本系列的第 1 部分和第 2 部分讲述了开发基于服务的集成模式所需的基本概念。本文（即本系列的第 3 部分）和即将发布的第 4 部分将进一步完善这些思想，使基于服务的集成模式成为全面的基于服务的模式。本文特别阐述了通常被总称为 Web services 的一些组件，这些服务最初是针对可以通过 Internet 访问的服务设计的。您还将看到，许多 Web services 组件可用于不使用 Internet 而仅需要一个网络连接的服务。

　　引言

　　在本系列的前两篇文章中，您已经掌握了一些基本概念。现在，您将了解 Web services，这些服务定义了处理异构问题 的标准。此问题是指这样一种事实，在典型的大型企业的 IT 基础结构中，通常使用不止一种技术来集成应用程序，在此类环境中，一般无法实施企业范围的统一标准。

　　在大型企业中，通常有几种不同类型的技术异构性，其中包括：

　　中间件异构性：在大型企业中，通常不止使用一种类型的中间件。最常见的两种类型是应用服务器和面向消息的中间件 (MOM)。此外还有品牌异构性，这需要支持不同品牌的应用服务器和 MOM。

　　协议异构性：此异构性是指用来访问由各种应用程序提供的服务的不同传输协议。有关这些协议的示例包括：Internet Inter-ORB 协议 (IIOP)、Java? 远程方法协议 (JRMP)、HTTP 和 HTTPS。

　　同步异构性：几乎始终需要同时支持应用程序之间的同步和异步交互。另外，通常还需要回调方法和发布与订阅方法。

　　协议不匹配：与通信协议异构性相关的问题是，不同的应用程序需要使用不兼容的协议相互通信。例如，应用程序 A 可能需要使用 HTTP 与应用程序 B 通信。但是，对应用程序 B 而言，合适的协议可能是 IIOP。在此情况下，就需要一个协议转换，以便应用程序 A 可以与应用程序 B 通信。

　　数据格式的多样性：存在多种数据交换格式。在大多数情况下，数据依赖于所使用的中间件。

　　接口声明的多样性：在服务接口的声明方式和用来调用该服务的方式上也存在着很大差异。例如，对于接口的声明方式而言，公共对象请求代理体系结构 (CORBA) 和 Java 远程方法调用 (RMI) 就不相同。

　　没有公共的服务查找位置：缺少公共的查找服务以处理大型企业中的各种服务的位置。

　　另一个常见问题是，每当软件提供者提供了软件的新版本时，，就必须修改使用者的应用程序以适应提供者应用程序中的更改。针对此问题的解决方案是需要找到一些方法来允许扩展这些服务，例如，在不中断以前版本的使用者应用程序的情况下添加更多的参数 。

　　这种多样性和可扩展性一部分是通过制定标准得到了解决的，而另一部分是通过进一步发展技术得到了解决。本文主要涉及有关标准方面的问题。（第 4 部分将主要着眼于技术方面的发展和开发。）这些标准集中了由主要市场参与者制定和接受的规范、规则和指南，并且独立于实现细节。这些标准奠定了公用性的基础，并通过互操作性被广泛接受。这些标准的示例包括：

　　公共通信语言 (XML)。
　　公共消息交换格式 (SOAP)。
　　通用服务规范格式（Web services 描述语言，即 WSDL）。
　　通用服务查找方法（统一描述、发展和集成，即 UDDI）。

　　技术开发示例包括：

　　进一步完善企业服务总线 (ESB) 思想，以便能够为服务提供者和服务使用者处理不同的协议。

　　进一步完善注册思想，以方便服务的注册和发现。

　　XML

　　XML 已作为进行数据和文档交换的独立于中间件的标准格式而被广泛采用。XML 基本上是 IT 行业认同的最小通用标准。与 CORBA IDL 或 Java 接口不同，XML 不与任何特定的技术或中间件标准绑定，目前经常作为跨不同的大部分不兼容的中间件平台处理数据的临时格式使用。XML 可以免费使用，并附带了可以在许多不同平台上使用的大量工具，其中包括不同的开源分析 API，如 Simple API for XML (SAX) 和 Document Object Model (DOM)。这些工具支持处理和管理 XML 文档。XML 的另一个优点是，它在数据传输过程中可以保留数据的结构。XML 还非常具有灵活性，这使它成为解决中间件和应用程序异构问题的最合适的标准。

　　SOAP

　　虽然采用 XML 是满足解决异构和可扩展性要求的一个重要步骤，但仅用 XML 还不足以让双方（服务提供者应用程序和服务使用者应用程序）正确通信。为了高效通信，双方必须能够根据协商一致的格式交换消息。SOAP 就是这样一个协议；它为服务提供了通用的消息格式。

　　SOAP 是一种基于文本的消息传递格式，使用一种基于 XML 的数据编码格式。SOAP 既独立于编程语言，又独立于操作平台。它在端点不需要任何特定的技术，因此完全不需要知道所用的供应商、平台和技术。其文本格式还使 SOAP 成为防火墙友好的协议。虽然 SOAP 最初在设计上仅与 HTTP 一起使用，但任何传输协议或消息传递中间件都可用来传送 SOAP 消息。

　　SOAP 消息是一个完整的 XML 文档，顶级元素是信封元素。信封元素包含一个 body 元素和一个可选的 header 元素。该 body 元素通常携带接收者所使用的实际消息。该 header 元素通常用于中间处理器，以提供高级功能。清单 1 中显示了一个 SOAP 请求获取股票报价的简单而完整的示例。该清单显示了如何使用 XML 编码 SOAP 消息，介绍了一些 SOAP 元素和属性。

　　清单 1 显示，SOAP 中的顶级元素必须是 envelope 元素，该元素包括以下两个命名空间：命名空间 SOAP:encodingStyle 表示 SOAP 编码，另一个命名空间表示 SOAP 信封。虽然 header 元素是可选的，但是，当其出现时，它必须是 envelope 元素的第一个直接子元素。如果 body 元素出现，它必须出现在所有 SOAP 消息中，并且必须跟在 header 元素之后。该 body 通常包含实际消息的规范。在清单 1 中，该消息包含该方法的名称 (GetLastTradePrice) 和输入参数值 (IBM)。

　　清单 1. SOAP 消息示例
               
　　<soap:envelope border=0>

　　图 1. 通过使用 UDDI 的注册中心的基本工作原理
 
　　在通过使用注册中心发现服务之后，对于特定的服务有三种绑定类别：

　　开发时间绑定：在此情况下，除服务操作签名和服务（网络）协议外，在开发时就已经知道该服务的实际物理位置。相应地开发客户端逻辑。因此，硬编码该绑定来使用特定的服务，并且绑定是永久性的。

　　部分运行时绑定：与前述情况一样，在开发时就已经知道服务操作的签名和网络协议。但是，在代码开发期间不知道特定服务的地址。在此情况下，将启用使用者应用程序，通过使用存储库中的特定名称或属性查找服务以动态地绑定到不同的服务实例。例如，使用者应用程序将依据用户所选的打印机名称，查找具有不同名称的打印服务。另一个示例是根据属性选择打印机服务时的情况，如场所编号和文档类型。

　　运行时绑定：在此情况下，在开发时甚至不知道服务规范（操作签名）和协议。客户端仍可以使用属性发现服务（如场所编号和文档类型），但不知道服务接口。在这里，某类反射机制必须在客户端实现，以便客户端能够动态地发现该服务的语义和有效的请求格式。此类服务发现是最复杂和最不常用，一般原因是它需要复杂的客户端逻辑来动态解释未知服务接口的语义。

　　结束语

　　在本系列文章的这一部分中，您学习了构成 Web services 的最常见的几种标准。这些标准包括 XML、WSDL、SOAP 和 UDDI。使用这些标准可以解决大型企业中的许多异构问题。但是，还有其他一些异构问题尚未解决。例如，在服务使用者与服务提供者所使用的传输协议之间可能存在不匹配的问题。此类问题的解决方案需要更进一步的技术开发，这些内容将在本系列的第 4 部分中讲述。

　　关于作者

　　Waseem Roshen 博士是俄亥俄州哥伦布市 IBM Global Business Services Enterprise Architecture and Technology Center of Excellence 的一位 IT 架构师。他致力于企业体系结构和集成方面的工作。他还是一位 Sun 认证的 J2EE 架构师，已经发表了 60 篇文章，并获得了 24 项专利。