OGSA-DAI分布式数据源访问与集成中间件包含的工作流引擎能够完成数据资源的访问、更新、传输、联合与交付工作，其最新的4.0版本已经释出。在这个里程碑中，OGSA-DAI新增特性如下：

• 增加OGSA-DAI SQL Views组件，能够与数据库视图交互进行读取操作。SQL Views在实现上多处使用了与DQP相同的SQL解析器；
• 集成高级数据挖掘与集成项目ADMIRE为DAI提供的通用行为。对于返回的一系列结果元组，允许使用脚本语言完成元组的连接或转换操作；
• 支持使用Apache Commons DBCP同基于JDBC的关系型数据资源建立连接，通过Commons-Pool创建与数据服务之间的连接对象，并访问数据资源；
• 数据接收器和数据源操作支持顺序数，在网络中断的情况下允许客户端重新同步；
• DAI数据接收器和数据源支持非阻塞读写操作；
• 增加OGSA-DAI工作流的执行情况跟踪页面；
• 提供服务器文件缓存行为，能够将缓存数据写入服务端文件保存，并提供RESTful形式的访问接口；
• 给出将OGSA-DAI结果元组转换为KML格式文档的Activities行为；
• 改进的配置和部署方式，使得完成复杂配置和在服务器之间拷贝配置文件更为简便；
• OGSA-DAI升级到Java 1.6环境下编译运行。

在更新的特性中，个人认为比较有用的是通过Apache Commons DBCP连接池与DAI服务进行交互，工作流引擎执行情况跟踪，以及KML格式的元组转换功能。在资源部署方面，先前部署资源和行为的ANT脚本由简单的配置命令代替，并且不需用ANT脚本进行GAR打包，而是仅将包含配置文件的目录拷贝到WebApp下的WSRF文件夹中。OGSA-DAI 4.0的文档也进行了同步更新，感兴趣的朋友可以访问OGSA-DAI文档获取更细节的内容。

OGSA-DAI通过数据服务对后端单个数据源查询，将整串SQL语句推送给后端数据库执行查询。而在面向分布式数据源的DQP查询中，组合查询在中间层被解析为针对不同数据源的子查询，子查询通过DAI数据服务获取查询结果，并在DQP中间层对不同数据源返回的结果进行组装，并返回给请求用户。

通俗来讲，DQP分布式数据服务查询类似于一个MapReduce过程，现将针对异构分布式数据源的复合查询语句解析拆散，提交给对应不同数据源的DAI服务进行查询，再将多个数据服务的返回结果汇总，有DQP中间层组装得到最终的查询结果。

现在的问题是，SQL语句在查询过程中允许嵌入查询函数，比如Count( )、Avg( )、Max( )、Min( )等聚合函数，甚至空间数据库中支持的ST_Buffer( )、ST_Union( )等空间分析函数，在查询过程中进行一定的数据处理操作。但DQP查询在查询语句分解时，由于复合查询语义分析的二义性，不能在将嵌套函数传递给子查询。为了弥补嵌入函数的操作，DQP提供了一种在中间层处理数据的UDF（用户自定义）函数拓展方式，使得函数处理过程，在子查询返回结果后由DQP中间层完成函数计算。

DQP已定义了基本的标量(Scalar)和聚合(Aggregate)函数，并为用户自定义函数提供了拓展接口。比方说我们在查询语句中定义一个缓冲区分析函数Buffer( )，其功能实现调用自JTS库提供的缓冲区分析API。Buffer操作需要返回每一列缓冲区分析结果，属于标量函数，需要继承LogicalExecutableFunctionBase类。同时，Buffer操作接受空间数据库子查询返回的Geometry类型输入数据，并需要用户在编写查询语句时给定一个Double型的缓冲区距离参数。

通过PostGIS驱动，子查询能够返回WKT格式的空间数据，DQP将返回数据以Parameters对象传入，我们可以使用JTS库的WKTReader( )读入返回的WKT数据并传给geom对象，再以类似Geometry result = geom.buffer(distance);的JTS调用完成缓冲区分析处理，并将结果以Object对象返回给DQP查询结果装配器，即可实现分布式查询中的空间分析函数嵌入工作。标量函数的拓展示例参见这里。对于聚合函数，则需要继承SQLAggregateFunction类，实现过程不在赘述，示例参见这里。

通过自定义函数的拓展，可以进一步丰富DQP分布式查询的功能和适用性。DQP对于复合查询的解析，应该是基于ANTLR提供的语法解析功能实现的，语法解析过程以后有时间研究一下再写出来。

根据OGSA-DAI项目组成员在OGF-28研讨会中公开的的开发线路图，OGSA-DAI 4.0将在2010年的4月份发布，更新的内容包括DQP的优化和拓展，增加SQL Views查询器，改进通用Activities，增加KML行为以及3.x版本中已报告的Bug修改等。

近3年时间里，我对OGSA-DAI项目始终保持关注，也在邮件沟通中认识了一些项目背后的开发者，他们一直在贡献代码和文档来推动着项目进程。希望DAI项目能够持续推进，并且在易用性方面得到进一步改善。

OGSA-DAI是用于分布式异构数据源访问和集成的网格中间件。在新近发布的3.2.x版本中，DAI在功能和易用性方面得到不少改进。

在OGSA-DAI 3.2版本中，最重大的改进是将分布式查询组件DQP进行重写，作为一个组件包含在DAI安装包中，无需之前版本在配置DQP时的DQP Evaluator和DQP Coordinator部署包。通过配置文件加载后的DQP资源，也作为DAI资源和行为(Activities)以标准DAI服务的形式存在，并可通过DAI的SQLClient进行分布式查询，极大简化了DQP配置和使用。

值得关注的是，具备拓展数据类型和函数的关系型数据库，如PostGIS空间数据库，3.2之前版本的DQP分布式查询无法读出包含拓展字段类型如Geometry类型的Schema表结构，而新版本中DQP资源以DAI资源形式对外暴露接口，且DAI支持关系型数据库拓展的JDBC列类型到DAI元组类型的元数据抽取和映射，所以可以读出空间数据库的Schema表结构，并对多个空间数据源进行分布式查询。但在DQP查询过程中，需使用OQL对象查询语句针对异构数据源进行拆分组合，所以DQP查询还不支持直接在SQL语句中嵌入空间分析函数。可行的方法是，对DQP查询进行自定义Functions拓展，加入后端空间数据库支持的空间操作函数。

此外，新的DQP索引页面dqp-index.jsp也可以在安装后查看已加载的DQP资源，其中包含DAI数据源信息、DQP数据字典、所有可以查询的表名和字段信息等。同时，DAI 3.2还更新了之前的dai-manager.jsp页面，新增了DAI资源列表dai-resources.jsp，DAI行为列表dai-activities.jsp，配置键值对dai-config.jsp，容器环境键值对dai-context.jsp，请求监视器dai-request-monitor.jsp等多项DAI服务信息页面。

DAI 3.2版本还启用了新的资源监控框架，用于跟踪工作流执行过程中每个Activities产生和消费的数据块的情况。同时，并优化了GridFTP行为的执行效率。在最新的OGSA-DAI 3.2.1版本中，还对已经发现并提交的一些Bug进行了修复。感兴趣的DAI使用者可以查看更新说明，以获取更多细节。

DAI 3.2提供了新的功能并在操作上做了简化，在Ubuntu 9.10下实际安装配置也很顺利，但在版本兼容性方面，测试了DQP提供的GUI组件ogsadqp-3.2.1-od30port，以及驱动程序OSGA-DAI:JDBC都已无法适用于新的DAI 3.2版本，需要等待组件升级或自己在原有基础上修改代码进行定制。

OGSA-DAI:JDBC驱动，是OGSA-DAI网格中间件客户端工具的拓展项目，符合Sun JDBC接口v2.0规范，用以帮助开发者通过符合JDBC标准的Java代码与数据服务资源交互。

通常情况下，在DAI安装与数据服务资源部署之后，需要运行环境变量设置脚本setenv.sh加载依赖类库，即可以在命令提示符下，使用DAI自带的SQLClient客户端向服务转入SQL脚本并执行数据资源查询。查询时需要指定的参数包含：服务资源URL地址，数据资源ID（代表与哪个数据源建立连接），以及SQLQuery查询串。

但以命令行方式使用OGSA-DAI客户端，在与网格数据服务交互方面并不方便，OGSA-DQP提供了针对分布式查询的GUI客户端，帮助使用者添加查询计划，并生成OQL查询解析树。但如果计划将已有JDBC应用数据源迁移到DAI服务之上，使用OGSA-DAI:JDBC驱动则更灵活，开发者可以通过一般JDBC的处理方式，操作DAI上部署的各类数据服务，甚至可以使用Hibernate或JPA等ORM层，来构建DAI:JDBC之上的实体关系映射。

OGSA-DAI:JDBC驱动目前最新为0.1版本，在使用时首先需要加载JDBC Metadata Activity，来帮助DAI:JDBC获取后端关系型数据库的元数据信息。之后需要将MetaDataMethodActivity部署在OGSA-DAI中，并设置已有DAI Resource关联新部署的Activity。重启服务容器之后，在dai-manager.jsp监控页面中，就可以看见刚部署的Activity出现在DAI Resource下的行为列表中。

在OGSA-DAI:JDBC驱动编码方面，首先通过语句Class.forName(”br.usp.pcs.lahpc.ogsadai.jdbc.Driver”); 来告知JVM查找并加载指定的JDBC驱动类，之后通过DriverManager.getConnection(”jdbc:ogsadai://localhost:8080/wsrf/services/dai/datasource”); 语句指定访问服务的URL地址和数据资源名称，接下来便可以用JDBC的方式通过PreparedStatement来传入待执行的SQL串，调用execute()函数执行查询，并通过getResultSet()函数获取数据库查询后的结果集。

实际测试中，发现OGSA-DAI:JDBC驱动目前还存在一些问题，与作者邮件联系后确认：驱动对直接在Globus Container中部署的DAI服务支持良好，但如果Globus WS Core和DAI部署在Tomcat中，需要在添加DAI:JDBC依赖项的同时，添加一堆额外的DAI SQLClient运行库，才可以保证代码正常执行。目前版本还在不断修正之中，感兴趣的开发者可以关注OGSA-DAI:JDBC的后续版本。

LCG计算网格（LHC Computing Grid）是专为处理欧洲粒子物理研究中心（CERN）建造的大型强子对撞机（LHC：Large Hadron Collider）所产生的数据而建立的计算网格项目。

由超过140个分布于世界各地计算机中心组成的LCG，将数据中心的计算和存储资源整合在一起，LCG所建立的基础设施对LHC每年预计产生的1500万GB的海量数据提供存储、分析和计算支持。

参与在LCG各个节点中的计算机，运行在CERN定制的Scientific Linux CERN 4(SLC4)操作系统之上。在CERN的资源页面中给出了所使用Linux发行版的介绍和下载链接。下一个版本的Scientific Linux CERN 5也处于测试中，将来可能会实际应用在LCG的节点之上。

监控与可视化工具GridView为LCG网格提供了高层次的功能监控视图，以可视化报表显示数据的传输状态、FTS文件传输、作业运行情况以及服务可用信息等内容。

除此之外，LCG之上还使用BONIC平台搭建了LHC@Home志愿式分布式计算，目的是吸引爱好者参加到LCG的数据处理之中。项目将计算任务分割，之后将任务包发送给个体的参与者进行计算。计算结果汇总到LCG之后，可以帮助CERN来获取粒子穿越27公里长隧道之后的模拟状态，用以调整实际加速时参数的精度。

尽管LHC在去年9月份由于冷却超导磁铁的液态氦发生洩漏而停止运转，将推迟今年夏天才恢复运作。但LCG的数据处理和计算工作并没有停滞，相信LHC恢复运行之后，LCG网格将会为这个最大的科学工程在数据分析处理方面提供更强有力的支持。

延伸阅读：LHC网格-为地球上最大的科学设施存储和分析数据（InfoQ）

Grid Engine是Sun发起的网格计算项目，为从集群到网格的计算环境提供了分布式的资源管理平台，以实现分布式网格计算的基础设施。在Grid Engine之中，已实现的特性包含在多个Grid Engine结点之间共享资源、根据用户所需请求和保存网格资源，同时Grid Engine具备良好的拓展性，以及强大的统计和报告控制台等功能。

在最新版的Sun Grid Engine 6.2中，保持工作负载透明的同时集成了服务域的动态管理功能，并且提高了可伸缩性、性能和易管理型的标准。支持服务域管理器的多重群集，并且，Grid Engine的伸缩性已经可以支持多达六万个核心CPU的同时工作，支持跨数千CPU内核的海量并行作业，可以帮助用户在其上搭建强大的云计算平台。

Sun Grid Engine目前已在生产环境中得到了应用，如过程模拟，模型预测等等。在一年一度的超级计算大会上，Sun还展示了Grid Engine计算的应用实例。目前已对外提供CPU计算服务的网格计算门户站点Network.com，其后台就是基于Grid Engine搭建。

感兴趣Grid Engine的朋友可以下载6.2版本的快速上手指南，其中包含Grid Engine的介绍和基本概念，Grid Engine的资源调度策略、计算环境和集群的搭建、Grid Engine的推荐配置等等。

除此之外，Sun的HPC Cluster Tools也为在高性能计算集群之上创建MPI应用提供了支持，并且通过VampirTrace和MPI PERUSE实现了并行计算的性能分析和优化工具，同时还提供了Grid Engine的插件支持。在Grid Engine以及OpenStorage在线存储机制等解决方案的支持下，构建自己的云计算平台正在变得触手可及。

Globus项目发布了最新的4.0.6版本，在安全性、数据管理、处理过程执行方面有了不少改进。最近决定在Ubuntu 7.10平台上安装Globus 4.0.6，过程比预计的要顺利一些。Globus安装的流程和步骤，基本按照QuickStart教程中进行，还有一份不错的排错指南也帮了不少忙。

由于通过源代码Build来进行安装的方式出错可能性较大，于是直接使用了Debian Sarge的安装包。值得注意的是，在安装过程中，需要启用Ubuntu的root用户，这样方便使用Globus的CA安全认证机制对用户提交的pem请求进行签名。还有，最好把Globus_Location写到环境变量里面，这样不用在每次启动命令行时用export命令导入。

在启动Globus Container之前，需要使得用户通过Globus的CA安全签名，否则会提示认证错误。容器的启动，也没有使用指南中的shell脚本，而直接通过Globus目录中的globus-strat-container命令启动，之后得到在Globus默认的8443端口启动的WSRF服务实例。

下面的实验还要慢慢做，初步的设想是：将写好的空间分析算法以WPS服务的形式从Tomcat迁移到Globus Container中发布，供基于uDig项目具备WPS插件的客户端调用。使用OGSA-DAI将异构数据源提供的矢量数据集成，在GeoServer中以WFS的方式发布，最好GeoServer也迁移到Globus Container中。uDig客户端加载WFS源数据，之后再调用网格容器中的WPS操作进行数据处理。

顺便提一下，OGC刚刚正式通过WPS成为Web处理服务的标准之一，脱离了之前Proposal的状态，看来符合WPS标准的服务处理以后应该会有不错的发展。

IBM developerWorks的网格专区，是我很喜欢并一直关注的板块，但不幸的是，今天IBM developerWorks的编辑团队宣布了专区即将关闭的消息：

非常感谢您一直以来对网格计算的关注，很高兴 developerWorks 可以为您提供关于网格计算方面最新信息。但是从现在起，网格计算专区今后将不再进行更新，因为我们决定关闭这个专区。

无疑，这个专区对关注网格计算的同学们很有帮助，尽管从国外翻译到中文有一个时间差，但是资料对网格方面的入门和及时详细了解技术资料还是很有帮助的。本来计划撰写一篇OGSA-DAI 3.0架构与应用方面的文章投稿给DW，现在看来也可以省了。

网格计算相关的技术一直以稳健的步伐向前发展，但离实际的应用还有一定的距离，一些面向商业应用的网格产品如IceGrid等往往与Globus也没有直接的联系。而IBM产品所涉及的网格计算环境，侧重于计算负载功能、信息与计算功能结合、信息和数据模型，采用标准面向服务的方式来管理计算和信息网格中的对象。

尽管对于关闭developerWorks网格专区的决定有些遗憾，但IBM对于新兴技术，一直都采取积极开放的态度，比方说我关注的Mashup资源和Ruby and Rails技术资源也在DW相继上线，为读者提供相关的技术资料。欣赏IBM DW一贯稳健专注的作风，为开发者提供各种技术最有价值的文章和教程，期望DW一直保持高品质的内容质量，为我们带来更多好的文章。