基于服务的企业集成模式轻松入门，第 3 部分: Web services 和注册中心

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




回页首
虽然采用 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)。
IBM




回页首
解决上面提到的基于服务的集成模式中异构问题的第二个 XML 应用在通过使用 WSDL 声明的服务接口。由于具有上一段落中概括的 XML 优势，所以大多数情况下都选择它。此外，还添加了解决企业的异构问题的新功能。这包括指定访问该服务所需的传输协议的规定，声明同步和异步服务的更明确的方法。最后，但也是同样重要的一点是，新方法允许在不停用以前版本的客户端软件的情况下扩展服务。
看一个 WSDL 文档示例会对您很有启发。清单 2 中显示了部分 WSDL 文档，这部分文档声明了一项获取天气信息的服务。

正如清单 2 所示，完整的 WSDL 包括一套定义，这些定义以 root 定义元素开头，后跟六个介绍服务的具体元素定义——types、message、portType、binding、port 和 service。下面让我们更详细地分析一下这些元素：
types：定义作为服务一部分进行交换的消息中包含的数据类型。数据类型可以是简单、复杂、派生或者数组类型。在 WSDL 文档的消息元素中引用的类型（架构定义或参考）是在该 WSDL 文档的类型元素中定义的。
message：定义该服务交换的消息。WSDL 文档对于每个交换消息有一个消息元素，并且该消息元素包括与 \\ 消息相关的数据类型。例如，在清单 1 中，第一个消息包括单个部分，它属于类型字符串。
portType：以抽象方式指定作为该服务一部分的操作和消息。对于它定义的每项服务，WSDL 文档都有一个或多个 portType 定义。在清单 1 中，仅定义了一个端口类型，即 WeatherService。
binding：将抽象的端口类型与其消息和操作绑定到传输协议和消息格式。在清单 1 中，定义了一个操作 getWeather，它同时具有输入和输出消息。这两则消息都以 SOAP 正文格式交换。绑定传输协议是 HTTP。
service 和 port：通过为绑定提供单一地址，定义实际服务的名称并为该服务指定一个端点。一个端口只能有一个地址。该 service 元素通过名称属性将相关端口组合在一起，为该服务提供逻辑名称。在清单 1 中，定义了一个名为 WeatherWebService 的服务，该服务具有地址为 http://mycompany.com/weatherservice 的单一端口（或端点）。




回页首
除服务接口声明（在此示例中是 WSDL）和 SOAP 消息传递标准外，大型企业还需要一个中心位置，以便服务提供者可以使用 WSDL 发布其服务，服务使用者可以发现现有服务。这主要是因为，在大型企业中，开发人员资源在地理位置上可能是分散的。此类中心位置被称为注册中心。注册中心就像一个图书馆的卡片目录，用来记录新书和其他媒体的入库情况并查找现有的项目。它还像电话系统的黄页，服务提供者用该页发布服务，服务使用者用该页查找服务。当使用者找到某项服务时，该注册中心在服务提供者与服务使用者之间将不起任何作用。
UDDI 规范定义注册、注销和查找服务的标准方法。图 1 显示了 UDDI 如何对服务启用动态描述、发现和集成。服务提供者首先使用 UDDI 注册中心注册服务。服务使用者然后在 UDDI 注册中心中查找所需的服务，当它发现需要的服务时，使用者将直接与提供者绑定来使用该服务。

在通过使用注册中心发现服务之后，对于特定的服务有三种绑定类别：
开发时间绑定：在此情况下，除服务操作签名和服务（网络）协议外，在开发时就已经知道该服务的实际物理位置。相应地开发客户端逻辑。因此，硬编码该绑定来使用特定的服务，并且绑定是永久性的。
部分运行时绑定：与前述情况一样，在开发时就已经知道服务操作的签名和网络协议。但是，在代码开发期间不知道特定服务的地址。在此情况下，将启用使用者应用程序，通过使用存储库中的特定名称或属性查找服务以动态地绑定到不同的服务实例。例如，使用者应用程序将依据用户所选的打印机名称，查找具有不同名称的打印服务。另一个示例是根据属性选择打印机服务时的情况，如场所编号和文档类型。
运行时绑定：在此情况下，在开发时甚至不知道服务规范（操作签名）和协议。客户端仍可以使用属性发现服务（如场所编号和文档类型），但不知道服务接口。在这里，某类反射机制必须在客户端实现，以便客户端能够动态地发现该服务的语义和有效的请求格式。此类服务发现是最复杂和最不常用，一般原因是它需要复杂的客户端逻辑来动态解释未知服务接口的语义。




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