基于服务的企业集成模式轻松入门，第 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) 思想，以便能够为服务提供者和服务使用者处理不同的协议。
• 进一步完善注册思想，以方便服务的注册和发现。

本文转自IBM Developerworks中国

        请点击此处查看全文