Web 服务使用了相似的方法。xml 是一种通用数据表达法。在使用不同程序语言编写的程序和执行不同的机器指令之间，可以使用 XML 作为交换媒介。XML 是所有 Web 服务技术的基础，并且是互操作性的要害，每个 Web 服务规范都是基于 XML。非凡是，SOAP 使 XML 所编写信息的交换规范化，WSDL 使用 XML 词汇描述 SOAP 的细节。
本文的第一部分中，定义了面向服务的体系结构（SOA）以及它的一些特征，并解释了它同 Web 服务技术的关系。从那里可以了解到 SOA 是一种由应用程序所组成服务的体系结构样式，并且封装了应用程序功能以提高可重用性。
我将 Web 服务描述为一套新兴规范，Web 服务是目前实现 SOA 的最好方法。关于 Web 服务的文章有很多，因此我将依据其他文章来解释这些细节。当我分析 SOA 的体系结构概念时，你会看到一些明显同 Web 服务重复的内容，但是本文的着重点是 SOA 扩展 Web 服务的前景。
服务工作角色
同 Web 服务一样，面向对象的体系结构（SOA）中有两个要害角色：服务请求者和服务提供者。一个或多个提供者应用程序通过发送请求消息并处理响应消息来提供服务，请求者应用程序调用这些服务。
图 1 .服务请求者和服务提供者
一些服务提供者同时也是服务请求者：它们聚集其他服务提供者的功能来构造复合的更高级别的服务。通过使用 java、C# 或者象业务流程执行语言（BPEL）那样的非凡编排语言来完成这种组合。
图 2. 聚合的服务请求者
一些像 UDDI 和 WS-Trust 的 SOA 技术提出了第三种角色，叫做服务代理（service broker）。 服务代理是服务提供者和服务请求者之间的中介 -- 服务本地化，代理托管方案等等。
图 3.作为中介的服务代理
使用这三种角色建模的实体使用服务调用（Service Invocation，例如 SOAP 消息）来通信。
服务调用
W3C SOAP 1.2 规范在服务请求者和服务提供者之间定义使用 XML 格式的消息进行通信。将应用程序请求（在 XML 中）放入 SOAP 信封中（也是 XML ），并从请求者到提供者发送应用程序请求，提供者发回的响应也采用相同的形式。市场上的大部分产品支持早期的 SOAP 1.1 规范，但是在未来产品发布中将支持 SOAP1.2。由于已经有许多关于 SOAP 的内容，进一步内容请参阅参考资料中列出的出版物。
图 4. 使用 SOAP 的服务请求
因为 SOAP 是平台无关和厂商无关的标准，因此在带有单独 IT 基础架构的合作伙伴之间的松耦合互操作中，SOAP 是支持服务调用的最好方法。然而，SOA 不需要使用 SOAP。
例如，在 SOAP 之前，一些公司使用 IBM® WebSphere® MQ 来给其他的计算机发送 XML 文档，其他计算机依据这些文档执行应用程序操作。使用 HTTPS 接口的 eBey XML 以相似的方式来传递用于拍卖的物品条目。虽然由于没有使用 SOAP 而不能调用 Web 服务，但是仍然可以在 SOA 中调用服务。当然，目前 WebSphere MQ 也对 SOAP 消息提供了直接支持。
只要所有的实体是用 Java 语言编写，那么就可以仅仅使用 J2EE 中的可用功能来创建 SOA。然而，这种方法不能为非 Java 应用程序的互操作性提供令人满足的解决方案。
在企业内部需要为 IT 系统控制代码的地方，可以考虑使用 SOAP 之外的服务调用方法，这些方法可能没有构建并解析 XML 内容。这就会有更好的性能，并且可以避免围绕现有功能编写 SOAP 封装代码。出于对简单性的需求，能够使用其他协议调用服务的单一调用 API 样式是一个很好的实践。
多重协议服务调用
JAX-RPC 规范（也叫 JSR-101）定义了一个 Java API，使从 Java 程序中调用 Web 服务变得简单。JAX-RPC 实现至少必须支持使用 HTTP 的 SOAP1.1。然而，为了服务调用它可能还支持其他的协议。多重协议服务调用能够使用相同的 API 指定不同的协议，例如改变 URL。
WebSphere application Server 当前版本中的 JAX-RPC 实现是 JSR-101-compliant，但答应简单的通过将 URL 修改为对 JMS 服务器（比如 WebSphere MQ）寻址的形式来使用 JMS 上的 SOAP 调用。在不久的将来，这种多重协议样式将答应使用 IIOP 上的 RMI 进行服务调用，以使 EJB 服务实现有效的互操作。
简单性的要害是不考虑协议而使用相同的 API。让这成为可能的是在 WSDL 中描述协议的能力，这些协议不同于 HTTP 上的 SOAP。
服务描述
Web 服务描述语言（WSDL）规范定义了一个 XML 词汇表，该词汇表依照请求和响应消息，在服务请求者和服务提供者之间定义了一种契约。你能够将 Web 服务定义为软件，这个软件通过描述 SOAP 消息接口的 WSDL 文档来提供可重用的应用程序功能，并使用标准的传输协议来进行传递。
WSDL描述包含必要的细节以便服务请求者能够使用特定服务：
请求消息格式
响应消息格式
向何处发送消息
WSDL 是基于 XML 的，因此 WSDL 文档是计算机可读的（machine-readable）。这样开发环境使用 WSDL 将集成服务的流程自动处理到请求者应用程序。例如 WebSphere Studio 产生一个 Java 的代理对象，它能够像本地对象一样实现服务，但是实际上代理对象仅仅处理请求的创建和响应消息的解析。不管服务是否用 Java，C# 或者其他的语言实现，生成的 Java 代理对象都能够从 WSDL 描述中调用任何的 Web 服务。实际上，WSDL 不能像编程语言那样描述实现细节。
图 5. 使用 WSDL 文档
WSDL 使用它的扩展功能并通过与 HTTP 上的 SOAP 不同的协议来支持服务定义。依据 SOA，你能够将任何可以用 WSDL 描述接口的应用程序功能称为服务。当 SOA 不非凡的需要 WSDL 时 -- 你可以使用其他服务描述语言 -- 目前大部分厂商和产品都支持 WSDL。
信息交换模式
在流行的请求-响应（request-response）交换模式中，服务请求者向服务提供者（或端点）发送请求消息，处理完请求之后，提供者将响应消息发送给请求者。服务互操作可以是会话式的，由若干对请求-响应构成。然而，为了性能、设计的简单性和从松耦合中获得好处，设计粗粒度接口是一个好办法，它能够将事务需要的交换数量最小化。
图 6. 请求-响应消息传递
除了请求-响应模式之外，WSDL还定义了以下内容：
将单向（one-way）消息发送到端点 -- 例如，不需要响应的请求：
图 7. 单向请求
从端点发送的单向消息，叫做通知：
图 8. 通知
要求-响应（Solicit-Response） 模型，端点通过它发送消息和接收响应：
图 9. 要求-响应
目前 SOA 实现通常使用 HTTP，导致了同步通信 -- 在处理之前请求者等待响应。同步交换用于预期完成时间相对较短（几秒或几分钟）的服务。
也可能有异步服务互操作，在异步服务互操作中服务请求者不等待响应，而是期望以后交付响应。这适合于长时间运行的事务。例如调用一个业务流程来请求指定的客机报价，流程包括许多合作伙伴或人的互操作，这要花几天或是几周来完成。使用异步交换能够避免失去连接（因为服务器维护等等）以及因此而失去响应的风险。
Web 服务寻址（WS-Addressing）规范将 reply-to 地址作为 SOAP 信封报头元素的扩展。服务请求者将请求排队放入 WSDL 文档中指定的端口，但是不需要等待。相反，在响应到达之前，它做其他的工作。当服务提供者预备发送响应时，使用 SOAP 中的 reply-to 地址：请求消息的报头。
图 10. SOAP 中的 reply-to 地址
使用像 WebSphere MQ 这样的消息队列产品时，可以使用 JMS 来实现同步消息。请求者可以选择为请求排队但是不等待处理的完成。当执行其他工作时，要定时检查响应队列中的响应。
图 11. 使用 JMS 的同步消息
你可以应用同步消息的方法来创建其他的交换模式，比如接收多重通知请求（例如在股票报价变更的通知）。
图 12. 多重响应模式
服务发现
尽管服务调用和服务描述通常被认为是 SOA 的需求，但服务发现也是它的可选功能。UDDI（通用描述，发现和集成）为发布服务的可用性和发现所需服务定义了一个标准接口（基于 SOAP 消息）。UDDI 实现将发布和发现服务的 SOAP 请求解释为用于基本数据存储的数据治理功能调用。
为了发布和发现其他 Web 服务，UDDI 通过定义标准的 SOAP 消息来实现服务注册（Service Registry）。注册是一种服务代理，它是在 UDDI 上需要发现服务的请求者和发布服务的提供者之间的中介。一旦请求者决定使用特定的服务，开发者通常借助于开发工具（例如IBM WebSphere Studio 或者 Microsoft® Visual Studio .NET）并通过创建以发送请求并处理响应的方式访问服务的代码来绑定服务。
图 13. UDDI 模式
发现用于构建 SOA 应用程序的服务，其结果就象电子黄页一样。你可以使用工具（比如 WebSphere 中的 UDDI Browser）在应用系统设计期间寻找合适的服务。SOA 不需要使用 UDDI，但由于 UDDI 是建立在 SOA 上来完成自身工作的，所以 UDDI 是服务发现的一个好的解决方案。
正如在 Steve Graham 的文章“Six Species of UDDI”（请参阅参考资料）中提到的，你能够用多种不同的方法使用 UDDI。本文非凡指出了在 IT 组织内 UDDI 的使用，主要是为了治理内部服务以提高可重用性以及进一步促进端点无关性。例如，应用程序中可能会缓存所需服务的位置。假如服务重新部署到不同的服务器当中，服务请求者能够使用 UDDI 发现新的位置并将它缓存以备将来使用。当内部部署 UDDI 时，使用 UDDI 服务请求者应用程序将自动适应于服务部署的变更（例如，为维护负载平衡而做的变更）。
随着 UDDI 的发展，它将广泛的用于发现由市场模型中其他组织所提供的公共可用的（publicly-available）业务服务。正如我们将在关于服务编排的文章中所讨论的，UDDI 在运行时对服务的 UDDI 动态选择方面很有用的。
结束语
本文讨论了 SOA 的基本元素以及它们相互发现和互操作的方法。你通过开发服务目录（内部的或合作伙伴的）来创建基于 SOA 的 IT 体系结构，并编写代码使用这些服务来开发出新的应用程序。由于服务提供者能够通过请求其他服务来完成自己的工作，在设计上就可以使用服务的分层结构。虽然简单的请求-响应消息模型最为流行，但是你可以使用其他的消息模型灵活的设计系统。WSDL 文档告诉你如何集成服务，UDDI 帮助你找到所需的服务。
参考资料
您可以参阅本文在 developerWorks 全球站点上的英文原文。
