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一直保持高品质的内容质量，为我们带来更多好的文章。

网格服务的标准由WS-Resource Framework (WSRF) 过渡到了WS-ResourceTransfer (WS-RT) 框架，WSRT在WS-Transfer的基础之上，增加了WSRF标准与WS-Management标准的特性，以便在不同组件之间方便的交换资源信息。

网格为异构资源提供了在结构化的、受管的系统中进行通信和互操作的能力。在网格计算环境下，状态信息的保存十分重要。在Globus体系中，分布式异构计算环境的Grid Service在Web Service的基础上进行扩展，将状态信息加入到无状态的服务之中，并提供构建有状态Web服务的API。

HTTP协议本身是无状态的，即服务器通过HTTP无法得知客户机是否已经关闭等状态信息。如果需要在资源传输中保持HTTP连接状态，需要由客户端保存的Cookie或服务端保存的Session来为HTTP记录用户的状态信息，再次与服务器取得连接时，就可以读取存放于HTTP响应头中的用户状态信息。

同样，一般的Web服务是不需要包含资源状态信息的。Web服务中，消息传递、服务描述、工作流描述、服务发现与集成四个部分都以松散耦合方式连接，服务交互由序列化XML进行描述。服务客户端在根据WSDL描述提交参数之后，一次调用在服务端执行的处理并得到返回结果，即可完成服务执行的整个过程。然而，WSRF协议为Web服务提供了有状态资源的管理方式，而WSRT则在WS-Transfer的基础上，增加了WSRF的WS-ResourceProperties和WS-ResourceLifetime两个组件的功能。

网格技术在分布、异构的资源基础上实现资源共享和协同工作，从OGSA到WSRF再到WSRT，Globus采用可以保存资源状态信息的Web服务标准一直处在不间断的进化之中，为网格技术的实现提供有效的支撑环境。

在OMII-UK支持下的网格计算项目OGSA-DAI新近发布了3.0版本，在OGSA-DAI项目的下载页，还包含3.0版本的拓展包以及实现分布式数据查询处理的OGSA-DQP 3.2版本。

OGSA-DAI项目由于实现网格环境下的数据访问与集成，针对结构化数据资源提供可拓展的编程框架。在DAI支持下，无论是数据库、文件还是其他形式的异构数据，都可以整合在网格环境下，并且允许这些资源可以通过Web服务的方式访问。更重要的是，OGSA-DAI提供了以数据为中心的工作流处理引擎，可实现数据访问、更新、转换和传递等操作。

OGSA-DAI 3.0可以说是非常重要的一次版本升级，首先针对工作流单元做了简化，并且进一步加强DAI的拓展性和标准化，使工作流的构建更为方便。在单个工作流之中，可以同时存取多种数据源，并且支持数据流并发操作。DAI中经过重构的资源和服务部分，增强模块化并减少了功能上的重复。OGSA-DAI分别提供了与Axis 1.4和Globus Toolkit 4.0.5相适用的版本，帮助开发者整合集成建立在DAI之上的数据应用。

由于OGSA-DAI 3.0几乎完全重写了OGSA-DAI 2.2版本的源代码，所以对于之前版本的应用开发，在向后兼容性方面已经无法保证。由于JDK 1.6之中对Java.SQL的API进行了较多改动，所以OGSA-DAI 3.0依然是JDK 1.5下编译发布，不过DAI团队准备在近期发布针对于1.6版本的补丁包。同时由于标准的Oracle JDBC驱动，不符合通过JDBC API插入BLOB字段的规范，所以对于Oracle数据库，DAI仍不支持插入BLOB字段。更多细节，可以在OGSA-DAI 3.0的用户手册中读到。

OMII是由英国EPSRC资助的网格计算研究机构，研究机构位于Southampton大学，其中OGSA-DAI的研究机构位于Edinburgh大学，研究团队都致力于将网格技术带入到实际的e-Science项目之中。在最近OGF的第21次会议资料中，也可以通过DAI开发者对于项目的 介绍文稿来了解3.0版本的最新进展。