一些服务提供者同时也是服务请求者：它们聚集其他服务提供者的功能来构造复合的更高级别的服务。通过使用 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 服务实现有效的互操作。
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 应用程序的服务，其结果就象电子黄页一样。你可以使用工具（比如 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 全球站点上的英文原文。新闻热点
疑难解答
