基于SOA构建网格应用程序(1)

迁移到 SOA 和网格

网格应用程序的一个永恒的问题是，使其足够灵活，以在各种平台和环境中使用。尽管早期的网格使用了专用的解决方案，其中采用的是严格受控的硬件和环境，但是最近的发展已经清楚地表明，将网格应用程序放到更为广泛的平台上运行，这样您只需要添加一些机器就可以很容易地扩展网格的范围和处理能力。

然而，平台之间微小的差异可能会导致非常令人头疼的事情。例如，Windows® 不同版本之间的改变，甚至是 Windows NT 和 Windows 2000 之间的差异，也都会导致那些网格环境中通常经过严格设计和优化了的应用程序出现问题。一个显然的解决方案是去掉那些高度与平台相关的元素，并切换到一个更加通用的环境中。

SOA 幕后的准则遵守一些基本的规则。SOA 是一个用来构建应用程序的基于组件的模型，可以将应用程序划分为很多离散的服务，这些服务各自执行某个特定的功能，但是可以将它们组合在一起构成更大的应用程序。

SOA 的基本原理现在已经并不新鲜了。面向对象的概念已经出现了很多年，分布式对象也已经在很多技术中存在很多年了，例如 CORBA。主要的区别在于，SOA 是基于面向对象和 Web 服务两个概念的组合，并在一个用来描述可用接口的开放系统中采用了这种结构。通过使得 Web 服务可以更容易发现和识别，SOA 可以极大地简化基于 SOA 应用程序的部署和分布。由于 Web 服务都是基于开放标准的，在其定义中就保证了体系结构和平台的无关性，因此基于 SOA 的应用程序可以部署到各种平台上。

简而言之，SOA 是一种对外提供服务的方法，让计算机可以彼此进行交谈，并共享自己的处理能力和功能。网格正在慢慢地朝 Web 服务架构发展，首先是 Globus 采用开放网格标准基础设施（OGSI），然后是发布 Globus Toolkit 4.0（GT4）。SOA 和网格技术正基于诸如 Web Services Resource Framework（WSRF）以及其他的一些解决方案，朝 Web Standards Interoperability 技术方向发展。

您还可以看到 SOA 和网格都可以为对方提供很多东西。这并不是网格技术利用 SOA 准则的情况，或者反之。从 SOA 的观点来说，网格为信息和资源的分布提供了一个异常模型，这是 SOA 模型的一个关键特性。从网格的观点来看，SOA 为调整网格解决方案的架构以及促进其透明性和更好地支持广泛的平台和环境，提供了一些可选的而又非常灵活的方法。

下面让我们来了解一下传统的网格模型，然后介绍一下基于 SOA 的网格模型，从而比较二者之间的区别，以及如何开始将网格和 SOA 应用程序作为一个单一的资源进行考虑。

传统的网格模型

为了全面地理解 SOA 如何才能改进网格服务，以及需要如何修改应用程序，下面让我们来看一个基于传统的网格技术的典型网格服务，包括基本的 Web 服务。这个服务的基本结构非常简单。

在图 1 中您可以看到一个典型的网格环境的结构图。其中我故意没有说明网格软件的类型，因为大部分网格软件都可以根据相同的原理进行工作。

图 1. 网格模型结构图

总体上来看，这个结构相当简单。我们有一个网格协调者负责分发信息并与各个节点进行工作。这个协调者（它还有很多别的名字，包括分发和管理节点）的职责就是运行网格。协调者与工作节点之间的通信可能在很多解决方案中都存在，不过大部分系统（包括 Globus）都是依赖于 Web 服务的。此处使用的模型通常都称为级联服务，因为信息和工作请求都是通过服务进行级联，从而将其从某个地方分发到各个节点上。

然而，不管采用哪种通信系统，其方法大体上是相同的：

• 严格结构的意思是说，节点都是使用一个特定的 Web 服务或 Web 服务接口与某个软件的特定部分进行联系的，从而处理来自节点协调者的请求。
• 任务提交是通过协调者进行处理的，它分布在各个节点上，通常使用一个 Web 服务来提交任务。在工作节点上，有一个类似的客户机将完成的任务发回给网格协调者。
• 网格节点所需要的其他信息（例如大型的数据结构或引用材料）可以在网络上通过另外一个服务进行访问，Web 服务可能支持，也可能不支持。例如，有些网格使用一个集中的 SQL 数据库来存储节点不通过 Web 服务接口而是直接访问的信息。

总体来说，大部分网格服务（直到最近）都是基于大型的单一代码基础的，它使用了一些私有的方法来进行通信和共享信息。这使得 Web 服务模型也正在发生改变，但是即使采用了 Web 服务标准之后，很多解决方案也都可以对原有的单一应用程序使用一个 Web 服务接口。例如，从上面这个传统的模型中我们可以看出，将任务提交到一个节点是通过一个 Web 服务接口提交给网格节点的，这实际上会将面向 Web 服务的接口暴露给原来的应用程序。

这种单块方法存在一个问题，即使使用 Web 服务，它也会限制扩展和增长的能力。采用这种单块风格，将应用程序移植到其他平台和环境就会变得更加复杂。如果您的系统不是基于 Web 服务的，那么问题可能就更加严重。增长之所以会受到限制是因为它依赖于单个协调系统来负责在网络间分发信息。如果您的客户机也是一个单块接口（即使它同时还使用 Web 服务来提供接口），那么将网格应用程序部署到很多机器上也会变得更加困难。