网格与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 Access Protocol, SOAP)更加高级。SOAP 的核心依然是一种 RPC 技术,但是这种技术经过增强,可以实现对一个对象的远程操纵。这样 SOAP 就不是一种简单的 RPC 调用,而是可以创建对象、操纵对象、并用这个对象在服务器和客户机之间进行更加确切和格式化的信息交换。
Web 服务可以由任何一种 Web 服务器提供,可以在几乎所有的支持平台上用几乎所有的语言书写,其中包括 Perl、Python、C/C++、Java 语言以及 Visual Basic。Web 服务的核心基本上是 Web 服务器上的一个动态组件,它能够正确地处理
相关新闻>>
- 发表评论
-
- 最新评论 更多>>