信息集成中的数据源访问机制分析

来源:用户上传      作者:

　　[摘要]从系统实现的角度，将信息集成中的关键技术――异构数据源的访问机制分为4类：基于HTTP协议、基于标准接口协议、基于API以及基于本地数据库接口的访问机制，对其基本原理、特点和使用原则加以详细介绍，并对这些信息获取机制的优势和劣势进行深入分析和对比，提供多种协议的选择原则，简单描述其实现策略，以便对其进行封装后加以集成。
　　[关键词]异构数据源　信息集成　访问机制
　　[分类号]G250.76
　　
　　1　引言
　　
　　随着计算机技术特别是Web的迅猛发展，越来越多的数据在Web上发布，并具备比较便利的访问接口，使用户可以方便快捷地获取各类信息。但是，由于数据提供方及专业领域的不同，每个数据源几乎都是异构的，因而它们之间的信息、组织和接口都不一样，这就构成了一个巨大而复杂的异构数据环境。只有将这些孤立的数据都集成起来，提供给用户一个统一的视图，才有可能从巨大的数据资源中获取所需的东西。为了集成这些数据，关键环节之一是将异构的访问接口进行封装，屏蔽各种数据源的差异，使这些异构系统“互联互通”。本文主要分析和探讨各类数据源的数据访问机制，为进一步的接口封装奠定基础。
　　
　　2　异构数据源的访问机制分析
　　
　　目前数据资源的结构及接口形式各异，所支持的接口协议主要包括：HTTP、Z39，50、JDBC、ODBC、SOAP(Simple Ob―ject Access Protoc01)、Web Service、LADP(Lightweight DirectoryAccess Protocol)等。
　　针对目前异构数据源所支持的协议集，可将访问机制大致划分为4类：①基于HTTP的访问机制；②基于标准接口协议的访问机制；③基于API的访问机制；④基于本地数据库接口的访问机制。每种访问机制均有其自身的特点及其适用范围，面对纷繁复杂的网络资源，集成时需要针对各类资源的具体情况进行区别对待。有些资源只支持一种访问机制，而还有一部分资源则允许多种协议对其进行访问。每种连接技术或协议都有其优点及缺点，因此，如果一种资源可以通过多种连接方式获取，那么在数据访问模块中应确定优选的连接方案。具体地说，通过HTTP协议可以检索许多网络资源，但是检索结果的集成需要对网页进行解析，因此它的结构性最差，应尽量采取其他标准接口的协议，以保持系统的稳定性和标准化。通过数据库接口软件与不同的数据库直接连接，在同时检索的数据库数量较少时，使用此技术可在一定程度上解决异构检索问题，但数据库达到一定数量时，处理速度很难保证。这种方式仅适用于对属于本单位的少量异构数据库进行统一检索。某些数据源本身提供的检索接口API，很容易识别和使用资源本身的元数据。信息集成中应该在选择访问机制时综合考虑稳定性、标准化、开放性等多种因素。为了封装各种协议，必须对每种协议进行分析研究，以下笔者结合实际开发经验，分析上述4类访问机制的实现技术。
　　
　　2.1　基于HTFP的访问机制
　　现有各种数据源都提供相应的客户端接口，因此可利用HTTp访问机制向其发送检索请求加以集成。HTTP(HyperText Transfer Protoc01)协议，即超文本传输协议，是WWW服务器使用的主要协议。它是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。HTrP协议基于请求／响应方式，客户／服务器模式中信息交换的实现过程主要包括建立连接、发送请求、发送响应和关闭连接4个步骤。HTTP协议是支持信息集成的最基本协议，通过它实现与分布式网络数据库、电子期刊等信息资源的连接，执行检索与浏览操作。
　　在实际应用中，不同数据源的Web处理接口存在很多细节上的差别，笔者对所掌握的各种情况进行总结，归纳出以下差别：
　　2.1.1　检索请求的发送方式大部分数据源都可以同时支持GET请求和POST请求，但也有一些数据源只接受POST请求，应进行区别对待。
　　2.1.2　检索请求URL的分析成本大部分数据源的集成都需要经过一定的人工分析，对它的检索机制要有一定的了解，但有一小部分数据源的集成几乎是“零成本”，即几乎不用进行分析就可以轻松集成。具体来说，在数据源的检索页面中输入检索词，执行检索后进入检索结果页面，包含各种参数的检索请求URL在浏览器的地址窗口中完全呈现，检索引擎只需根据具体情况改变检索参数值，以POST或GET方式向数据源发送检索请求，即可返回检索结果。这种数据源可以很容易地加以集成，但这种情况非常少见。
　　大部分数据源在执行检索后，向用户呈现的检索结果页面并不会直接将检索请求的所有参数显示在地址栏中，而只是显示结果页面的基本URL，如果检索引擎直接利用这个URL作为检索请求，由于参数不足，不能正确返回检索结果。因此在将这类资源添加到集成检索系统中时，开发人员还必须对数据源的检索页面进行细致分析，查找各种隐藏或显式的检索参数，将其进行组配，才能得到有效的检索请求。
　　因此，根据这一点可以将数据源分为两类：①检索请求直接呈现；②检索请求间接转换。
　　2.1.3　检索请求的动态参数值向每个数据源发送的检索请求中除了基本的服务器地址，还包括多种参数，只有这些参数互相配合才能真正从数据源得到检索结果，访问信息源的参数可以存放到请求URL或实体当中。每个参数的形式一般都是“参数名=参数值”，参数之间用“&”连接。参数分成两种：一种是固定值的，另一种是动态值的。动态值的参数可以与信息源访问算子中捆绑约束谓词内出现的属性作对应，其中参数名对应属性名，参数值对应捆绑约束谓词内的具体属性值。因此，只要建立捆绑约束谓词内属性名到访问参数名的固定映射以及捆绑约束谓词内属性值到访问参数值的映射函数，就能实现信息源的访问。
　　动态变化的参数一般是数据源的检索系统为用户的每次会话建立的标识SessionID。根据这一点可以将数据源分为以下三类。
　　・检索请求中不包含会话标识。向这一类数据源发送的检索请求中不包含SessionID，这就意味着同一个检索请求无论什么时候发送都可以从远端的服务器得到响应，不会有会话过期的问题。
　　・检索请求中显式包含会话标识。某些数据源在用户进入检索页面时，会给用户分配一个随机生成的会话标识，只要用户没有退出或会话没有超过时效，用户的相关信息就会保存在Session中，数据源的检索系统将根据该标识识别用户的相关操作，因此在将这类数据源集成到系统中时，集成系统应在多次发送的检索请求中包含会话标识，才能得到最终的检索结果，对于不同的数据源有时需要获取多个会话标识。
　　・检索请求中隐式包含会话标识。用户在使用某些数据源的检索系统时，需要账号登录后才能进行检索。将这类数据源集成到系统中时，检索引擎应模拟人工手动向数据源

提交用户名和密码。这种类型与上述的第二类比较相似，都需要检索引擎向数据源发送的多次请求保持连贯性，但不同的是后者可以得到一个保证操作连续性的会话标识，而前者却是在浏览器中隐含着为用户分配的标识，用户需带着这个标识才能保持登入的状态。
　　2.1.4　完成一次检索需要发送请求的次数　对不同的数据源来说，要完成一次检索，检索引擎需要发送的检索请求次数是不同的。某些数据源只要经过一次连接就可以得到检索结果。对于一些需要建立Session的数据源(2.1.3中的第二、三类数据源)，则要经过多次检索请求的发送才能得到最终的检索结果。另外还存在一部分数据源在多次发送检索请求后，只能得到带有检索结果页面URL的网页，检索引擎在处理这些数据源时，需要利用人工分析的结果进行重新定位，才能得到最终检索结果。
　　对于任何采用HTTP访问机制进行集成的数据源，我们都可以用上述4个指标进行衡量，只要把数据源的这些方面进行充分了解，就可以“对症下药”采取相应的策略，从而将其进行整合。
　　HTTP连接是目前在检索引擎中最常用的信息获取机制，其主要原因有以下几点：首先，采用HTTP访问机制可以进行无障碍通信，由于采用端口80，从而可以避开防火墙的阻挡，取得检索结果；其次，通信过程简单快速，检索引擎向服务器请求服务时，只需传送请求方法和路径，请求方法常用的有GET、POST、HEAD等，每种方法规定了客户端与服务器联系的类型不同；再次，HTTP允许传输任意类型的数据对象，较其他协议更灵活；最后，HTT P的通信过程属于无连接状态，无连接的含义是限制每次连接只处理一个请求，服务器处理完检索引擎的请求，并收到应答后，即断开连接，采用这种方式可以节省传输时间。
　　不过HTTP访问机制也存在一定的缺点，主要是在集成数据源时，需要对它们的Web处理接口一一进行详尽分析，比较繁琐；另一方面，由于网络资源更新频率越来越快，各个数据库的Web处理接口也经常发生变化，一旦发生细微的改变，就需要重新进行分析设计，接口的稳定性较差。如果从结果处理的角度出发，HTTP连接所获得的检索结果是不甚规范的HTML网页，为结果整合提供了一定的难度。因此，如果数据源同时支持HTTP协议及其他标准接口协议，建议还是采取标准接口协议进行连接。
　　
　　2.2　基于标准接口协议的访问机制
　　除了常见的HTTP访问机制外，还有很多数据源是支持标准接口协议访问机制的，采用标准接口协议的检索引擎一般比较稳定，获得的检索结果格式统一、结构标准，对于这些数据源的集成需要对这些协议有一定的了解。目前检索引擎中采用的标准接口协议主要包括Z39.50t、OAI(Open Ar－chives Initiative)、OpenURL和SOAP，它们的主要目的都是提供整合性的信息查寻与连接服务。
　　采用Z39.50协议的检索引擎主要应用于对书目数据库的检索。这种开放网络平台上的应用层协议，支持不同数据结构、内容、格式的系统之间的数据传输，可以实现异构平台、异构系统之间的互联与查询。OAI属于基于元数据搜寻和检索的分布式系统，通过OAI，可以实现对“深层网络(deep Web)”资源的访问。OAI具有很好的开放性和适用性，使得不论各个数据库内部结构如何，都可以将它们灵活地无缝连接起来。OpenURL是在基于Web的学术信息环境下实现开放互连的机制。作为需要与外界建立链接的资源，只要遵循OpenURL，原则上就可以与任何资源(或者服务)建立链接，而无需关注链接对象的平台和规则。SOAP是在分散或分布式的环境中交换信息的简单协议，通过采用标准化的动作，调用远程过程来检索特定的信息对象系统，从而解决跨平台的程序沟通问题。
　　同HTFP访问机制一样，标准接口协议在资源集成方面同样存在各种优势和劣势。笔者将从以下几个方面对这4种标准接口协议进行比较说明。
　　2.2.1　访问机制的跨平台性及可扩展性这4种协议都是将成熟的基于HTTP的Web技术与XML的灵活性和可扩展性组合在了一起，其最大优点是不受特定的平台或语言的局限，因此采用这些标准接口协议作为访问机制可以扩大集成数据源的范围。
　　2.2.2　访问机制的可靠性相对于HTTP协议的无状态性，有状态、确认性的网络连接方式可以保证数据传输的可靠性与安全性，但这种有状态的连接方式可能引起系统并发数的限制。Z39.50协议即属于后者，一旦建立SOCKET连接，在整个过程中将一直保持，客户端很长时间不与服务端交互，也要占用连接资源。其他三种标准接口协议则是属于无确认性的访问机制。
　　2.2.3　整合检索模式主要分为两种：①采用标准接口协议，自动批次获取各个数据源的元数据，如OAI；②通过标准接口协议实时检索数据源，如Z39.50、SOAP、OpenURL。对于使用者而言，前者查询速度较快。
　　2.2.4　实现复杂度这4种标准接口协议都是经过认证的国际标准，具备了稳定性、开放性等多种优势，相较于其他非标准接口协议，实现方式也很简单。但这4种协议的复杂度有所不同：Z39.50的应用实现最为复杂，主要原因在于抽象的记录语法、RPN的检索表达式、ASN.1的传输方式，复杂的属性集支持等；OpenURL、OAI、SOAP均是相当简单的协议。
　　2.2.5　字符支持检索引擎从各个异构数据源获得检索结果后，结果处理模块要对它们进行整合，整合工作的一部分就是将字符编码进行转换、规范，其中需要特别关注的是中文问题。Z39，50的返回信息中字符编码种类繁多，如GBK、GB2312、EACC、CCCII等，检索引擎需要对每种情况进行特殊处理，相对比较复杂。OpenURL主要是以强化超级链接为目的，没有中文化问题。
　　总之，尽管还存在种种不足，但标准接口协议是信息集成的推荐使用访问机制，不仅接口稳定，而且格式统一的结果有利于进行结果整合。
　　
　　2，3　基于API的访问机制
　　
　　除了以上通用的、常见的协议，某些数据源本身提供公开的接口API，在集成这些资源时可以利用这些API来构建检索引擎，从而可以在接口比较明确的情况下，以灵活的方式将数据源有效集成。采用这种机制的检索引擎相对稳定，结果整合比较容易。
　　例如搜索引擎Coogle提供对外开放的查询接口API，可以让全世界各地的Java以及NET程序员，通过Web服务接口访问其索引。这就是说，开发人员可以采用编程的方法将请求发送到Google服务器，然后取回结果。虽然这些请求的参数与用户通过Web界面进行正常的COogle搜索使用的所有参数完全一样，但是程序员可以在程序内部控制这些参数。程序员还可以利用其他一些信息，如拼写建议服务器。这就是说，可以写一个能利用Google引擎来检查用户的拼

写并提出建议的应用程序。检索得到的输出结果规范统一，API中提供了各种查找设定方法，例如从第几笔开始查找、设定传回笔数、偏好查找(避免查找“java”时传回“咖啡”的结果)等。
　　目前，Google的API还没有提出正式的运营模式和收费方式，处于测试阶段，因此，在API的使用上还有一些限制。例如，使用这些API需要申请一个账号，取得一个32位长度的license key，每次呼叫查询时，必须发送这个license key才能使用。对于免费申请的账号，为了防止开发人员不正当的使用，限制每个账号、每天最多只能查询1 000次，每次最多返回10条搜索结果，通过这个服务只能找到前1 000条结果。另外，由于这是一个试验性的服务，Google可能为维护而关掉服务，可能修改了API而导致与开发人员的程序不兼容，或干脆不再提供这项服务，因此，信息集成过程中还应密切关注各种API的动态。
　　
　　2.4　基于本地数据库接口的访问机制
　　在异构资源中，各单位的自建数据库也是相当重要的一部分数据源，这些数据源与其他网络数据源的相同点是通过互联网提供服务，其对外服务接口可能属于本文前面介绍的种种类型，不同的是集成系统的开发人员可以直接获得数据源的详细底层接口、数据结构、裸数据等。
　　由于目前比较成熟的数据库都存在相应的数据库接口软件，因此集成系统的检索引擎可以利用这些接口软件(如JDBC、ODBC等)，将用户的查询请求转换为数据库查询语句执行检索，进而将其集成到系统中。采用这种访问机制集成的数据源结构性较好，也比较稳定、简单，得到的检索结果是没有经过任何包装的数据，可以借助数据库提供的功能或其他技术直接转换成利于整合的XML文档，因此这是一种优先采用的机制。
　　可以采用这种机制的数据源只是占到全部资源的很小比例，因此在扩充集成资源数目及类型上作用甚微。在对数据源进行集成时，采用本地数据库接口软件这种访问机制将涉及到多种数据库驱动程序，以采用JDBC为例，SQL Server、Oracle、MySQL等数据库所加载的驱动程序各不相同，甚至有时同一种数据库的不同版本所采用的驱动程序也有差别，如SQL Server2000和SQL Server 7.0。因此，需要针对不同类型的数据库采用不同的连接器，并了解每种驱动程序的机制。另外，使用JDBC访问数据记录的速度会受到一定程度的影响，从而影响系统整体的检索速度。
　　
　　3　结论
　　
　　目前而言，数据类型及来源的不同导致各个数据源不可能提供统一的访问接口，尚无完美的解决方案可以集成所有的电子和网络资源，但是针对不同的需求、平台或是系统、资源，都有不同的、适合的集成技术和协议。因此应针对不同的需求和方式，结合适合的资源集成技术和协议，发挥最大的整合效益，通过保证用户可以获得大量多样的相关资源，而基于Wrapper的封装技术可以实现这个目标，内部封装的各个组件能够连接支持不同协议集的目标数据源，实现对用户的透明化，并可以通过新增组件方便地进行扩充，从而实现对任何协议资源的连接功能。

转载注明来源:https://www.xzbu.com/1/view-154414.htm