引言
大多数开发者在想到网格时，可能都会想起高压电缆和发电站组成的网络。实际上，网格本来的意思是一个互相连接的系统，这个系统被用来在一个广泛的区域内配送电流或电磁信号。因此，所有的电气和电子设备都可以通过插入到网络中来访问某些资源，这样就成了“启用网格”的设备。
大约在 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 的格式可能如下所示：
|
而且，UDDI 注册中心和 WSIL 将被 WSIL wsiluddi 数据标记紧密地关联在一起。在 WSIL 中，引用指针被用来连接到发布在 UDDI 注册中心的业务或服务。
[page]
网格服务实例的创建与调用
用户应用程序在工厂上调用“创建网格服务（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 规范中得到解决。
结束语
网格计算使用因特网把计算机群集或业务流程群集连接在一起形成一个强大的“超级计算机”。最后，因特网将变成一个单一的、统一的计算平台，使我们可以更快速地访问基础架构和其他业务应用程序资源。这是服务计算（Service Computing）时代。
在本文中，我们已经向开发者介绍了服务计算。我们还展示了如何使用最新的 Globus Toolkit 发现网格服务、创建网格服务接口和调用网格服务实例。本文还描述了一些帮助开发者把 Web 服务和网格计算集成在一起的想法。
[page]
IBM 对网格计算前景的概括如下：
“IBM 认为网格最终会成为因特网上的一个实用模型，在这个模型中，客户机就象获取电力一样获得计算机的计算能力。IT 预算的百分之六十多都花在了维护和集成上 — 这个百分比还在继续上升 — 降低复杂度和管理需求这种需要就成了当务之急。” — IBM Grid Computing 的总经理 Tom Hawk 于 2002 年 6 月 17 日在圣何塞召开的 Grid Computing Planet Conference and Expo 大会上这样说。
在这个系列的第二篇文章中，我们将看一下网格解决方案创建过程，其中包括网格体系结构设计、网格服务开发和网格服务部署。
（Open Grid Services Architecture，OGSA）的基本思想以及使用高级 Web 服务技术完善 OGSA 的一些想法。在本文中，Liang-Jie Zhang、Qun Zhou 和 Jen-Yao Chung 继续介绍网格解决方案体系结构，该体系结构包含基于逻辑和物理网格两种范畴的网格解决方案。他们还将使用 StockQuoteGrid 演示如何用 Globus Toolkit 开发和调用网格服务。
创建网格解决方案是为了使应用程序能够共享数据和计算资源，同时还能够用一种高效率的方式跨多个组织访问它们。在构建一个分布式解决方案时，我们需要一些标准的方法在多个位置共享和访问应用程序 — 随着公司的发展，这种方法会变得更加重要。其中一个关键问题是要找到更标准且伸缩性更好的方法在分布式环境内把数据和其他计算资源与应用程序集成在一起。
目前传统的基于软件的网格解决方案通常需要安装在防火墙后。这些“本地”网格解决方案不仅依赖于平台，而且相互之间还存在不兼容的通信协议。此外，它们提供的用来与其他“本地”网格通信的集成机制极少。由于专有接口的原因，向现有的“本地”网格添加来自不同供应商的新应用程序也非常困难。另一个问题是要找到一种方法以便快速而轻松地用一个安全的、成本低且易管理的解决方案把不同的“本地”网格提供的服务和外部业务流程集成在一起。
构建网格解决方案要面临的挑战
通常情况下，不同平台上的远程应用程序系统都是网格解决方案的一部分。构建网格解决方案时我们面临的难题包括：
全面的管理
资源供应
应用程序集成
数据共享和访问
活动监控
基于策略的网格管理机制
因此，我们应该找到一种方法来构建一个全面的管理系统，该系统要使解决方案创建者和管理员能轻松地注册一个新的网格服务，并且还能管理其他网格的概要文件。管理员或服务供应商将选择使特定的计算资源对网格解决方案是可见的。我们把这个过程称为资源供应（Resource provisioning）。还应该应用相应的授权机制来保护资源的安全并使特定的请求者可以访问它们（特定的请求者可以是一个应用程序、一个长时间运行的业务流程或者另一个网格解决方案）。我们在前面的文章中已经讨论过，应该把敏感数据、私有应用程序和机密信息分派到确实私有的地方，比如私有的统一发现、描述和集成（Universal Discovery, Description, and Integration，UDDI）注册中心，它提供特殊类型的应用程序。应用程序请求者需要统一的数据访问机制来共享和访问数据以及应用程序。另外，还应该创建资源管理器来访问位于不同网格的资源。
网格的目的是利用计算资源（而不必考虑资源所在的位置或平台）来执行涉及到各个方面的任务。例如，某个国家的某个地方的一些个人计算机设计师与正在设计不同计算机组件的这个国家其他地方、甚至其他国家的其他设计小组成员合作创建电脑辅助设计（Computer Aided Design，CAD）绘图。那么每个组怎样才能共享设计文件、访问设计更改和进行修改呢？这是网格解决方案中典型的设计合作案例。并且，网格解决方案已经被构建为支持精密计算研究，比如药物研制、财政分析、动态能量分配、国防研究和天气预报。（请参阅参考资料）。
因此，我们必须找到一个灵活的解决方案体系结构使多个合作者能够用一种安全且易管理的方法共享资源。稍后在本文中，我们将介绍一个网格解决方案体系结构，该体系结构包含基于逻辑和物理网格两种范畴的网格解决方案，还包含一个基于外购服务的业务网格（Business Grid）框架。我们将以 StockQuoteGrid 为例演示使用 Globus Toolkit（请参阅参考资料）开发和调用网格服务所需的详细过程。
网格解决方案体系结构
在我们看来，每个网格解决方案都可以配置成两类网格：物理的和逻辑的，如图 1 所示。物理网格指的是可以在分布式网络上共享的计算机计算能力和其他硬件资源。这是为特定的任务预定义的配置。逻辑网格指的是软件和应用程序共享以及更高级的业务流程共享。从理论上说，物理网格可以作为被多个逻辑网格（它们提供特定的功能）使用的组件网格。一个逻辑网格可以由多个物理网格构成，这些物理网格共同合作来执行某个特定的任务，比如天气预报和财政分析。一般情况下都可以根据客户的需求动态配置逻辑网格。一个典型的物理网格是计算机计算能力共享基础架构。数据网格是一个逻辑网格示例，在需要时它利用多个现有的物理网格。
图 1. 网格解决方案体系结构
在图 1 所示的网格解决方案体系结构中，我们需要允许管理员控制对网格资源的访问并使用户或应用程序可以访问网格资源。至于开发，您可以使用 OGSA 和 Globus Toolkit，它们解决了安全性、信息基础架构、资源管理、通信、错误检测和移植性等问题。OGSA 是一个面向服务的网格体系结构（请参阅参考资料）。网格服务是 OGSA 的基本概念。它是一种特殊的 Web 服务，提供一组定义完善的接口并且遵守特定的约定。网格服务的接口解决了查找、动态服务实例创建、生命周期管理、通知和易管理性等问题；网格服务的约定解决了命名问题及升级问题。这种网格服务可以部署在不同的托管环境，甚至不同的操作系统中。OGSA 还提供了一种网格安全机制来确保服务间所有的通信都是安全的。所有的服务（持久的或瞬时的）都是用 Globus Toolkit 构建的。
图 2 演示了一个集线器风格的网格解决方案系统，该系统使用逻辑网格来实现服务外购。这个解决方案案例是一个典型的用于业务流程集成的合作式逻辑网格解决方案。所以，我们还把这种逻辑网格称为“业务网格（Business Grid）”。在图 2 中，每个服务都可以作为网格服务部署，这样其他的应用程序就可以通过标准的通信协议（比如简单对象访问协议（Simple Object Access Protocol，SOAP）使用和访问它。
业务网格可以连接到业务网格（集线器）自身托管的或注册了业务网格的服务提供者托管的所有服务。应用程序客户机可以使用 XML、HTTP 上的 SOAP、SMTP、FTP 或 MQ 协议连接到业务网格。业务网格与外部的旧应用程序、Web 服务提供者、客户的供应链管理（Supply Chain Management，SCM）、供应商的企业关系计划（Supplier's Enterprise Relationship Planning，ERP）或合作伙伴的客户关系管理（Partner's Customer Relationship Management，CRM）进行通信。业务网格通过提供会员资格管理服务、数据格式转换服务、业务协议转换服务、高级查找服务和业务流管理服务来负责提供互操作性，以便连接到使用不同传输、数据格式和业务协议的多方参与者。
图 2. 一个网格服务外购示例图
另外，业务流程还包含许多业务交互，这些业务交互带有有状态、长时间运行的涉及到两方或更多方的交互。随取即用的业务流程是下一代电子商务的更高级需求。例如，图 2 中所示的 Enterprise A 的业务流程由多个外购的网格服务（比如来自 Enterprise B 的 Purchase Order Creation 网格服务、来自 Enterprise B 的 Credit Checking 网格服务以及来自 Suppliers 的 Shipping 网格服务）组成。因此，外购客户仅需的软件是 Web 浏览器或处理 SOAP 通信的轻量级连接适配器。企业客户不需要安装昂贵的软件。例如，客户可以使用 Web 浏览器注册业务网格。对于每个用户，他们的角色可以被指定为提供网格服务的一般用户（regular user）、业务管理员（business administrator）、服务供应经理（service provisioning manager）和服务订阅经理（service subscription manager）。
业务网格可以与多个本地网格（比如 Supplier 的本地网格和 Enterprise B 的本地网格）进行交互，如图 2 所示。业务网格是一个用来进行外购的中心框架，它包含多个已连接的本地网格。每个网格都可以有买方、供应方、服务提供者和贸易伙伴。业务网格框架可以有多个虚拟的业务网格，如果需要的话，这些网格可以共享同一信息基础架构并互相交互。
网格服务开发与调用
接下来，我们将介绍网格解决方案体系结构（Grid Solution Architecture）这个概念，随后再介绍我们用 OGSA Toolkit 构建的示例。为方便起见，我们已经创建了一个股票报价网格服务（Stock Quote Grid Service），它就在 OGSA 软件包中。它与 OGSA Globus Toolkit 中包含的天气网格服务（Weather Grid Service）有类似的打包风格。这部分将演示如何编写插入到 OGSA 的解决方案框架内的网格服务。按照 OGSA 开发框架（OGSA Development Framework，OGSADF）（请参阅参考资料），编写一个服务并将它插入到框架中需要下面的五个主要步骤：
1、为网格服务定义创建 WSDL
2、为 WSDL 定义生成 Java 代理
3、编写服务端实现代码
4、编写客户机端实现代码
5、用 OGSA 服务浏览器部署并测试网格服务
所以您可以为服务提供自己的 WSDL 定义，也可以使用内建的 ant 目标根据 Java 接口创建 WSDL 文件。核心服务接口是网格服务（Grid service）、工厂（factory）、注册中心（registry）、通知（notification）和句柄映射（handle map）。服务定义被用作组成服务实现的构件。在我们的示例中，将开发一个股票报价网格服务，如图 3。这个股票报价网格服务被部署在 Apache Tomcat 上，后者是 Apache 的一个应用程序容器，它将调用部署在 IBM WebSphere Application Server 上的股票 Web 服务（请参阅参考资料）。
图 3. 本地网格平台
股票网格服务实现是一个可设定地址的、并可能会有状态的实例，它实现了聚集 serviceType 上下文中的 WSDL portType 所描述的一个或多个接口。清单 1 显示了描述股票网格服务的 WSDL 文件（stock_service.wsdl）。这个网格服务的名称是StockService。name 属性为外围的 WSDL 文档中定义的服务提供了唯一的名称，使所有这些服务都可以区分开来。这个 WSDL 文件引用了两个文件（在清单 1 中突出显示）：stock_bindings.wsdl 和 stock_port_type.wsdl。
清单 1. 股票网格服务（WSDL，stock_service.wsdl）
清单 1 中显示的 WSDL 文档定义了两个端口：StockPort 和 GridServicePort。端口通过为一个绑定指定一个地址来定义一个独立的端点。name 属性为 WSDL 文档内定义的每个端口都提供一个唯一的名称。binding 属性用 WSDL 定义的链接规则引用绑定。这个 WSDL 描述一个 SOAP 请求可能会被通过 SOAP HTTP 绑定发送到 StockService 服务。
清单 2 中显示的 stock_bindings.wsdl 文档描述了一个 getQuote 或 setSymbol SOAP 请求可能会被通过使用 SOAP HTTP 绑定发送到 StockService。stock_port_type.wsdl 文档被导入到 stock-binding.wsdl 中。
清单 2. 股票网格服务（WSDL，stock_bindings.wsdl）
在清单 3 中，portType 是网格服务接口的一部分。这个文档中已经定义了操作名（也就是网格服务内的方法名）和输入／输出参数。客户机工具将使用这些信息识别一些 portType 与单个服务之间的所属关系，这样它就可以正确地生成客户机代理，并且能够正确地绑定存根。这些信息还可以被客户机用来简化股票网格服务支持什么 portType 的发现。
清单 3. 股票网格服务（WSDL，stock_port_type.wsdl）
除 UDDI 注册中心外，还可以将网格服务发布到 WS-Inspection Language（WSIL）文档。在目前的 OGSA 实现中，它只支持把网格服务发布到 WSIL。WSIL 不需要 UDDI 注册中心就能够发现、部署和调用网格服务。但 OGSA 可能会在不久的将来支持 UDDI 注册中心。
现在，我们来研究一下详细的网格服务实现。实现一个服务的简单方法是从 ServiceSkeleton Java 类继承，然后实现端口类型接口中的所有操作，这些接口已经在先前的步骤中生成了。清单 4 中显示了股票网格服务实现。就象先前图 3 中显示的那样，这段代码的基本思想是使用 Globus 包和常规的 Java 包调用股票报价 Web 服务。
清单 4. 股票网格服务实现（StockImpl.java）
在刚才的清单 3 中，突出显示的代码（用蓝色显示）演示了股票报价 Web 服务，该服务部署在“zhanglj”这台机器上。图 4 显示了关于股票报价 Web 服务的已部署服务信息。这个 Web 服务的标识是 urn:xmltoday-delayed-quotes。它是一个 Java 应用程序，带有一个方法：getQuote。
图 4. 部署在 WAS 4.0 上的股票报价 Web 服务
接下来，我们需要为股票网格服务创建一个服务工厂（Service Factory）。股票网格服务工厂将被用来创建给定 serviceType 的实例。每个股票网格服务实例都有一个唯一的标识（例如稍后将在图 6 和 图 7 中显示的 MyStockGridService），以便与系统中的其他实例区分开。
我们已经编写了一个类，它继承 FactoryServiceSkeleton 并提供了 createServiceObject 方法的一个实现来创建清单 4 中创建的一个服务实现的实例。清单 5 中显示了 StockFactoryImpl.java。
清单 5. 股票网格服务工厂（StockFactoryImpl.java）
创建了股票网格服务后，我们就可以用 OGSA 服务浏览器查看部署在样本服务容器内的所有网格服务。如果您想用 OGSA 服务浏览器创建股票网格服务实例并调用它，则必须编写几行代码来创建一个 GUI 以允许用户输入参数并在屏幕上看到执行结果。看一下 OGSA toolkit 包中包括的样本代码就可以很轻松地创建出这样一个 GUI。
在图 5 中，我们可以发现新创建的股票网格服务（样本股票服务）显示在根据 WSIL 文档创建的网格服务列表中。我们还可以使用这个服务浏览器在这个网格服务注册中心查看 WSDL 文档和 WSIL 文档。
图 5. 网格服务注册中心
我们在本系列文章的第 1 部分中已经提到过，OGSA 使应用程序和应用程序用户能够创建瞬时服务，并且还能够发现可用网格的属性并对这些属性求值。OGSA 工厂、注册中心、网格服务和 HandleMap 接口涵盖了在实际的组织内创建瞬时网格服务实例、发现和描述服务等方面。我们可以使用 OGSA 网格服务（OGSA Grid Service）浏览器创建图 6 中所示的名为 MyStockGridService 的实例。
图 6. 网格服务实例的创建
用户应用程序调用工厂接口上的“创建网格服务”请求来创建新的服务实例。新创建的与网格服务接口相关联的服务实例将被自动分配计算资源。同时，在服务实例被创建之前就可以为该实例指定初始生命周期。就象电子商务解决方案中的单一登录一样，新创建的服务实例将保存用户凭证以便与因特网上的其他系统进行进一步的交互。新创建的网格服务实例将被自动赋予一个名为网格服务句柄（Grid Service Handle，GSH）的全局唯一名称，该名称被用来把这个特定的服务实例与其他的网格服务实例区分开。
除使用 GSH 外，还可以通过使用网格服务引用（Grid Service Reference，GSR）访问股票网格服务实例。GSH 和 GSR 都被链接到了应用程序服务器托管的特定网格服务实例上。客户机应用程序可以使用 GSR 把 SOAP 请求直接发送到特定的实例。
现在，我们可以设置股票符号并从因特网获取股票报价。这些价格信息被部署在机器“zhanglj”上的 StockQuote Web 服务检索。作为图 7 中显示的一个示例，我们把股票符号设为“IBM”。然后，我们可以调用网格服务实例来获得最新的报价信息。返回的价格是 $79.35（2002 年 8 月 17 日 10:00AM）。
图 7. StockQuote 网格服务调用
结束语
在本文中，我们已经介绍了网格解决方案体系结构这个概念以及用来进行网格服务外购的“业务网格”方法。然后，我们给出了一个本地网格平台示例，它将 Web 服务封装在网格服务的实现中。此外，我们还演示了使用 Globus OGSA toolkit 创建和调用网格服务的详细过程。
网格计算与 Web 服务的集成仍处于早期阶段。把网格计算引入业务服务（流程）外购在不久的将来将依然是一个充满挑战和希望的研究课题。我们可以利用 Web 服务与 OGSA 来构建电子商务解决方案基础架构。同时，我们还可以使用网格计算平台来共享和访问因特网上的计算资源。随着自主运算（Autonomic computing）— 这种运算管理已创建的解决方案基础架构 — 的发展，OGSA 会成为把电子商务推向未来的关键。
致谢
作者在此要感谢 Global Grid Forum、Globus.org 和其他组织及个人，他们提供了本文中介绍的网格计算和 OGSA（包含在 Globus Toolkit）这两方面的相关资料。本文中介绍的端到端网格股票服务解决方案包含 Globus 项目（http://www.globus.org/）开发和／或派生出的软件。
参考资料
阅读更多 IBM 提供的网格解决方案 。
全球网格论坛（GGF）的 Open Grid Service Infrastructure Working Group 正在定义 OGSA。
请查阅 Globus 项目以了解关于 Globus Toolkit 3.0 和开放网格服务体系结构的信息。
OGSADF 的设计文档在 OGSI 技术预览版中 。
看一下 Web 服务检查语言（Web Services Inspection Language）规范 ，它提供了一种 XML 格式来帮助检查一个站点，查找可用服务及一组关于应该如何使与检查相关的信息可用的规则。
请参阅 IBM WebSphere UDDI Registry ，它使开发者能够探索在企业内和跨企业构建 Web 服务注册中心的可能性。
了解更多关于 SOAP 规范的知识。
下载 Apache Tomcat 免费副本以构建网格解决方案。
使用 IBM WebSphere Application Server 托管商业网格和 Web 服务解决方案。
参考资料
全球网格论坛（GGF）的 Open Grid Service Infrastructure Working Group 正在定义 OGSA。
进一步了解 Globus Toolkit 3.0：开放网格服务体系结构。
OGSI 技术预览版中 OGSADF 的设计文档。
下载 alphaWorks 上的 BE4WS 分发包 并试一下比较容易的示例。这样您将亲身体验到 BE4WS 支持的不同搜索条件以及它优于 UDDI4J 或其他 UDDI 客户机的地方。
阅读 UDDI4J ，它提供 UDDI 规范 v2 的全面支持。
看一下 IBM WebSphere UDDI Registry ，它使开发者能够探索在企业内部以及跨企业构建 Web 服务注册中心的可能性。
了解更多关于 SOAP 规范的知识。
Liang-Jie Zhang、Henry Chang 和 Tian Chao 合写的 “Web Services Relationships Binding for Dynamic e-Business Integration” ，发表于 2002 年 5 月 24-27 日在内华达州的拉斯维加斯举行的因特网计算国际会议（International Conference on Internet Computing）（IC '02）上。
Liang-Jie Zhang、Tian Chao、Henry Chang 和 Jen-Yao Chung 合写的 “Automatic Method Signature Adaptation Framework for Dynamic Web Service Invocation” ，发表于 2002 年 7 月 14-18 日在佛罗里达州的奥兰多举行的第六届资讯系统及自动控制联合国际会议（6th World Multi Conference on Systemics, Cybernetics and Informatics）（SCI 2002）上。
关于作者
Liang-Jie Zhang 是 IBM 的 T.J. Watson Research Cente 的一名研究员，在那里，他积极从事使用 Web 服务和网格计算的企业应用程序集成和设计协作（Enterprise Application Integration and Design Collaboration）方面的研究。他是 Business Explorer for Web Services（BE4WS）和 Web Services Outsourcing Manager 的首席设计师。他的其他研究兴趣包括 B2B 集成中心框架和宽带-媒体业务。他已经组织了几次关于 Web 服务计算（Web Services Computing）和网格计算（Grid computing）的竞赛，并且还是 GRID 2002 的一名程序委员会委员（program committee member）。您可以通过 zhanglj@us.ibm.com 与 Liang-Jie 联系。
Jen-Yao Chung 是 IBM 的 T.J. Watson Research Center 的一名研究员。他目前是 electronic commerce and supply chain 部门的高级经理，同时还是 IBM Institute for Advanced Commerce 技术办公室的程序主管（program director）。他曾经参与过电子商务、电子市场、基于 Web 的应用系统和业务流程集成与管理的研究、开发和客户接洽。您可以通过 jychung@us.ibm.com 与 Jen-Yao 联系。
Qun Zhou 是 IBM Software Group 的一名软件工程师，在那里，她一直从事媒体搜索和分类工作。她还深入研究 Web 服务及其在媒体内容分发和搜索方面的应用。您可以通过 qzhou@us.ibm.com 与 Qun 联系。