论网格计算与 Web 服务的应用结合目前两项最热门的技术就是网格计算和 Web 服务，但是这两者是兼容的吗？本 文将告诉我们这两个系统实际上兼容程度是相当高的，并描述了在网格应用程序 中使用 Web 服务的好处为了确定网格计算和 Web 服务是否相互兼容，我们需要研究一下网格计算的工 作方式，看看我们是否真的可以将一个典型的网格系统分解成若干个相对分散的 单元网格计算的架构依赖于相当基本的原理，即在多台客户机和多台服务器之 间传送简单的请求食Web服务依赖于处理从一台客户机发送到一台服务器上 的请求如果您尚未看到这一点是如何适应已有的网格结构的，本文将探讨两种最常见的 网格系统：请求架构和分发架构请求系统依赖于客户机请求工作，而分发系统 依赖于代理直接给客户机提供工作这两种系统在与 Web 服务结合的时候面对 的是不同的问题，这一点我们也会讨论到网格通信在网格计算中，基本存在两种主要的组件类型 —— 服务器和客户机服务器用 于分发工作请求及保存有关构成整个工作的独立工作单元的信息客户机（典型 情况下有多个）负责处理独立的工作单元这两者之间的通信方式有多种，但是系统的核心是对工作的分发再次指出，系 统采用两种工作方式中的一种，要么是客户机管理自己的工作流，并向服务器请 求新的工作单元，要么是服务器将工作单元分发给客户机。
通信过程并不是到这 里就停止了；通常还需要额外的服务器和服务来支持网格服务器的基础设施，它 们相互之间需要进行对话，并交换信息关键的问题在于，通常情况下网格解决方案中交换的是相当分散的信息片断在 客户机和服务器之间交换的是原始的工作单元和处理之后的响应甚至在数据负 载相当高的情况之下，如进行数据处理或视频呈现时，我们依然在交换信息包， 而不是在客户机和服务器元素之间建立完全、双向、永久的通信新版的 WebSphere 扩展包中的网格思想更为激进，甚至允许将到 WebSphere 应 用程序的 Web 请求通过 WebSphere 服务器进行分发这个例子也证明了网格管 理与实际的工作分发都可以通过相当简单的数据交换来完成规则中当然总有例外并不是所有的网格系统都依赖于如此直接的简单包交换 比如说，资源网格通常依赖于网格提供者（客户机）之间相当繁重的相互通信， 这样才能在网格上实现实时的存储请求不过在这些情况下，即便当客户机之间 直接进行通信时，依然是一种基本的信息交换因此，如果我们仅仅在交换信息，当然就应该用一种标准的方法在服务器和客户 机之间进行通信这也就是 Web 服务的用武之地Web 服务概览在我们能够理解 Web 服务如何为我们的网格解决方案提供支柱之前，我们需要 理解 Web 服务的工作方式。
最简单的方法是将其想像成一种远程过程调用(RPC)，通过这种方式我们可以从一台计算机(客户机)上调用某个功能，而 代码和实际的功能是在另外一台计算机(服务器)上执行的各种各样的 RPC 中不存在新东西一段时间以来，各种不同的平台上都有不同 的实现也许最有名的 RPC 实现是 UNIX 机上的这一实现使用了一组复杂的 函数，可以使客户机与服务器之间进行信息交换，它将一种基本的 C 结构转换 成一种可以在网络上广播的标准化格式，即外部数据表示( External Data Represen tat ion, XDR)格式这种方法对数据进行了序列化和标准化的处理， 转换后的数据格式可以被该 RPC 架构下的任何客户机或服务器解码出来最近 Web 的爆炸式发展意味着，每当我们访问某个 Web 站点的时候，我们很自 然就是在进行远程过程调用我们的客户机就是浏览器，它向一台服务器(如 Apache, IIS 等)请求一个文件，然后，处理并显示得到的信息这是一个简单 的数据交换过程有了公共网关接口( Common Ga teway In terface, CGI)、JSP、 ASP 这样的动态技术，我们才真正是在调用远程过程。
交换过程是以 HTTP 请求 和 HTML 响应的形式进行的，但是达到的效果一样：我们调用远程机器上的过程， 然后获得一个响应通过以某种方式标准化信息的交换过程，我们就得到了 Web 服务请求和响应 都以XML编码从基本相同的技术派生出两个变种：XML-RPC的设计目标与它 的缩写名所暗示的完全一样 —— 发送和接收用 XML 格式化的远程过程调用； 简单对象访问协议(Simple Object Access Protocol, SOAP)更加高级SOAP的 核心依然是一种 RPC 技术，但是这种技术经过增强，可以实现对一个对象的远 程操纵这样 SOAP 就不是一种简单的 RPC 调用，而是可以创建对象、操纵对 象、并用这个对象在服务器和客户机之间进行更加确切和格式化的信息交换Web 服务可以由任何一种 Web 服务器提供，可以在几乎所有的支持平台上用几 乎所有的语言书写，其中包括 Perl、 Python、 C/C++、 Java 语言以及 Visual Basic Web 服务的核心基本上是 Web 服务器上的一个动态组件，它能够正确地 处理 Web 服务请求和响应这意味着，在很多情况下，您可以很容易在您的已有系统中创建一个 Web 服务 的接口。
您需要做的只是在通常进行的常规系统调用外围编写一个包装器网格与 Web 服务之间的界限逐渐模糊到目前为止，我们已经探讨了通过交换信 息而实现的网格技术，这种交换既可以在服务器和客户机之间进行，也可以直接 在客户机之间进行，从而实现对信息的处理和分发但是这种交换系统需要借用 某种方式进行真正的信息交换这些年来，人们使用了很多种系统，包括 FTP 协 议和定制的协议系统目前，在 Web 服务阵营之中，我们已经拥有了一种通用的工具，可以用来在两 台机器之间交换信息，比如说请求执行某项特定的功能(如 getnewworkunit())， 或是简单地在这两者之间交换信息因为 Web 服务是建立在 XML 等其他标准之 上的，因此很容易开发并扩展到各种不同环境中，并且也容易部署我们摆脱了 不同系统间数据交换的所有问题，并且不需要担心处理器字节中的位次序(endian-ness),也不需要将我们传递的信息转换成中性格式，因为Web服务 的标准已经替我们做了这些事情因为我们需要用某种类型的侦听程序/分发服务来处理请求、分发工作以及收集 结果，所以Web服务就是最理想的选择Web服务系统带来的主要益处在于， 因为它依赖于 HTTP 协议，因此很容易将 Web 服务集成到已有的 HTTP 平台、 路由器、防火墙以及其他系统中。
大多数组织已经运行了 HTTP 服务，因此您可 以用已有的技术和安全系统来支持您的网格系统，而不需要对网络进行改造，也 不会对网格系统中的设备造成限制这样，用 Web 服务开发网格系统就具有了 一些无可比拟的优势，其中包括：增强的兼容性增强的灵活性 通过消除数据交换的复杂性，使跨平台开发成为可能 很容易部署在已有的 Web 服务器上很容易通过已有的 HTTP 安全机制与防火墙的支持来提供安全性 通过 Intranet 或 Internet 访问网格组件的难度降低，这样就使得通信变得容 易，可访问性增强出于所有上面这些理由，以及更多的原因， Web 服务已经逐渐成为新的网格服务 标准 开放网格服务架构(Open Grid Services Architecture, OGSA)以及与之相伴的开放网格服务基础设施(Open Grid Services Infras true ture, OGSI)—— 的一个组成部分GlobusToolkit3.0 是第一个完全支持 OGSA/OGSI 标准的网格平台，它支持将 Web 服务作为数据交换的平台 IBM 作为 OGSA 标准和 Globus 系统的关键参与 者，给 Web 服务提供了强有力的支持，现在正推荐人们在业务开发平台中广泛 使用 Web 服务。
Globus 支持 SOAP Web 服务协议Web 服务方法还带来其他一些好处 Web 服务可以通过多种不同的 Web 服务目 录和系统发布，其中包括像统一描述、发现与集成(Universal Description、 Discovery and Integration, UDDI)和 Web 服务描述语言(Web Services Description Language, WSDL)这样的系统为了让网格计算能更容易部署，我 们需要通过这样的目录和系统来发布服务不管您是否选择Globus Toolki t,都需要考虑如何在您的网格系统中应用Web 服务有两种 Web 服务可供使用，它们分别适应两种典型的网格服务结构：请 求架构，在这种架构之下客户机与一个或者多个中央服务器进行联系；分发架构， 服务器直接与客户机联系对于每一种架构，在网格应用程序中使用 Web 服务 之前您都必须考虑一些问题支持请求架构Web 服务的主要应用位置是在分发和代理的一端，也就是说，点单元被分布到网 格中的客户机（提供者）上，这就是一种请求架构的例子，其中客户机从网格代 理那里请求工作请求架构事实上是可以支持 Web 服务的最简单的系统，因为这样的系统可以像 以前一样很好地工作：客户机向一个可用的服务器发送已经完成的工作单元，并 从那里请求新的工作。
您需要做的事情只是安装 Web 服务和 Web 服务器，可以 单独安装，也可以直接安装在代理服务器上，然后添加代码以将您的 Web 服务 连接到代理整个系统的工作情况如图 1 所示：图 1. 请求架构运行图Globus 对于这种架构是一个理想的解决方案，因为 Web 服务组件可以很方便地 对系统支持分发架构 分发架构与传统的网格服务模型相反，它直接从服务器向客户机分配工作这种 架构尽管不常用，但是如果某种环境中的工作是受到控制的，并可以仔细地分配 到特定的执行单元，并分别监控，那么这种架构对于分发工作就是很实用的方法 然后，由服务器负责单独管理和分配每一个单元分发模型对于时间要求高的任务分配是一种好办法，因为工作单元可以根据机器 的负载和代理上的服务器队列分配到独立的机器上这种模型特别适合用于 Intranet 和封闭的网络中，因为访问和通信都很方便，因此系统的效率也相对 较高这种模型还适用于工作提供者（即客户机）完全用来处理网格工作的情况分发系统惟一的问题是实现难度比较大这种模型不是由服务器运行 Web 服务 系统，客户机作为 Web 服务的客户机，而是调了个头网格提供者（通常应该 是“客户机”）需要支持一个 Web 服务的服务器接口。
这时，代理（通常是“服 务器”）成为网格提供者的 Web 服务客户机您可以从图 2 中看到这种模型的 运行情况：图 2. 分发模式下的 Web 服务在这里的 Web 服务机制的基础之上还存在以下问题： 代理需要确切知道哪些机器是网格的一部分，因为它需要能分别访问这些客户机 每一个客户机都必须支持 Web 服务模型，该模型又依赖于客户机提供 HTTP 服 务每一个客户机都必须能够确定自己的负载和性能，这样才能在代理请求的时候将 这些信息提供给它 尽管需要解决上面的每一个问题，分发架构使用起来依然相对简单然而 Globus Toolkit 目前并不支持这种模型这并不意味着我们不能在其他领域内使用Globus Toolkit,但是却意味着您必须重新考虑客户机和代理之 间是如何交换任务的将网格应用程序和 Web 服务集成实际上并不像刚开始看上去那么复杂大多数 网格应用程序的基础使它们很容易转移到 Web 服务的架构上来,但是您需要考 虑对您的网格应用程序设计的影响,以保证您的后端系统（包括代理、工作单元 管理器以及其他组件）都能与您所期望的客户机工作方式兼容。