引言
Web服务旨在处理大型企业中遇到的一些应用程序异构性问题。不过，Web服务本身并不能提供解决异构性问题的完整解决方案。特别是，它们不是为了处理服务使用者和服务提供者应用程序使用的传输协议之间不匹配的情形。与此不匹配情况相关的问题是接口不匹配的问题。此类不匹配情况通常是由于合并和收购的结果造成的。一种可能的解决方案是根据新的 Web服务重写这些应用程序，以消除这些不匹配的情况。但往往是没有足够的开发人员资源或者没有足够的时间来执行如此大量的任务。
在这种情况下，企业服务总线 (ESB) 为解决大型系统中异构性问题提供一个优秀的解决方案。ESB 是面向服务的体系架构 (SOA) 中不可或缺的一部分。它提供了综合、灵活而且一致的集成方法。在ESB 模式中，服务使用者和服务提供者不直接交互；而是通过总线进行通信的。该总线可提供许多功能，其中包括协议转换、数据转换和基于内容和上下文路由的核心功能。您将了解在以下两部分中描述的这些功能和其他常见功能。
考虑使用 ESB的另一个原因是，有时候出于合同或法律的原因必须保证消息的提交。在这些情况下，需要使用 Web服务之外的服务。此类服务的一个示例是使用消息传递软件（例如IBM WebSphere MQ 系列）的异步服务。通过在请求者和服务器端的网络上持久保留消息可以保证消息的提交。
核心功能
通过阅读本系列第 2 部分中的对象请求代理 (ORB) 和异步消息传递，您可以了解到这两种技术都提供基于内容或上下文的某种形式的基本路由。这种基于内容或上下文的路由构成了 ESB的框架。因此，通常使用的 ESB 类型有两种：
基于ORB 产品的 ESB，如IBM WebSphere Application Server。通常，这些产品在处理 Web服务、XML和Java 远程方法调用 (RMI) 方面功能非常强大。使用这些产品的成本相当低而且非常易于设置。但是，对于大量事务和处理较为多样化的应用程序方面伸缩性较低。
基于异步消息传递软件的 ESB 产品，如WebSphere MQ。此类 ESB 产品的一个示例是IBM WebSphere Message Broker。这些 ESB 产品在事务量和处理较为多样化的应用程序方面具有高度伸缩性。但是这些产品较为昂贵，并且需要的设置时间也较长。这两类产品通常具有互操作性。例如，IBM WebSphere Enterprise Service Bus 可以与基于WebSphere Message Broker的 ESB 进行完全互操作。
基于内容的路由本身并不足以解决大型企业中的所有异构性问题。具体来说，通信协议日益增多，包括 HTTP、HTTPS、Internet ORB 间协议（Internet Inter-ORB Protocol，IIOP）、Java 远程方法协议（Java Remote Method Protocol，JRMP）和传输控制协议（Transmission Control Protocol，TCP）。因此，您会发现服务使用者可能仅被设置为使用一种协议，但服务提供者更愿意使用不同的协议。如果没有将一种协议转换为另一种协议的工具，则服务使用者很难与给定的服务提供者进行通信。与此需求相关的需求是使用者喜欢的数据格式可能与服务提供者使用的数据格式不同。因此，还需要一种能够提供此数据转换的工具。总的来说，ESB 提供的最少功能包括：
基于上下文或内容的路由。
协议转换。
数据转换。
如果一个组件中包括这些最少功能，则该组件即成为提供虚拟化的服务总线，因此应用程序不需要直接相互通信。图 1 显示了此间接交互的示意图。
图 1. 通过 ESB 间接交互
