开放式网格服务体系—数据访问与集成体系与数据库

引言
OGSA- DAI是中间件,它被设计得使在网格环境中对数据的访问和集成变得更为容易.本项目包含了多名积极的合作者,其完整的名单可以在OGSA-DAI网站http://www.ogsadai.org.uk/上找到,然而多数的开发工作是在苏格兰的EPCC(EPCC Scotland)和在英格兰的IBM Hursley 公园(IBM Hursley Park England.)进行的.
我们采用的OGSA参考工具来自Glubus 项目的Globus Toolkit 3(GT3).GT3是一种供网格应用的Java主机框架结构,它提供了使网格应用可在框架内注册其服务,维护其状态,以及与其它应用通讯的一个环境.
推动OGSA-DAI发展的原因是一些"大科学"项目对中间件层的需要,这些中间件提供了访问大型的,基础的静态数据库的支持.OGSA-DAI被构建成为一个带有许多扩展点的工具包,以便让开发者去扩展能力来适应他们自己的特定需要.数据库管理系统就是一个实例,这里有我们经常使用的各种关系数据库(通过JDBC来实现)和XML数据库(通过XMLDB实现).当然,应用开发者也可以写他们自己的数据库来支持可能产生的需要.

本文试图去探索OGSA-DAI较少公开的一些片段,诸如内部架构以及一些用户可以访问的较为公开的领域.当你读完了本文以后你就会有较大的收益,就会理解OGSA-DAI是如何工作的以及它为什么需要按它特定的方式工作.我们也希望你将会有足够的信心使用我们所讨论的工具去进行实地的实验,甚至可能建立若干扩展并发展现有的平台(OGSA-DAI项目组欢迎组外人士的贡献).

注册器,工场,网格数据服务实例,以及执行文件
我们假设你熟悉OGSA的注册器(registry),工场(factory)和实例(instance)等的概念.下面是用于本文的一些附加的术语:
网格数据服务—Grid Data Service (GDS) 是一种可以访问数据源(一个关系数据库或XML数据库,甚至是一种原始文件形式的数据存储)的服务.
工场—Factory 是一种服务,它建立一个GDS实例来访问特定的数据源.
服务组注册器—Service Group registry 它是一种服务,用以寻找你所关注的GDS或由工场(factory)根据需要建立的GDS.
执行文件—Perform document 一个XML格式文件,它规定了在GDS上被执行的许多行为,如执行SQL查询然后将该查询的结果输出到第三方.
我们也假设你熟悉OGSA-DAI并至少已经下载,安装和使用它来访问数据资源.如果确实如此,你将会明了主配置包括建立工场(factory)的步骤.我们按下述方法配置工场:

用一个特定的网格数据服务组注册器来注册它自己
将它链接到下层的数据资源,并包括下列资源:
⊙ 有用的行为,模式,执行类
⊙ 对于资源的元数据,它可能采取两种形式,静态的(在配置文件中写明)和恢复的——由一个执行类MetaDataExtractor来恢复
⊙ 驱动信息,包括对数据资源的执行类,JDBC(或等效的)驱动以及资源的URI.
扩充观点:
在本文中我们谈及了许多扩充观点.在配置文件中对OGSA-DAI已说明了使用你新建立的类的方法.
现在已经配置完成并可开始运行OGSA-DAI了,当我们使用一个客户时将会发生什么呢?一旦OGSA-DAI被启动,工场(factory)就起动,由注册服务来注册自己,并且通过保存于配置文件中的静态信息和由配置给定的MetaDataExtractor类的工作,使服务数据生效.工场也将为数据资源建立执行对象.然后客户就能决定在注册表中列出的许多潜在的工场中哪一个将被使用.

选择了适当的工场以后,客户就可以请求工场来建立GDS实例以容许对特定数据资源的访问.现在GDS已准备好接收执行文件来运行数据库查询,将结果进行转换,以及输出数据了.

引擎架构
设定引擎(我们刚称之为引擎)是OGSA-DAI的核心.当一个执行文件递交到GDS执行时引擎像乐队处理每一个音符一样管理每一个发生在OGSA-DAI内的事物.让我们观察引擎做了些什么,并通过一小段细节观察它究竟是如何工作的.

当GDS建立后,通过来自GDS配置(最先来自工场的配置)的若干正文信息,引擎的工作被明白地说明了.这些正文信息包括:
行为及其相应的XML模式(schemas)和执行类的列表.
任务映射器器(role mappers)列表及任务映射器的细节.
数据资源适用工具(resources implementation)和数据资源特殊的细节.
可区别名字(Distinguished Name)DN
可区别名字是一种符号,用以在当X509验证时,统一识别一个特定的用户.典型的DN是由用户名,组织名,国家名和一些必要的附加信息组成.例如:
/c=UK/o=IBM/ou=HS&T/l=Winchester/
cn=Neil Hardman.
c=UK : Country(国家)
o=IBM : Organization(组织)
ou=HS&T : Organizational unit (组织的部门)
l=Winchester : Locality(位置)
cn=Neil Hardman : Common name (first and last names)(通用名)
当GDS接收到一个执行文件,它就将文件随同一些正文信息(如用户授权信息等)一并传送到引擎.引擎通过下列动作来处理执行文件:
解析执行文件并使之生效
对执行文件规定的行为进行识别
对行为执行工具进行说明
对行为及行为间的管道进行说明
对行为处理器进行说明
用处理器来处理行为,并通过管道传送产生的数据
将输出进行合成,并形成一个响应文件
将响应文件返回到GDS,再被返回到客户去
在执行文件被执行的全过程,行为的状态作为OGSI服务数据始终有效.
引擎被设计得在一个时间内只与一个执行文件相联系.如果一个执行文件被提交而另一个文件仍在执行,系统将会返回一个UserException信息.当然这不会停止由同一个工场(factory)所建立的多个GDS例证——每一个GDS例证都将会有它自己的引擎,因此你就能在同一时间里执行多个文件.

我们就以图1的图解结束上面的分析.
图1 引擎架构
1
现在我们将更详细地研究一个执行文件(如上面提及的用粗圆点标出的)是如何执行的.
Setting up建立
当一个执行文件被提交到GDS以后,GDS将它交给引擎,而引擎则使用保存在引擎正文信息中的行为模式从而使执行文件生效.然后行为则被按照执行文件的相关数据和保存的正文信息的要求来执行(例如,行为sqlQueryStatment需要按任务映射器(role
mapper)和数据资源适用工具的信息连接到数据库并执行查询).引擎的工作可以超越各行为的输入和输出被链接在一起的顺序,并且在这些行为之间设置了缺省的管道.
引擎也可以对任何未被链接的行为(unlinked
activity)的输出端建立起了deliverToResponse行为(并连接到管道).所以缺省的性能是,由行为产生的任何数据应按响应文件要求同步地返回.其次,引擎建立了行为处理器来管理行为如何被调用,最后是,正文如何提供给行为的.所以他们可以选择一个非缺省的行为处理器或管道来使用(例如,inputStream行为使用一个SynchronizedGrowablePipe管道).

Synchronous or asynchronous 同步或异步
现在一切都已建立并可以准备让数据开始流动了.如果引擎没有使用任何deliverToResponse行为(例如,如果执行文件规定所有的数据都通过deliverToURL行为被输出到第三方,如FTP服务器),引擎就开启一个新的线程来异步地执行行为并发送响应文返回给客户端.在这种情况下,响应文件可能只包含了简单的信息以指明执行文件已经执行即可.否则,执行立即起动并且没有响应被返回,直到所有的行为集合的状态都被完成或是产生一个错误为止.

Block 块
在OGSA-DAI中,数据的基本单位是块.块是单一的Java对象(或一个单一的对象数组或基本类型),其含义是,一个行为可以将任何Java对象放置进它的输出,以供后续的行为消耗,并且可以期望去接收一个大的输入块,这取决于流中前面的行为的状态.在行为之间不做类型检查,这意味着行为需要检查从其输入的数据应具有所希望的类型.否则,一个ClassCastException将被抛出.

实际上几乎所有的由OGSA-DAI提供的行为都把字符串对象放进它的输入,而只有少数例外,这将在本文的第二部分关于行为的节中加以分析.
How the data flows数据是怎样流动的
数据通过系统的移动由一系列的行为处理器来调整,每个处理器管理着行为链上的一个行为.管道给底层行为(infra-activities)提供数据路径,并把所有行为彼此链接在一起.除了链上第一个和最后一个以外,每个行为都有两个管道即输入管道和输出管道.输出递交行为(如缺省的deliverToRespoinse行为,显式使用的deliverToURL行为,或类似方法)应当对通过使用指定处理器(如RunAheadHangler)的初始化数据流进行响应.关于处理器将在本文的第二部分进行较完整的说明.对数据流的处理步骤说明如下:

1,输出行为处理器调用该行为的processBlock方法
2,此行为调用捆绑在输入管道上的next方法来提供所要处理的数据块
3,如果在管道中没有可用的数据块,管道将向提供数据的行为处理器进行调用
4,该处理器再一次向正在进行管理的行为调用processBlock方法,对链上的所有行为重复2,3及4的步骤
5,此处理的过程一直继续到该行为提供出了初始的源数据——无论是通过对数据库查询产生的数据或是由另一系统递交出数据时为止
6,当行为已经处理或已经恢复出了一些数据的时候,就要使用该行为的put方法将数据块put进它的输出管道中去
最后,所有数据都将流过了系统,并且每个行为(从起动初始数据源的行为开始)都将对它连接的输出管道调用close方法.当close方法结束后,后继的行为再试图从这个管道中拉出数据时,一个NoSuchElementException将释放出来,说明系统已无更多可用数据.

Error handling 出错处理
如果在处理过程中出现错误,失败行为的状态将设置为Error(可在行为中显式地设置,或在处理器中通过例外处理进行).由引擎监控所有行为的状态,如果发现一个错误状态,则将暂停处理工作,将状态和错误消息写入返回的响应文件中.如果行为是异步处理的,则处理工作的停止和客户发现出错的消息都可通过查询GDS的引擎状态来获悉(作为OGSI服务数据公布).

Cleaning up清除
如果错误发生或者所有行为的状态都被设置为完成,引擎就能够知道处理已经完成并可进行清除.如果系统使用的是一个deliverToRespoonse行为,就会在写响应文件完成后并送回给客户.然后系统丢弃所有的数据以使引擎准备执行即将到达的下一个文件.

An example一个实例
列表1的示例用以处理一个送到GDS的执行文件,该GDS使用sqlQueryStement行为来查询数据库.查询的结果将采用WebRowSet
XML格式(有关WebRowSet将在本文的第二部分讨论).接下来的一步,是使用xslTransform行为把一份XSLT格式单传送到WebRowSet
XML文件中并把查询结果转换成一组以逗号分隔的变量.最后,使用缺省的deliverToResponse行为,把此转换结果递交回到客户,因为从xslTransform行为的输出(在此案例中命名为transformedData)是不与任何其他行为相链接的.

列表1. 执行文件示例

select * from littleblackbook where id=100

在引擎收到此文件并使之生效以后,示例中表示出了两个已命名的行为以及与它们相关的处理器.然后在行为之间建立起管道,注意从sqlQueryStatment行为的输出被链接到xslTransform行为的输入(通过名字"statmentOutput").引擎也通告:xslTransform行为具有一个正在处理的输出(名为"transformedData")和已示例出的deliverToResponse行为以及其它的处理器和管道.

因为deliverToResponse是个输出行为,与该行为相关联的处理器被设置为RunAheadHandler.其它的行为都该赋值为缺省值CallThroughPipe和SimpleHandler.由RunAheadHandler起动处理工作,并使数据流动——通过查询sqlQueryStatment行为从数据库获得数据,经过xslTransform行为转换,再进入deliverToResponse行为把数据块合并到响应文件后返回到客户,处理过程见列表2所示.

列表2 响应文件示例

再次使用前面的图形后,现在的体系架构变为图2所示.
图2.上述实例的引擎架构
Database access 数据库访问
由于受到已掌握技术的深刻影响,因此我们不打算创造新的解决方案或范例来简化对保存于数据库中信息的访问.从视觉上和感觉上来说,对OSGA-DAI的访问似乎应该尽可能地与对网格环境以外的数据库访问相类似.只有在这种情况下,我们才能看到将数据库包含进网格之中并以最小的成本改写数据库的巨大好处,即使差劲的解决方案也是如此.在本节中的UML列表并未刻意加以完美化,而仅仅用加亮列表上的内容来加以说明.

现在我们已掌握了执行文件并将它发送到引擎的方法,引擎也给了我们一串经过管道连接起来的行为.这些行为如何与DBMS互动来进行对数据库数据的访问?让我们继续下去.
不管你采用XPath,XUpdate,或SQL作为查询语言,但类型的集合是类似的,并且它们彼此的关系也是类似的.这里我们只考虑使用JDBC连接到一个关系型DBMS的SQL查询语言,但我们也加亮了扩充点部分.本实例可以引导你进行编程,允许Xpath或Xupdate越过XMLDB到XML
DBMS,重点是你如何写你自己的行为来与后端的数据源互动.
下面我们将讨论这些类型:
Package uk.org.ogsadai.porttype.gds.activity.sql
SQLActivity
RelationalResourceManagementActivity
SQLBulkLoadRowSetActivity
SQLQueryStatementActivity
SQLStoredProcedureActivity
SQLUpdateStatementActivity
Package uk.org.ogsadai.porttype.gds.dataresource
DatabaseMetaDataExtractor
DataResourceImplementation
JDBCDataResource
MetaDataExtractor
SimpleJDBCDataResourceImplementation
SimpleJDBCMetaDataExtractor
一个GDS被专门约束在它正在访问的特定数据资源上,而且该数据资源在物理上与任何GDS独立地存在.所以这意味着,这个表示数据资源的对象应当与工场(factory)紧密相关联.当与一个特定的数据库互动期间,存在着一个对象去管理或汇集(pool)以每一个工场为基础的连接.GDS不能管理与它不相连的孤立数据库的互动,每一个GDS将使用由工场提供的DataResourceImplementation来管理连接.多个DGS来自同一个工场并访问同一个数据源时,将使用同一个DataResourceImplementation对象来处理连接.

所有这些意味着上面所述的类型将落入下列三个组中:
DataResourceImplementation 类,处理JDBC连接,驱动,任务映射器,以及对DBMS的访问
Activity classes行为类,使用JDBC连接来接收SQL,通过SQL访问DBMS,进行格式转换和返回结果
MetaDataExtractor 类,发布关于DataResource的服务数据并能在注册或工场服务发生时正确选择数据源
DataResourceImplementation 类
JDBCDataResource getDriverClass 方法
在开发过程中,我们发现各种数据库驱动器具有有趣的特性.我们建立了一种方法getDriverClass, 去发现驱动器的类并可以使我们能够适当地改变其性能.
图3. 以UML模型表示的DataResourceImplementation
DataResourceImplementation类能小心谨慎地处理连接和任务映射.正如前面所述,他们与配置文件中规定的数据源相匹配,同时又为那些想自己编写DataResourceImplementation的人提供了一个扩展点.在关联的接口中行为的类只应当依赖于方法.

Connection pooling连接的汇集
虽然OGSA-DAI架构能够支持连接的汇集,但并没有把执行连接汇集操作的DataResourceImplementation当作代码的一部分被装载到程序之中.如下面图3所示的执行连接的汇集是完全可能的.

如果我们希望建立MyPoolingJDBCDataResourceImplementation,我们有以下两种选择:
我们可以从已存在的simpleJDBCDataResourceImplememntation继承并改写getConnection和returnConnection方法.

我们可以建立自己的对象,该对象择要地继承了DataResourceImplementation类,并使用JDBCDataResource接口.在这里使用JDBCDataResource接口是很重要的.因为它被SQL行为用来获得和返回数据库连接.

一旦你已经写出了新的类,剩下的事仅仅是更改OGSA-DAI的配置文件使其中一个数据源使用MyPoolingJDBCDataResourceImplementation类.(当然,OGSA-DAI项目组欢迎你们把执行连接的汇集的程序代码反馈给我们.)

对亲属的访问,SQLActivity行为(将在下面加以说明)将用getConnection方法向JDBCDataResource请求一个JDBC连接.要这样做必须递交信用证作为请求的参数.DataResourceImplementation类提供一个mapCertificate方法,该方法用来把信用证映射到数据库任务中去(由任务映射器来送达用户名,密码).现在我们有了建立一个JDBC连接所必须的信息,如来自mapCertificate方法的用户ID和密码,以及来自配置文件的URI.

当没有规定的当前的XMLDBResource接口可用时,扩充SimpleXMLDataResourceImplementation类通常是写你自己的XMLDB的DataResourceImplementation的唯一方法是.

Activity classes 行为类
图4. UML模型表示的SQL行为
用所有其它的SQL行为来扩充抽象SQLActivity类.该抽象类包含了受保护的我们可用它来提取行为的输入和输出的方法,.上下文正文信息中的输入可以是值(配置文件提供的)也可以是参考数据(来自另一个行为的流数据)并通常应该与SQL参数,如SQL表达式,存储的过程名相一致.当然,输出可以是一个ResultSet集合或是一个取决于行为类型的更新数值.

允许以流作为输入,而且实际上可以允许来自同一个流的多个输入,但这可能引起不希望的后果.在这些流中数值出现的次序变得十分重要,因为行为将要读出的流的次序必须与行为元素中被声明的输入次序一致.

在关于项目次序的叙述中存在一个例外:那就是命令(SQL表达式或存储的过程名).命令必须总是作为流中的第一个项目.对于这一要求的理由有二:
因为SQL行为元素不允许在任何地方对命令进行声明,不象其它的可以在SQLParameters之后和在结果流之前进行声明.
除非命令被预先发现,SQLParameter对命令将不作任何感知,因此命令将不可用.
所有这些意味着什么呢?图5提供了图解方法:
图5. 来自单一数据流的多个输入
因此结果是,你无须预先设置一个转换而仅需改变一下项目的次序,即在SQL行为尚未使用这些元素之前改变这些项目在流中出现的次序.所以,如果你想让使用的流中出现的项目具有如参数1,参数3,参数2,参数1,参数3,参数2,的次序,则你需要保证SQL行为的SQLParameters声明具有相同的次序(1随后3随后2),同时你必须能直接把这些流送到SQL行为.

在设置我们自己的行为时,我们应当知道什么是期望的输入以及输出将去到那里.我们将跟踪整个处理进程而不管我们是否有一个开放的连接.这个跟踪使我们在一旦工作结束时能够返回到连接,并可在适当地重新使用连接(例如,已准备的语句).

SQL行为的处理进程可设想为三个阶段:`
startProcessing(开始处理)获得连接并建立下一个语句,根据行为的属性,可将连接设置为只读状态.
getResult(获得结果)给输出流返回下一个数据块.因为执行一条语句可能导致执行一个对应于多个数据块的ResultSet方法,该方法并不总在执行语句(当然,它在第一时间总是导致语句的执行).

endProcessing(结束处理)完成输出流并返回连接.但是,如果行为对应了一条已准备执行的语句时,我们应选择保持连接并容许重新使用该行为.
所有XMLDB行为几乎是相同的,带有扩展的抽象类XMLDBactivity行为和附加的软件包(uk.org.ogsadai.porttype.gds.activity.xmldb.commands).此包中包含了相关程序代码,这些代码允许扩展抽象类XMLDBCommandActivity行为并提供不同的XMLDB命令.行为xmlCollectionManagement和行为xmlResourceManagement是对行为XMLDBCommandActivity的继承.

为满足特定数据库系统(DBMSs)例如Oracle等的特别需要另外一些附加的行为正在开发之中.
MetaDataExtractor 类
图6. 以UML模型表示的MetaDataExtractor
你如何发现一个关于GDS的元数据?例如,你能确定何种表和列已经存在?
我们假设你懂得网格服务和Globus
toolkit3,所以回答当然是与GDS相关联的服务数据.我们不希望与数据库相关的服务数据(比如一个列)被保存在DBMS的外面.所以OGSA-DAI使用GT3的ServiceDataValueCallBack接口在需要时通过MetaDataExtractor类使值能够发现.

Coming up in Part 2第二部分内容简介
在OGSA-DAI:盖头下的一暼的第二部分,我们将更详细地揭示行为,处理器,管道和任务映射,以及在更深的层次上观察如何来处理结果.我们将依然在文中包括了一些代码实例(我们只为代码疯狂!).

Resources
See the official OGSA-DAI site, where the latest distribution, documentation and
mailing list details can be found.
The 'grid data service' document contains in depth information about configuring
and using OGSA-DAI and about creating perform documents, and it contains a
complete listing of activities.
The 'How to write an activity' document contains a guide to the creation of
OGSA-DAI activities as well as in-depth information about how they work in the
OGSA-DAI framework.
The Globus site is the home of the Globus Toolkit 3, which is the main
implementation of the Open Grid Services Architecture upon which OGSA-DAI is
based.
The Global Grid Forum site is the home of the Open Grid Services Architecture
specification.
WebRowSet XML notation is the XSD file that defines the WebRowSet XML structure.

The article Accessing DB2 Universal Database Using the Globus Toolkit and
OGSA-DAI describes how to use OGSA-DAI to access DB2 data.

网格应用提升企业效率

网格计算的现状和挑战

网格计算开发入门基本概念

网格计算与分布式超级计算

网格与公用计算中的自动化 

网格---未来的Internet应用