在面向服务的架构 (SOA) 中，企业服务总线 (ESB) 是基础架构的一个至关重要的组件。ESB 用于间接地连接采用不同服务格式的应用程序，如图 1 所示。这些不同格式的服务包括 Web 服务、RESTful 服务、异步服务（比如使用 MQ 的服务）、基于 CORBA 的服务、基于 DCOM 的服务和 Java RMI。这些服务采用不同的通信协议和消息格式。例如，Web 服务使用 HTTP 作为通信协议，使用 SOAP 作为消息格式类型，而异步服务可能采用 MQ 作为通信协议，采用 XML 作为消息格式。
目前，可用的 ESB 提供了众多核心功能来连接采用不同服务格式的应用程序。但是，在这些目前可用的 ESB 中，每个应用程序使用一种特定类型的端口来连接 ESB，如图 1 所示。给定应用程序使用的端口类型由该应用程序使用的通信协议和消息格式类型确定。应用程序在对这些特定端口类型的使用上存在诸多问题。您将在本期（本系 列的第一部分）后面一节中了解这些问题和不便性。
应用程序使用特定端口类型连接 ESB
在本期的下一节中，我们将首先简单介绍 ESB，列出应用程序之间的点对点连接中固有的一些问题，以及如何使用 ESB 帮助解决这些问题。接下来，在本期的第三节中，您将了解当前可用 ESB 中各种连接的应用程序对不同端口类型的使用所引起的各种问题。本期最后一节将提供一些总结性评论。
本节的目的在于简单介绍 ESB，简短描述使用点对点连接方法将应用程序与各种不同的服务相连接的 3 种核心功能和相关的问题。
设想一下一家需要集成 6 个应用程序的中型公司。连接这 6 个应用程序所需的连接略图如图 2 所示。
使用点对点集成方法的 6 个应用程序连接
您可以看到，本例中所需要的连接数目为 15 个。这一数目相当于集成模式中应用程序不同配对的数量。同样地，可以看到，如果此例中有 10 个应用程序，需要的连接数量将为 45。因此，我们可以得出结论，随着应用程序数量增加，需要的连接数量会以非线性方式迅速增加。这被称作一种毛团问题，因为它可能阻碍任何网络。事实上， 可以发现，如果企业要集成 N 个应用程序，点对点方法中需要的连接数量为
N(N-1)/2
这很容易理解，因为应用程序不同配对数量也为 N(N-1)/2。因此，我们可以得出结论，点对点集成模式并不适用于大型企业中的集成，应该找到另一种扩展能力更高的解决方案。
企业服务总线为连接可扩展性问题提供了一个优秀的解决方案，因此适合需要集成大量应用程序的大中型企业。在企业服务总线交互样式中，应用程序 之间不直接进行交互。相反，应用程序连接到总线，总线提供途径以供应用程序之间建立连接。这种间接交互如图 1 所示，其中展示了 6 个应用程序通过使用企业服务总线进行交互。图 1 要注意的最重要一点是，所需的连接数仅为 6。此数量比点对点模式中 6 个应用程序所需的连接数（即 15）少得多。在此图中要注意的另一点是，所需的连接数量等于集成的应用程序数量。因此，如果我们有 10 个应用程序，仅需要 10 个连接。相对于点对点方法中需要的连接数量（即 45），这个连接数量非常小。
ESB 通过提供基于内容和上下文的路由来实现间接连接应用程序的功能。因此，请求应用程序不需要知道目标应用程序的地址，或者甚至不用知道哪些应用程序在提供该服务。
通信协议错误匹配问题出现的原因在于，大型企业中的各个应用程序通常会采用不同的协议进行通信。换句话说，在真实世界中，这些协议会不断增 生，其中包括 HTTP、HTTPS、JRMP、IIOP 和 JMS。由于这种增生现象，服务用户应用程序与服务提供者应用程序之间有时会发生协议错误匹配。因此，没有一种工具来将一种通信协议转换为另一种，服务用 户应用程序将无法调用服务提供者应用程序所提供的服务。此问题的图略如图 3 所示。
协议错误匹配问题
因此，ESB 中应该包含的另一个核心功能就是一个可将一种协议转换为另一种的协议转换工具。使用此转换工具，采用不同协议的应用程序就可彼此交互。值得指出的是，当前 可用的商用 ESB 已提供协议转换支持。例如，我们常常看到从 HTTP（用于异步消息交换）到 MQ 异步消息的转换。出于此用途，可以使用一个关联 ID 来将请求和响应 MQ 消息联系起来。
另一种异构性问题是数据/消息格式错误匹配的问题。此问题指的是这样一个事实，有时服务用户提供的数据格式与服务提供者应用程序所需的数据格式不太匹配。这会阻止应用程序彼此交互，如图 4 所示。
数据格式错误匹配问题
因此，ESB 需要提供的另一种核心功能是数据或消息转换。大多数可用的商用 ESB 都采用不同技术提供了此功能。例如，可采用 XML 样式表实现不同 XML 格式（包括 SOAP）之间转换。当此功能与其他两种 ESB 功能相结合时，应用程序之间可以轻易地进行连接和交互，即使在它们的接口和协议不完全匹配时。
除了满足这 3 种功能需求外，ESB 还实现了服务来满足非功能性需求，比如性能和可靠性、审计和安全性。此外，许多商业 ESB 产品还提供了其他一些可选的服务，比如数据扩充、消息分发、更正和监视。
这些功能和非功能需求可由单个产品或一组产品来满足。换句话说，ESB 基本来讲是一种模式，它没有必要实现为单个产品。
在当前可用 ESB 中，每个应用程序使用一种特定的端口类型来连接 ESB，如图 1 所示。端口类型由应用程序用于公开其功能的服务类型决定。例如，通过 Web 服务公开其功能的应用程序必须使用这样的端口类型，它提供 HTTP 作为通信协议，提供 SOAP 作为消息格式。换句话说，给定的应用程序必须通过一种具体的端口类型连接 ESB，端口类型由应用程序使用的通信协议和消息格式确定。出于许多原因，这种应用程序通过特定类型的端口进行连接的方法既不灵活，也不方便。其中一些原 因是：
- 许多时候，由于需求或运行时环境改变，应用程序希望切换通信协议。但是，这也需要更改 ESB 一端的端口类型，而且几乎肯定需要构建另一种类型的端口。这无疑会消耗不少时间和资源。
- 一种常见情形是，一个应用程序希望使用多种协议来公开不同的功能，大型机 COBOL 应用程序常常会遇到此情况，给定应用程序使用 Web 服务公开它的部分功能，而与此同时，它使用 MQ 等消息传递协议公开另一部分功能。再一次，这需要在 ESB 一端构建新的端口类型来同时提供两种类型的协议，这非常不方便，因为它会耗时又耗资源。
- 在目前可用 ESB 中，很难将 ESB 的用途扩大到新构建的通信协议。这是因为，它需要同时更改应用程序一端和 ESB 一端。在 ESB 一端，需要开发全新的端口类型。
- 因为每个应用程序必须通过一种特定类型的端口连接到 ESB，所以需要花许多工夫来配置 ESB，以供应用程序使用。这些工夫可能包括构建一种新端口类型、将它部署在 ESB 中，并配置 ESB 以使用这个特定的端口。所有这些都使得难以使用 ESB 连接大量应用程序，并进而导致可扩展性问题。
- 另外，由于每个端口必须独立部署和配置，所以很难维护和更新 ESB。
在这期文章中，您了解了集成使用不同格式 SOA 服务的应用程序时所引起的一些问题，以及当前 ESB 的核心功能如何解决这些问题。您还了解到了另外一些与当前可用 ESB 中不同端口类使用相关的问题。这些问题并未得到当前可用 ESB 的解决。
下一期将介绍如何克服当前 ESB 的不足，您将了解一种新的 ESB 类型。这种新 ESB 将采用单一的通用端口类型，它可供大部分或所有采用不同服务类型的应用程序用于公开其部分或所有功能。这将消除或显著减少为每个新应用程序类型开发和部署 新端口类型的需要。新的通用端口类型将带来大量收益，包括较高的代码重用率。使用通用端口类型的收益将在以后的一期中详细介绍。
学习
- 最近新书：“基于 SOA 的企业整合” 提供了一种循序渐进的 SOA 和 Web 服务方法。
- 在 developerWorks 的 SOA 和 Web Service 专区 中，您将找到关于 Web 服务和 SOA 服务的文章、教程、标准和其他技术资源。
- 关于 ESB 基本知识的一个非常不错的资料来源：“基于 SOA 的企业整合” 中的第 8 章。
- 关于 ESB 基本知识的另一个不错的资料来源是一篇 developerworks 文章：“基于服务的企业集成模式轻松入门，第 4 部分：企业服务总线”
- 有关 IBM 的高级 ESB 产品 WebSphere Message Broker (WMB) 的信息，请访问 Message Broker 信息站点。
- 有关来自 IBM 的低成本 ESB 产品的信息，请访问 WebSphere Enterprise Service Bus。
- 有关基于硬件的 ESB 产品的信息，请访问 WebSphere DataPower SOA Appliances。
- 要了解 HTTP 等通信协议的更多信息，请访问：HTTP。
- 关于 SOAP 消息格式信息的一个不错来源是 SOAP Wikipedia。
- 在 IBM SOA 沙盒 中进行试验，通过 IBM SOA 入口点进行实际的新手实践来提高您的 SOA 技能。
- IBM SOA 网站 提供 SOA 的概述，并介绍 IBM 是如何帮助您实现 SOA 的。
- 浏览 技术书店，获得有关这些主题和其他技术主题的图书。
获得产品和技术
下载 IBM 产品评估试用版软件 或 在线试用 IBM SOA 沙盒，并开始使用来自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的应用程序开发工具和中间件产品。