模板
教程
环境
性能
功能
管理
论网格计算与 Web 服务的应用结合
为了确定网格计算和 Web 服务是否相互兼容，我们需要研究一下网格计算的工作方式，看看我们是否真的可以将一个典型的网格系统分解成若干个相对分散的单元。网格计算的架构依赖于相当基本的原理，即在多台客户机和多台服务器之间传送简单的请求。 Web 服务依赖于处理从一台客户机发送到一台服务器上的请求。
如果您尚未看到这一点是如何适应已有的网格结构的，本文将探讨两种最常见的网格系统：请求架构和分发架构。请求系统依赖于客户机请求工作，而分发系统依赖于代理直接给客户机提供工作。这两种系统在与 Web 服务结合的时候面对的是不同的问题，这一点我们也会讨论到。
网格通信
在网格计算中，基本存在两种主要的组件类型 —— 服务器和客户机。服务器用于分发工作请求及保存有关构成整个工作的独立工作单元的信息。客户机(典型情况下有多个)负责处理独立的工作单元。
这两者之间的通信方式有多种，但是系统的核心是对工作的分发。再次指出，系统采用两种工作方式中的一种，要么是客户机管理自己的工作流，并向服务器请求新的工作单元，要么是服务器将工作单元分发给客户机。通信过程并不是到这里就停止了;通常还需要额外的服务器和服务来支持网格服务器的基础设施，它们相互之间需要进行对话，并交换信息。
关键的问题在于，通常情况下网格解决方案中交换的是相当分散的信息片断。在客户机和服务器之间交换的是原始的工作单元和处理之后的响应。甚至在数据负载相当高的情况之下，如进行数据处理或视频呈现时，我们依然在交换信息包，而不是在客户机和服务器元素之间建立完全、双向、永久的通信。
新版的 WebSphere 扩展包中的网格思想更为激进，甚至允许将到 WebSphere 应用程序的 Web 请求通过 WebSphere 服务器进行分发。这个例子也证明了网格管理与实际的工作分发都可以通过相当简单的数据交换来完成。
规则中当然总有例外。并不是所有的网格系统都依赖于如此直接的简单包交换。比如说，资源网格通常依赖于网格提供者(客户机)之间相当繁重的相互通信，这样才能在网格上实现实时的存储请求。不过在这些情况下，即便当客户机之间直接进行通信时，依然是一种基本的信息交换。
因此，如果我们仅仅在交换信息，当然就应该用一种标准的方法在服务器和客户机之间进行通信。这也就是 Web 服务的用武之地。
Web 服务概览
在我们能够理解 Web 服务如何为我们的网格解决方案提供支柱之前，我们需要理解 Web 服务的工作方式。最简单的方法是将其想像成一种远程过程调用(RPC)，通过这种方式我们可以从一台计算机(客户机)上调用某个功能，而代码和实际的功能是在另外一台计算机(服务器)上执行的。
各种各样的 RPC 中不存在新东西。一段时间以来，各种不同的平台上都有不同的实现。也许最有名的 RPC 实现是 UNIX 机上的。这一实现使用了一组复杂的函数，可以使客户机与服务器之间进行信息交换，它将一种基本的 C 结构转换成一种可以在网络上广播的标准化格式，即外部数据表示(External Data Representation, XDR)格式。这种方法对数据进行了序列化和标准化的处理，转换后的数据格式可以被该 RPC 架构下的任何客户机或服务器解码出来。
最近 Web 的爆炸式发展意味着，每当我们访问某个 Web 站点的时候，我们很自然就是在进行远程过程调用。我们的客户机就是浏览器，它向一台服务器(如 Apache, IIS 等)请求一个文件，然后，处理并显示得到的信息。这是一个简单的数据交换过程。有了公共网关接口(Common Gateway Interface, CGI)、JSP、ASP 这样的动态技术，我们才真正是在调用远程过程。交换过程是以 HTTP 请求和 HTML 响应的形式进行的，但是达到的效果一样：我们调用远程机器上的过程，然后获得一个响应。
通过以某种方式标准化信息的交换过程，我们就得到了 Web 服务。请求和响应都以 XML 编码。从基本相同的技术派生出两个变种：XML-RPC 的设计目标与它的缩写名所暗示的完全一样 —— 发送和接收用 XML 格式化的远程过程调用;简单对象访问协议(Simple Object Aclearcase/" target="_blank" >ccess 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 Infrastructure, OGSI)—— 的一个组成部分。
Globus Toolkit 3.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 Toolkit，都需要考虑如何在您的网格系统中应用 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 服务的架构上来，但是您需要考虑对您的网格应用程序设计的影响，以保证您的后端系统(包括代理、工作单元管理器以及其他组件)都能与您所期望的客户机工作方式兼容。
