【IT168 专稿】随着计算机网络和数据库系统的迅速发展，企业竞争与兼并的加剧，多样化新技术的采用，使得信息资源的异构性在企业的信息系统中无处不在，越来越多的应用需要访问各种异构数据源。任何企业应用首先需要解决的，就是如何对企业中的异构数据源进行集成和一致化处理，形成标准、统一和可靠的数据源，来作为应用系统的基础。而为了达到异构数据源的共享，必须先解决异构数据源集成与转换问题。
本文的重点介绍用Globus Toolkit 和OGSA-DAI建立异构数据集成平台，利用此平台对各个异构数据源进行无缝连接, 对各个节点数据源提供数据共享注册的功能，集成中心协调管理各个节点数据源，为用户提供一个统一透明的访问接口。利用现有的网格中间件工具Globus Toolkit和现有开发体系的中间件OGSA-DAI，对网格开发工具进行封装，从而屏蔽网格理论和工具的复杂性。将若干个分布的、独立的异构数据源集成到一个特定的环境中，实现对这些多数据库系统的统一查询，屏蔽各个业务节点数据库的结构、运行环境上的差异、网络分布状况和具体的物理位置，保证各个节点数据库的独立性和数据的安全。
首先简要介绍一下网格技术和Globus Toolkit以及OGSA-DAI：
1．网格技术：网格是构筑在因特网上的一组新兴技术，它将网上的各种资源融为一体，实现如计算资源、存储资源、数据资源、信息资源、知识资源、专家资源的全方面共享。它的目的是想利用高速互联网把分布于不同地理位置的计算机、数据库、存储器和软件等资源连成整体，就像一台超级计算机一样，为用户提供一体化信息服务，其核心思想是：“整个因特网就是一台计算机！” 网格的根本特征不是它的规模，而是资源共享，消除资源孤岛。
2．Globus Toolkit：由全球网格论坛（GGF）下属Globus项目组成员联合开发的Globus Toolkit标准工具包，已被公认为当前建立网格系统和开发网格软件事实的参考标准。它是一种供网格应用的Java主机框架结构，它提供了使网格应用可在框架内注册其服务并维护其状态，以及与其它应用通讯的一个环境。Globus Toolkit是开放网格服务体系结构的主要实现，而该体系结构又是OGSA-DAI 的基础。
3．OGSA-DAI（Open Grid Services Architecture - Data Access and Integration）： OGSA-DAI是一种中间件，其设计目标是提供一种简便的方法，在网格环境中实现数据的访问和集成。OGSA-DAI是一个带有许多扩展点的工具包，它为开发者提供便利，以便适应各自特定的应用。更重要的是，OGSA-DAI中间件可以允许相同的数据在虚拟的组织中进行查询，隐藏那些像数据库驱动程序技术、数据格式转换技术与来自用户的发送机制等细节。这个目标通过提供高效率的网格中间件的标准组件执行来实现的。这些标准组件用来访问和控制数据信息和资源。开放网格服务架构— 数据存取和集成(OGSA-DAI)使得现有数据资源，如关系数据库和XML数据库能够通过扩展活动较容易地集成到网格环境中。
网格服务(Grid Service)技术是在开放网格体系结构OGSA中提出来的，它是对Web Service 的扩展，实际上就是一种Web Service和以往网格技术融合的产物。由于OGSA采用统一的Web Service框架，因此很自然具有Web Service的所有优势，它是一种编程模型，提供在可缩放的、松耦合的和非特定平台的环境下交换信息的能力，信息交换使用诸如HTTP、XML、XSD、SOAP和WSDL之类的标准协议。它能够统一地封装信息、行为数据表现以及流程。而无需考虑应用所在的环境是使用何种系统和设备，最大优势就是提供了异构平台无缝衔接的技术手段，实现异构平台间的互通。网格工具软件包Globus Toolkit已经成为对OGSA进行规划和组建的开发平台，它将web服务、数据库存取、J2EE等技术有机的纳入网格中，从而形成构建网格系统的标准和规范。因此本文的集成系统采用Globus Toolkit作为基本的开发平台。
在异构数据源集成中使用Grid Service的目的就是将服务功能以接口的方式提供给用户，数据库访问操作则通过中间件平台完成。用户不需要了解后台的实现过程仅需调用功能接口就可以完成对数据库的操作。Grid Service将客户对数据库的操作目的封装成SOAP对象，通过http传送到Web服务器，Web服务器将接受的SOAP对象转发给Grid Service请求服务器；Grid Service请求服务器解析收到的SOAP请求，调用Grid Service，对数据库进行操作，然后将返回结果生成相应的SOAP应答。Web服务器收到SOAP应答后，再通过HTTP应答的方式将结果返回到客户端。过程如下图：
下面来介绍一下该平台的框架设计：
集成平台中的各个节点数据源以Grid Service的方式对外发布，WEB应用客户端或者其它应用程序客户端从不同的平台，不同的软件开发环境调用该中间件的Grid Service接口,从而获得来自不同节点数据源的数据,实现数据的透明访问。下图是数据集成框架。
从上图中可以看到，客户端运行资源浏览器，用户通过资源浏览器能看到系统的统一数据视图、对数据进行访问和操作、调用系统提供的网格服务等。客户与网格服务器之间的通信是调用网格服务接口进行的，之间的传输协议是SOAP访问协议。它们的交互数据通过XML语言进行统一描述，便于系统的理解，这样，客户端就可用浏览器对返回的数据进行解释和显示。
网格服务接口负责通过标准的Grid Service接口形式向用户提供访问整个网格环境内已经发布的数据源的方法。每个业务节点都拥有一个Tomcat (Apache)服务器，以作为Grid Service的运行平台。每个节点有拥有一组Grid Service服务，但是网格环境的每一个节点必须至少拥有一个管理器的服务，从而能够与上层的网格服务(Grid Service)管理与发现层进行交互。
本平台体系结构采用网格组件构架的方式进行设计，参照开放网格服务结构OGSA的思想，将节点数据库自动注册，数据库集成和虚拟数据库查询都抽象为服务，建立数据集成中间件平台，通过服务的请求和调用实现系统间的数据交换和共享。
各个节点系统所提供的数据并不需要先复制到系统的中心数据库中，而是以Grid Service的形式发布出来，只有当用户发出服务请求的时候，数据才从节点系统经过数据集成平台直接传递到用户。这样，用户得到的永远是最新的信息。
当节点系统中的数据格式变更或增加了新的数据时，只需要以新的Grid Service发布出来，用户通过数据集成平台使用服务并获得相应的数据。数据中心和客户端，都不需要任何改动，这就实现了系统之间的低耦合性。
下面介绍一下OGSA-DAI的内部架构以及它的工作原理。
? 网格数据服务—Grid Data Service (GDS)：是一种可以访问数据源（一个关系数据库或XML数据库，甚至是一种原始文件形式的数据存储）的服务。
? 工场—Factory：是一种服务，它建立一个GDS实例来访问特定的数据源。
? 服务组注册器—Service Group registry：它是一种服务，用以寻找你所关注的GDS或由工场（factory）根据需要建立的GDS。
? 执行文件—Perform document：一个XML格式文件，它规定了在GDS上被执行的许多行为，如执行SQL查询然后将该查询的结果输出到第三方。
下图是OGSA-DAI的工作流程：
如上图所示：一旦OGSA-DAI启动，工厂就随之启动，然后用注册器对数据源进行注册，并能通过预先配置文件中的静态信息和配置文件提供的MetaDataExtractor类能访问到服务数据。客户机在服务列表中确定在注册器中列出的众多服务源应该使用哪一个。一旦选定合适Data Service Resources，客户机就请求工厂创建一个GDS实例，以访问特定的数据资源。现在，GDS已经准备好了，可以接收执行文档，运行数据库查询，传输查询结果和传送数据。
现在，已经有了一个执行文档，并将其发送到引擎中，引擎构造了一串活动，并用管道将这些活动连接起来。那么，这些活动该如何与 DBMS 交互，来访问数据库中的数据呢？
下面介绍如何如数据资源交互：
不论您使用的查询语言是 XPath、XUpdate、还是 SQL，所使用的类集合以及这些类之间的关系都比较相似。所以在这里只考虑通过 JDBC 连接 DBMS 执行 SQL 的情况。
OGSA-DAI访问数据源的类如下：
? 包 uk.org.ogsadai.porttype.gds.activity.sql
SQLActivity
RelationalResourceManagementActivity
SQLBulkLoadRowSetActivity
SQLQueryStatementActivity
SQLStoredProcedureActivity
SQLUpdateStatementActivity
? 包 uk.org.ogsadai.porttype.gds.dataresource
DatabaseMetaDataExtractor
DataResourceImplementation
JDBCDataResource
MetaDataExtractor
SimpleJDBCDataResourceImplementation
SimpleJDBCMetaDataExtractor
GDS是专门为访问特定的数据资源设计的，这种数据资源从物理上讲存在相互独立的任意GDS。因此这就意味着代表数据资源的对象应该与工厂紧密相关。在与特定数据交互的过程中，会存在一个对象，用来在每个工厂的基础上管理或缓存连接。GDS并不是孤立地管理它与数据库的交互。与此相反，每一个 GDS都使用工厂类提供的 DataResourceImplementation来管理连接。同一个工厂生成的多个访问同一数据资源的 GDS都用同一个 DataResourceImplementation 对象来处理连接。
这就意味着OGSA-DAI访问DBMS的这些类可以划分为三组：
? DataResourceImplementation类：负责处理 JDBC 连接、驱动程序、角色映射以及访问 DBMS。
? 活动类：负责接受 SQL，并用 JDBC 连接将这个 SQL 传递给 DBMS，然后对返回的结果进行格式化。
? MetaDataExtractor 类：发布与 DataResource 有关的服务数据，以便在注册器或工厂服务中选择正确的数据资源。以便在 注册器或工厂服务中选择正确的数据资源。
DataResourceImplementation类
DataResourceImplementation类掌管连接的处理和角色映射。它们在配置文件中与数据资源相匹配，并为希望自己编写 DataResourceImplementation 的人们提供扩展点。活动类应该仅仅依赖相关接口中的方法。
对关系型访问而言， SQLActivity将通过 JDBCDataResource 的 getConnection 方法获取一个 JDBC连接。实现的方法是将凭证作为参数传递。 DataResourceImplementation 类提供的 mapCertificate 方法可以用于将这些凭证映射为数据库角色（根据角色映射器获取用户名和口令）。现在，我们已经用 mapCertificate 方法获得了用户 ID和口令，也从配置文件中获得了 URI，必要的条件都已经具备，可以创建JDBC 连接了。
活动类
所有其他的 SQL 活动都要扩展抽象的 SQLActivity 类。这个抽象类中包含受保护的方法，可以用这些方法从活动中获取输入和输出信息。在这样的环境中，输入可以是值（由执行文档提供），也可以是引用（从其他活动中流入），还可以作为 SQL 参数、SQL 表达式以及存储过程名称等的响应。输出当然是 ResultSet，根据活动的类型不同，也可能是被更新的记录数目。
允许从流输入数据，特别是允许从同一个流获得多个输入，这种情况可能导致无法预计的结果。流中的值出现的顺序变得很重要，因为活动读取流中数据的顺序要与输入数据在活动元素中的声明顺序保持一致。
设置好活动之后，就知道需要什么样的输入信息，也知道输出信息将去往何处。在整个处理过程中，都将实施跟踪，看连接是否保持打开状态。这种跟踪机制使我们能够在操作完成的时候将连接返回，并在适当的场合重新利用这个连接（比如在prepared statement 中）。
SQL 活动中的处理可以分为三个阶段：
? startProcessing 获得连接，设置下一条语句。根据活动的不同，连接可能会设置为只读。
? getResult 从输出流中获得下一个数据块。由于执行语句的结果可能是 ResultSet，这样就对应多个数据块，因此调用这个方法并不总会执行一条语句（当然了，第一次调用的时候肯定会执行语句的）。
? endProcessing 结束输出流，并返回连接。然而，如果活动对应于 prepared statement，将选择保持连接，并允许重用该活动。
MetaDataExtractor 类
OGSA-DAI 使用了 GT4 的 ServiceDataValueCallBack 接口，这样就能根据需要，通过 MetaDataExtractor 类的getMetaData()来获得元数据。
OGSA-DAI执行文挡，通过OGSA-DAI在数据库中执行查询或者其它操作，这些操作可以由自己定义。每次操作请求称为一个活动，需要创建预先写好的服务活动事例，在数据库端执行。实际运用中，OGSA-DAI还支持其它类型数据源的扩充访问。执行文档可以包括多项SQL操作，如查询操作，但无需编写任何数据库连接语句，因为创建网格数据服务时，OGSA-DAI在后台会进行相应的数据库连接。查询请求的输出结果需要被格式化为WebRowSet格式，OGSA-DAI需要返回一个执行XML文档，在XML文挡中包括查询操作返回的所有行。
基于网格的异构数据源集成，从访问数据库的角度看，在网格环境下访问数据库的方式和在网格环境之外访问数据库的方式相似，但是利用网格开发工具可以屏蔽各个业务节点数据库的结构、运行环境上的差异、网络分布状况和具体的物理位置，保证各个节点数据库的独立性和数据的安全。相比较其它异构数据源的集成环境这是它的优势所在，随着网格技术的进一步完善与规范，数据网格的应用会越发的成熟。
