本文继续详细介绍面向服务的体系结构（SOA）。在第1部分我们讨论了SOA的特征。本文讨论SOA连接体系结构 — SOA的工作角色：服务请求者和服务提供者如何通信，服务提供者如何指定必要信息来将服务集成到服务请求者，以及服务请求者如何发现它所需的服务。本文还介绍了信息交换模式并比较了同步和异步交换。

　　中国的书面语言由表意文字而不是表音文字构成，即使在方言中词语发音完全不同，我们也可以用书面语言来代表所有方言。虽然秦始皇统一口语的目标并没有实现，但是当中国人不理解彼此的口语时，就用通用的书面语言进行交流。

　　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帮助你找到所需的服务。

　　下一部分，将要讨论服务编排以及为其他服务构建服务和应用程序的各种方法。

　　关于作者
　
　　Mark Colan是IBM Corporation主要的电子商务技术倡导者。他给出关于Web服务和XML技术和策略的技术、基调和客户展示。他在2000年和2001年大部分XML会议以及Java One ’98和’99上发言。Mark当前展示的PDF可以从http://ibm.com/developerworks/speakers/colan下载。

　　在加入IBM以前，Mark在Lotus Development Corporation工作了12年， 帮助开发了一些商业产品。Mark具有超过20年的设计和实现商业软件产品和技术的经验，他精通于组件软件策略、操作系统和软件工具。他作为InfoBus Technology（Lotus开发的Java Standard Extension）的首席架构师。您可以通过mcolan@us.ibm.com与Mark联系。