可以作为一个单独的服务使用 —— 所提供的服务质量的级别还需要作为一项标准确定。例如，我们还不知道是否要提供一个可以处理多个操作和多个服务的单一发票服务，每个都支持不同的操作，例如开具发票、支付发票或修改发票。
独立性 —— 我们并不关心它们是如何来实现我们请求的任务的。它们只要实现这个功能就好了。类似地，服务也并不关心如何来达到这个结果。 服务会广播自己的存在。
因此从理论上来说，应该可以将一个应用程序划分为更小的组件，然后可以将其连接在一起（通过相互调用），从而构成最终的应用程序。由于这些单元也可能会扩展到多台机器上，因此我们需要从这种单块、级联结构切换到一种更加灵活的分布式、自由通信的结构。在图 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 的网格，我们可以获得很多优点。单块模型消失了。现在不再采用一个单一的网格协调者来控制各个任务单元在网格上的执行，任务可以提交到任意的节点上。当任务进行分发时，如果节点不能及时处理这些任务，各个节点应该可以将任务直接发送到其他节点上。这种自治体系结构是可能的，因为各个组件可以彼此进行交互。
