开发网格应用程序

引言

大多数开发者在想到网格时，可能都会想起高压电缆和发电站组成的网络。实际上，网格本来的意思是一个互相连接的系统，这个系统被用来在一个广泛的区域内配送电流或电磁信号。因此，所有的电气和电子设备都可以通过插入到网络中来访问某些资源，这样就成了“启用网格”的设备。

大约在 1995 年，这个概念被应用到了计算领域。随着计算环境 ― 特别是因特网和宽带技术 ― 的发展，商业界出现了一种运动，就是应用这些新的、互相协作的技术与思想来解决金融业、国防研究、医药发明、决策制定和协作设计等领域的问题。网格计算计划曾经是把重点放在计算和高性能计算机上，现在它已经利用 Web 服务进入到了业务服务，比如业务流程外购这种更高级别的电子商务按需外购模型。

有许多开发者认为网格可以重新定义计算的性质，就象因特网改造了人们的交流方式那样。网格还可以改变来自不同组织和位置的人共同协作以解决某个具体的问题（如设计协作）的方式。这是典型的动态资源共享和信息交换。网格计算平台允许在一个分布式环境中发现资源、管理数据、调度在线资源并提供安全性。

网格技术标准化是由全球网格论坛（Global Grid Forum）（GGF，请参阅 参考资料）推动的。网格与 Web 服务的集成在技术上很复杂，不过又是很自然的事情。GGF 是一个由社区发起的论坛，论坛的参与者是从事分布式计算（或称“网格”技术）的个体研究人员和从业人员。GGF 是 网格论坛（Grid Forum）、 eGrid 欧洲网格论坛（eGrid European Grid Forum）和亚太地区的网格社区合并的产物。GGF 工作的另一个目标是开发有广泛基础的集成网格体系结构（Integrated Grid Architecture），这个体系结构可以帮助指导新兴网格社区的研究、开发和部署活动。GGF 的开放网格服务接口工作组（Open Grid Service Interface Working Group）正在定义“开放网格服务体系结构（OGSA）”。

这个系列的第 2 篇的内容是什么？ 这个系列的第二部分将重点讨论网格解决方案创建流程，该流程包括网格体系结构设计、网格服务开发及网格服务部署。

OGSA 是一种基于网格服务的分布式交互和计算体系结构，用来确保异构系统间的互操作性，这样不同类型的系统就可以进行通信、共享信息。它利用新兴的 Web 服务定义了 Web 服务定义语言（Web Services Definition Language（WSDL），请参阅 参考资料）接口。所有的服务都遵循指定的网格服务接口和行为。可以用三种级别来定义网格：

1. 企业（企业网格（Enterprise Grid））
2. 伙伴（伙伴网格（Partner Grid））
3. 服务（服务网格（Service Grid））

然而，OGSA 规范中的下列组件仍处于早期开发阶段：工厂（Factory）、注册中心（Registry）、发现（Discovery）、生命周期（Lifecycle）、查询服务数据（Query service data）、通知（Notification）和可靠的调用（Reliable invocation）。另一方面，OGSA 是一个系统合成模型，它用网络上的分布式资源执行特定的任务或解决富有挑战性的问题。

回页首

使用 OGSA 分发资源

OGSA 描述并定义了基于 Web 服务的体系结构，这个体系结构由一组接口及其关联的行为组成，用来方便在异构动态环境中共享分布式资源（请参阅 参考资料）。OGSA 依赖 WSDL 中对服务的定义，WSDL 定义服务访问的参数及其类型。OGSA 体系结构如图 1 所示。

图 1. OGSA 体系结构 

OGSA 背后的基本概念是，它是一个面向服务的网格体系结构 ― 一种特殊的 Web 服务，它提供一组遵守特定约定的定义明确的接口。这些接口解决发现、动态服务创建、生命周期管理、通知和可管理性等方面的问题。约定解决命名和升级问题。网格服务的标准接口包含多个绑定和实现（比如 Java 和 C# 语言）。这种网格服务可以部署在不同的托管环境 ― 甚至不同的操作系统中。OGSA 还提供了一种网格安全机制来确保服务间所有的通信都是安全的。所有的服务（持久的或瞬时的）都是用 Globus Toolkit 构建的。所以，OGSA 的基本思想等于网格结构加 Web 服务再加工具箱（Toolkit）。OGSA 中解决了两个重要的问题，即标准服务接口的定义和协议的识别。

网格服务接口的语义

OGSA 定义了网格服务实例的语义：它是如何被创建的、它是如何被命名的、它的生命周期是如何被确定的以及如何与它进行通信等等。目前的网格应用程序通常依赖本机操作系统作为它们的托管环境。创建新的服务实例要涉及到创建新的流程。在 OGSA 上下文中，托管环境（容器）主要负责确保它支持的服务遵守网格服务语义。这样，OGSA 就可以促进对容器／组件接口的修改或添加了。

OGSA 允许应用程序和用户创建瞬时服务、发现和确定可用服务的属性。OGSA Factory、Registry、GridService 和 HandleMap 接口支持创建瞬时服务实例，并支持发现与实际的组织相关联的服务实例以及确定这些服务实例的特征。

服务能力

服务能力（Service capability）（也就是某个公司或组织提供的服务）被当前的 Web 服务解决方案广泛使用。例如，送货服务可能具有在两天内将一个包裹送达目的地的能力，且收费不到 10 美元。同样，网格服务能力也可能是计算资源、存储资源、网络、程序、数据库等等。网格服务的特征由它们提供的能力来确定。网格服务实现一个或多个接口，其中每个接口定义一组通过交换定义好的消息序列（比如方法调用的输入参数）进行调用的操作。网格服务接口对应于 WSDL 中的 portTypes 。

服务的版本确定与升级

网格服务支持的 portTypes 集以及一些与版本确定相关的额外信息在网格服务的 serviceType 中被指定，后者是 OGSA 定义的一个 WSDL 可扩展性元素。复杂的分布式系统内的服务可以独立升级。因此，我们可以管理和表达服务间的版本确定和兼容性，这样客户机就不仅可以发现特定的服务版本，还可以发现与之兼容的服务。而且，不必打断客户机对服务的操作就可以对服务（和运行它们的托管环境）进行升级。目前的 Web 服务规范中没有提供这种增强了的功能。

软状态（Soft-state）管理

网格服务可以维护服务生命周期的内部 状态（以便把一个服务实例与另一个提供相同接口的服务实例区分开）。 网格服务实例（Grid service instance）这个术语指的是网格服务的某个特定的实例化。服务通过交换消息进行交互。内部状态的存在使得保证服务已经一次性收到一条完整的消息或根本没收到消息这种能力变得很重要。在这个基础上，我们可以构建广泛的更高级别的每操作语义，比如事务。OGSA 模型定义了一个标准接口（Factory）和任何服务创建服务都必须提供的语义。在一个结合了瞬时的、有状态的服务实例的系统中，必须提供一些机制来使与失败的操作有关的服务和状态恢复原状。

假设用户应用程序因为某种原因失败了。网格服务计算暂时还在继续，但如果没有其他方对计算结果感兴趣，就不再生成 keepalive 消息。由于应用程序出了故障， keepalive 消息停止了，网格服务实例最终超时，并通过释放它们使用的存储和计算资源终止。

网格服务部署与服务注册

图 2 展示了一个网格服务部署和发布示例的示意图。使用简单对象访问协议（Simple Object Access Protocol，SOAP）的远程过程调用（Remote Procedure Call，RPC）servlet 和网格服务的实际实现可以被部署到应用程序服务器（比如 WebSphere 或 Apache Tomcat）上。所有的调用消息都将被 SOAPRPC servlet 捕获，它把这些消息路由到相应的网格服务。

图 2. 网格服务部署与发布示例的示意图 

同时，可以把网格服务发布到 统一描述、发现和集成（Universal Description, Discovery, and Integration）（UDDI）注册中心（请参阅 参考资料）或 Web 服务检查语言（Web Services Inspection Language）（WSIL）文档（请参阅 参考资料）。UDDI 的设计使得我们可以在其中发布和搜索商业伙伴的业务及他们的网格服务。UDDI 注册中心是一个存储这种信息以及网格服务位置的中心。有两种类型的 UDDI 注册中心：公共的和私有的。您可以以应用程序开发者或服务提供者的身份把您的网格服务发布到 IBM、Microsoft、HP 或 SAP 掌管的公共 UDDI 注册中心。如果您想发布自己的私有网格服务或机密网格服务，就应该使用私有 UDDI 注册中心。但用于测试目的或小规模集成时，将您的网格服务发布到 WSIL 文档却是最容易的，因为 WSIL 不需要 UDDI 注册中心就能够进行网格服务发现、部署和调用。这是因为 WSIL 提供了对已存在的服务描述文档的引用进行聚集的方法（这些文档已经被用许多种格式编辑过了）。然后这些检查文档在服务提供点处被提供，或者通过可以放置在内容媒体（比如 HTML）中的引用使其可用。例如，定位 WSIL 的 URL 的格式可能如下所示：

http://www.myorg-wsd.com/inspection.wsil

而且，UDDI 注册中心和 WSIL 将被 WSIL wsiluddi 数据标记紧密地关联在一起。在 WSIL 中，引用指针被用来连接到发布在 UDDI 注册中心的业务或服务。

网格服务实例的创建与调用

用户应用程序在工厂上调用“创建网格服务（create Grid service）”请求，请求创建一个新的服务实例，并分配临时存储器以供这次计算之用。每个请求都涉及到用户和相关工厂之间的相互认证，接着是请求授权。每个请求都成功，结果是创建出了一个带某个初始生命周期的网格服务实例。同时还给这个新创建的网格服务实例提供了一个委托的代理凭证，该凭证允许这个实例代表用户执行更多的远程操作。由于网格服务是动态的并且是有状态的，所以每个网格服务实例都被分配了一个全局唯一的名称，即 网格服务句柄（Grid Service Handle）（GSH），它把一个特定的网格服务实例与其他所有的网格服务实例区分开来。

例如，“高级 UDDI 搜索服务（Advanced UDDI Search service）”使用它的代理凭证开始请求来自 UDDI 注册中心的数据，把中间结果放在本地存储器上。高级 UDDI 搜索服务还使用通知机制向用户应用程序提供对其状态的定期更新。同时，用户应用程序生成对它创建的网格服务实例的定期 keepalive 请求。

回页首

OGSA 开发工具：Globus toolkit

OGSA 的开发框架（OGSADF，请参阅 参考资料）可以被看作是传输和组织引擎（transport and marshalling engine）以及应用程序代码托管环境之间的粘合剂。OGSADF 的实现就是 Globus Toolkit，它来自开放源代码社区。

通过提供网格服务规范中定义的接口的基于标准的、可定制的实现，大多数网格行为对托管环境和应用程序代码都将是透明的。参考实现的另一个目标是例示关键的 OGSA 概念来帮助规范实现者、托管环境提供者和服务提供者。该实现的主要目的是提供一个框架，使得在网格环境中容易集成、开发和使用服务。

Globus Toolkit 建立在 SOAP、WSDL 和 WSI 等 Web 服务技术的基础之上，用来支持分布式状态的管理；轻量级的检查和发现以及异步通知。所有的外部组件都通过 WSDL 接口描述公开，这些描述是直接从 Global 服务规范中派生出来的。

Globus Toolkit 提供支持 Grids 和 Grid 应用程序的软件库。这个工具箱解决了安全性、信息发现、资源管理、数据管理、通信、故障检测和可移植性问题。作为示例，目前提供的安全性支持高度依赖被选择用来实现 OGSA 的开发和托管环境。

Globus Toolkit 提供了一个 GUI 框架来演示 OGSADF 的动态性质。图 3 显示如何使用发现（discovery）和检查（inspection）在服务变为可用时查找、查询和使用它们。它知道如何从 GSH 获取网格服务引用（Grid Service Reference，GSR），还知道如何把在 GSR 中发现的 WSDL 端口类型映射到一个 GUI 面板。服务提供者可以很容易地通过配置添加对新端口类型的支持。所有的 GUI 面板实现都被给予一个 GSH 和一个缺省的 GSR 端点以使服务调用支持某个特定的端口类型。

图 3. OGSA 网格服务浏览器 

如 OGSA 服务浏览器中所示，容器注册中心服务包含 Globus Toolkit 的 alpha 发行版中包含的多个示例服务。您可以把注册中心作为一张表（一个服务列表）或 WSIL 文档（一个 XML 文档）来查看。

您还可以使用 Globus 提供的轻量级发现和检查能力按名称查询服务。GUI 框架使所有的服务都自动成为查询和检查请求的目标。为 OGSADF 编写的所有服务都将公开一个针对检查的 WSDL 文件和一组 Service Data 元素，这取决于提供了什么服务。这意味着所有的 OGSADF 服务都将使用 OGSA 服务浏览器。您可以查看用 WSDL 描述的服务接口的详细信息。 清单 1演示了 Globus Toolkit2.0 的 alpha 发行版中包含的 Weather 网格服务示例的 WSDL。

一个 instanceOf 元素在清单 1 中作为网格服务定义的一部分出现。该元素使用 WSDL 服务元素下的可扩展性机制。handle 属性是这个服务的网格服务句柄（Grid Service Handle）。清单 1 中的端口绑定被用于描述用来表达操作、与操作进行通信的具体网络协议和消息格式。

客户机可以使用许多不同的模型来调用启用 OGSADF 的服务。任何支持 WSDL 的工具都可能有自己的编程模型。当前实现支持的一个可能的模型是：

1. 根据 WSDL 定义生成一个代理
2. 从一个众所周知的注册中心中的服务（该服务支持步骤 1 中使用的端口类型）获取一个 GSH
3. 用 GSH 的 WSDL 选项调用 HTTP GET 来获得 GSR 并解析端点 URL
4. 向步骤 1 中生成的代理传递在步骤 3 中找到的端点 URL，然后开始调用服务

如果绑定是 SOAP 协议的话，也有可能使用现有的工具，比如 WSTK 中的 Wsdl2Java （请参阅 参考资料）生成 SOAP 调用代理来调用网格服务。另一种方法是使用 Web 服务调用框架（Web Services Invocation Framework）（WSIF，请参阅 参考资料）来动态检测绑定协议和构建适当的调用代码。使用 WSIF 的免代理调用代码的输入可以包括 WSDL 的位置、方法名和这个方法的输入参数。绑定协议可以包括 SOAP、CORBA、DCOM 等。

图 4 中演示了两种可能的调用方法和详细的调用流程。

图 4. 网格服务调用样本图

图 5 显示了用户可以怎样使用 OGSA 服务浏览器来创建一个名为 MyWeatherInstance 的网格服务实例。可以在服务实例被创建之前设置初始生命周期。

图 5. 网格服务实例的创建

使用 WeatherFactoryService 创建了网格服务实例后，您将看到正运行的实例页面。然后，使用 OGSA 服务浏览器作为网格服务客户机，您可以输入自己的邮政编码。然后将从 XMethods（它是一个网关，可以连接 Weather 信息服务提供者）获得您所在地区的温度值。结果显示在图 6 中，是 74.0。

图 6. 调用 Weather 网格服务的结果

回页首

使用 Web 服务增强 OGSA

目前 OGSA 的工作是从 IT 基础架构外购开始的。在我们看来，OGSA 的下一阶段应该包含更高级别的外购：业务流程外购。从 OGSA 规范来看，有可能用不同的方法实现和合成网格服务。例如，一个支持同时发生多个服务绑定并使用多个计算资源的旅行计划服务可以被实例化为一个服务实例，与作为库的应用程序链接在一起，或组合成更高级别的服务。我们将称之为 合成的网格服务（composite Grid service）。

实际上，现有 Web 服务中的大多数都可以按照体系结构和特定的技术组件被设计成网格计算空间。例如，基于 Web 服务的 B2B 集成中心可以被当作是电子商务所需的典型集线器风格的网格计算系统。换句话说就是，每个服务都可以当作网格服务来部署，这样，其他使用 SOAP 的应用程序就可以使用和访问它。一般情况下，提供基于网格的 Web 服务的公司在网格系统（可以通过 Web 服务把它们销售给伙伴或订户）上创建有价值的数据时都会开辟出新的收入渠道。可以增强当前网格计算基础架构的其他技术组件包括：

• 高级 Web 服务发现引擎（Advanced Web Service Discovery Engine）：可以用来增强 OGSA 以发现网格服务。 Business Explorer for Web Services（BE4WS）就是高级 Web 服务发现引擎的一个示例，可以从 IBM alphaWorks 上获得这个示例。它提供一种高效率的方法和统一的接口来使用 UDDI 搜索标记语言（UDDI Search Markup Language，USML）搜索脚本而不是通过较低级的 Java API 来发现 Web 服务（请参阅 参考资料）。
  
• Web 服务关系语言（Web Services Relationships Language，WSRL）：可以用来增强 OGSA 以定义网格服务间的复杂关系。基本的 Web 服务信息用 WSDL 描述。但 Web 服务的相关数据的一个重要部分是业务实体、企业服务和操作间的关系，这些关系是合成和执行动态业务流程的关键。但当前的 Web 服务规范和 UDDI 规范却缺少对这些关系的定义和描述。WSRL（请参阅 参考资料）以不同的粒度捕获了 Web 服务关系（我们将把这些关系看作选择和合成满足客户需求的正确服务集的重要辅助器），包括：
  • 企业与企业的关系（Business-Business Relationship，BBR）
  • 企业与服务的关系（Business-Service Relationship，BSR）
  • 服务与服务的关系（Service-Service Relationship，SSR）
  • 企业与操作的关系（Business-Operation Relationship，BOR）
  • 服务与操作的关系（Service-Operation Relationship，SOR）
  • 操作与操作的关系（Operation-Operation Relationship，OOR）
  
  
• Web 服务合成（Web Services Composition）：可以用来增强 OGSA 以根据一些最优化的服务选择机制和合成模式使用现有的网格服务合成新的业务流程。
  
• 自适应 Web 服务调用机制（Adaptive Web Service Invocation Mechanism）：可以用来增强 OGSA 以执行可靠的和动态的网格服务调用。为进行动态 Web 服务调用，这种机制应该能够自动执行方法说明适应（包括输入和输出）。元 WSDL（Meta-WSDL）（请参阅 参考资料）是一种通用的 XML 表示，用来传送 WSDL 的语义信息（比如描述和量化输入与输出参数的信息）。当需要进行单元间的转换时，这种单元信息尤其重要。例如，得到的输入是以盎司为单位，但 Web 服务要求的单位是公升。因此，在调用 Web 服务之前就必须把输入从盎司转换为公升。类似地，英尺和米、磅和千克等等之间也需要进行转换。对于输出来说也是如此。也就是说，Web 服务可能以摄氏度为单位提供输出，而客户可能要求数据以华氏度为单位。通过提供元数据并用 MetaWSDL 描述它们，OGSA 可以正确地、自动地使输入适应 Web 服务调用，而无须人工干涉并且还可以使输出参数适应 Web 服务调用。
  
• 网格服务供应和订阅（Grid service provisioning and subscription）：我们如何宣传网格服务呢？我们怎样才能向企业用户和最终用户提供网格服务呢？用户如何订阅网格服务呢？所有这些问题都应该能在将来的 OGSA 规范中得到解决。