网格和面向服务架构（SOA）是两个似乎相互冲突的系统。SOA 是构建离散服务的标准，它可能要跨越多台机器，这些机器可以进行合并以构建一个应用程序，从而降低集成成本。大部分现代网格都采用了类似于 SOA 的 Web 服务，但是在这两个系统之间实际上有更多东西可以进行合并，而不仅仅是采用几个 Web 服务。您还必须调整网格解决方案的体系结构。本文将简要介绍 SOA 幕后的一些概念，以及在将网格应用程序迁移到 SOA 模型时应该考虑的问题。
迁移到 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 服务来提供接口），那么将网格应用程序部署到很多机器上也会变得更加困难。
SOA 应用程序模型
SOA 并不是使用 Web 服务来集成应用程序不同部分并在其间进行通信的另外一个简单术语。SOA 要走得更远，它定义了一种方法来部署应用程序，这样可以将注意力从由多个函数和对象组成的单个应用程序转移到一种将整个应用程序划分为多个单一服务的结构上来。例如，考虑一个记帐程序，它有一些组件负责开具发票并提供一种方法进行支付。除了传统的组件应用程序模型之外，您还可能会希望为这两个任务定义一些对象和相关方法。
在一个简单的 Web 服务环境中，您要为对象和方法构建一个接口来允许访问需要远程访问的内容。例如，开具发票这个任务可能需要您通过网络连接进行访问。在所有的可能性中，Web 服务都会在一台专用的机器上有一个专用的接口，为其构建一个接口需要了解这台服务器上都在运行什么服务，以及为其提供接口需要的详细信息。
在一个 SOA 中，这个记帐应用程序中的每个功能从技术上来说都可以作为一个 Web 服务。每个服务都会在网络上广播自己的存在，您可以在任何经过适当授权的机器上执行任何操作。而且，由于每个服务都是自己可以控制的一个组件，因此它们可以存在于网络上的任何地方。我们不再需要一台专用的服务器来处理请求。例如，我们可以使用一个服务器农场，由于服务会广播自己的存在，因此我们不必担心如何发现这些服务。
从上面的介绍中，我们可以确定 SOA 的主要元素是：
- 可以作为一个单独的服务使用 —— 所提供的服务质量的级别还需要作为一项标准确定。例如，我们还不知道是否要提供一个可以处理多个操作和多个服务的单一发票服务，每个都支持不同的操作，例如开具发票、支付发票或修改发票。
- 独立性 —— 我们并不关心它们是如何来实现我们请求的任务的。它们只要实现这个功能就好了。类似地，服务也并不关心如何来达到这个结果。
- 服务会广播自己的存在。
因此从理论上来说，应该可以将一个应用程序划分为更小的组件，然后可以将其连接在一起（通过相互调用），从而构成最终的应用程序。由于这些单元也可能会扩展到多台机器上，因此我们需要从这种单块、级联结构切换到一种更加灵活的分布式、自由通信的结构。在图 2 中您可以看到一个 SOA 结构的例子。
图 2. SOA 网格模型的一个例子
SOA 网格模型
从上面对于 SOA 模型的介绍以及目前网格技术朝着 Web 服务结构发展的趋势可以清楚地看出，二者正在不断融合。使用简单的术语来说，网格是一个共享资源的分布式系统，而 SOA 则是一个分布式体系结构，后者最关注的是服务的相互操作能力、易于集成、简单性、可扩展性以及安全访问的特性。这两个系统有一些共同的问题，包括延时、并发和局部故障等问题。
二者都使用了 Web 服务，图 3 给出了一个可以在 SOA 和网格环境中使用的简单布局。二者都大量地采用了 SOAP、XML Web 服务标准以及相关的安全性、管理和其他系统。
图 3. SOA 操作模型
不管现有的应用程序是否使用 Web 服务，您都可以看到在图 3 中详细介绍的开放标准构成了 SOA 标准的主体。总之，SOA 利用了以下的技术：
- 使用 XML 来构成所有标准的核心部分，从用来交换信息的 SOAP 协议到用来共享描述信息的方法。例如， WSDL（一种基于 XML 的描述语言）就用来描述潜在的客户机可以使用的服务。
- SOAP 为交换对象和调用方法提供了一些基本的方法。底层的传输协议是高度不相关的，不过很可能会使用 HTTP。
- 很多扩展用来为服务之间的交互操作提供关键的服务。例如，WS-Reliability 和 WS-Resource 就用来帮助提高通信的可靠性。
- 后台标准，例如 WS-Security 和新的 WS-Distributed Management 标准，用来帮助提供安全的通信和管理远程服务。
这些准则和技术早已在 Globus Toolkit 中得到了采用，并深入网格标准和应用程序之中。
要在自己的应用程序中采用这些技术，需要改变一下开发应用程序的方法。例如，要在网格应用程序中采用 SOA 的准则，您需要：
- 将应用程序迁移到服务模型。如果您还没有这样做，就必须考虑一下应用程序中的每个操作。稍后我们会更详细地介绍这个问题。
- 将应用程序划分成更小的、离散的组件。例如，不采用一个带有 Web 服务接口的单块程序，而是将应用程序划分成单个基于 Web 服务的组件。您可以将为网格节点提供服务的应用程序划分成单个服务来接受任务、返回任务和汇报统计信息。
- 确保节点和控制器可以独立工作。不要依赖于对数据库服务器或其他资源的持久连接。
反之，要在 SOA 应用程序中采用网格的概念，您需要：
- 从应用程序中删除那些依赖于单一主机或环境进行操作的部分。
- 将统计信息和监视信息集成到 SOA 服务中，从而确定典型的网格负载信息，例如 CPU 和存储资源。
这两种情况中的结果应该是可以构建一个更加灵活而且实际可用的应用程序。
迁移应用程序
修改现有的应用程序是修改网格或 SOA 应用程序最困难的方法，因为您需要找到一种方法来修改应用程序，却不要极大地改变应用程序工作的方法和现有的服务。
主要的问题是要确定应用程序的组织。建立要执行的操作列表，网格中的组件和节点之间通信是如何操作的，以及各个步骤的编译次序。例如，您可能会希望制作一个提交次序的模型：当提交作业时会发生什么，当发回响应时会发生什么，当需要有关某个给定资源的状态信息时又会发生什么。有了这些信息，就可以构建一个支持这些操作所需要的服务清单了。
现在您需要考虑如何实现这些服务。SOA 和基于网格的服务方法之间有一点区别：SOA 组件被认为是无状态的，而网格则是有状态的。二者并不需要是互斥的。您可以开发一个无状态的应用程序来提供有状态的信息，这样就可以包含一个方法来记录可以汇报的服务的状态。
记住，即使是在迁移到新的 SOA 模型时，应用程序中的关键部分也是相同的。例如在 CPU 敏感的网格中，网格中执行实际工作的核心的计算函数都是相同的，访问数据结构和信息的代码也都是相同的。例如，如果您考虑一个图像呈现网格，构成原始图像描述的数据以及将这些向量数据转换成最终图像的代码（函数或应用程序）都是相同的。只有各个节点之间进行通信和发送请求的方式会发生变化。
最后，具备这些信息之后，就可以开始将应用程序迁移到新的基于组件的模型了。不幸的是，并没有什么简单的方法可以产生这些信息，现在也没有什么工具可以对此进行简化。您需要确定的很多信息都依赖于应用程序和转换应用程序时的源环境。
结束语
即使对于一个偶然的观察者来说，SOA 和网格都具有类似的目标：简化应用程序，扩充其功能和所支持的平台，可以将任务更容易地分发到多台机器上。它们当然会采用很多相同的基本组件 —— Web 服务和 XML —— 但是这些方法稍有不同。您还可以看到每种解决方案可以给另外一种解决方案提供很多优点，足以值得考虑利用这种技术。例如，网格技术的独立特性对于部署基于 SOA 的应用程序就非常有益。SOA 的灵活特性和异构特性对于网格扩充自己的平台基础来说则十分理想。
采用基于 SOA 的网格，我们可以获得很多优点。单块模型消失了。现在不再采用一个单一的网格协调者来控制各个任务单元在网格上的执行，任务可以提交到任意的节点上。当任务进行分发时，如果节点不能及时处理这些任务，各个节点应该可以将任务直接发送到其他节点上。这种自治体系结构是可能的，因为各个组件可以彼此进行交互。