本文将 ESB(企业服务总线) 描述为由中间件技术实现并支持 SOA 的一组基础架构功能。ESB 支持异构环境中的服务、消息，以及基于事 件的交互，并且具有适当的服务级别和可管理性。为了达到此目的，需要将多种功能集中起来并加以分类。然而，并不是 ESB 能够传递值的每 一种情形都需要所有的功能。

　　IBM认为，为了实现 SOA，应用程序和基础架构都必须支持 SOA 原则。启用 SOA 应用程序涉及到 创建服务接口，服务接口可以直接也可以间接地通过使用适配器用于现有的或新的功能。从最基本的级别来看，启用该基础架构涉及到规划功 能来将服务请求路由和传递给正确的服务提供者。然而，基础架构支持在不影响服务的客户端的情况下由另一个服务实现替代原有的服务实现 也是至关重要的。这不仅需要根据 SOA 原则指定服务接口，而且需要基础架构允许客户端代码以独立于所涉及的服务位置和通信协议的方式来 调用服务。这样的服务路由和替代是 ESB 的许多功能中的一部分。

　　ESB 支持这些服务交互功能，并通过提供集成的通信、消息 传递以及事件基础架构来支持这些功能。因此，它将当今正在使用的主要企业集成模式组合成一个实体。ESB 为 SOA 提供与企业需要保持一致 的基础架构，从而提供合适的服务级别和可管理性、以及异构环境中的操作。

　　本文剩余部分将讨论 ESB 在 SOA 中的角色，包括 除了基本的路由和传输以外，它所提供的的功能，如下面的 ESB 功能模型部分中所述。

　　ESB 结构ESB 有时被描述为分布式基础 架构，这与其他的解决方案形成了对比，比如消息代理技术一般被描述为中心辐射型(hub-and-spoke)。然而，这并不是真正的差别。有两个 不同的问题正被研究:控制的集中和基础架构的分布。ESB 和中心辐射型(hub-and-spoke)解决方案都集中控制配置，比如服务交互的路由、 服务命名等等。同样，这两个解决方案可能部署在简单的集中式基础架构中，也可能采用更复杂的分布式方式进行部署。

　　毫无疑 问，不同的技术对它们所支持的物理部署模式有不同的约束–有些可能适合于非常广泛的分布，以支持在很大的地理范围内进行的集成，而其 他的可能更适合于部署在本地群集中，以支持高可用性和扩展性。使物理分布需求与候选技术的功能相匹配是 ESB 设计的一个重要方面。另外 的一种能力也是非常重要的，就是以增量方式扩展最初的部署来反映不断变化的需求、集成附加的系统或扩展基础架构的物理范围。

　　还应该在 SOA 基础架构中 定位ESB 与其他组件之间的关系，特别是与 Service Directory、Business Service Choreography、以及 Business-to-Business (B2B) Gateway 这些组件之间的关系。由于上述 SOA 原则对这些组件并没有严格的要求，所以可以将它们视为可选组 件。

　　ESB 需要某种形式的服务路由目录(service routing directory)来路由服务请求。然而，SOA 可能还有单独的业务服务 目录(business service directory)，其最基本的形式可能是设计时(design-time)服务目录，用于在组织的整个开发活动中实现服务的重 用。Web 服务远景在业务服务目录和服务路由目录的角色中都放置了一个 UDDI 目录，因而使得可以动态发现和调用服务。这样的目录可以视 为 ESB 的一部分;然而，在这样的解决方案变得普遍之前，业务服务目录可能与 ESB 是分离的。

　　Business Service Choreographer 的作用是通过若干业务服务来组合业务流程;因此，它将通过 ESB 调用服务，然后再次通过 ESB 将业务流程公开为客户端可 用的其他服务。然而，Business Service Choreographer 在编排业务流程和服务中所扮演的角色确定了这种业务工作流技术是一种与基础架构 技术 ESB 分离的技术。

　　最后，B2B Gateway 组件的作用是使两个或多个组织的服务在受控且安全的方式下对彼此可用。这有助 于查看这些连接到 ESB 的组件，但它们并不是 ESB 的一部分。虽然有一些网关技术可以提供适合于实现 B2B Gateway 组件和 ESB 的功能， 但是 B2B Gateway 组件的用途是将其与 ESB 分离。事实上，这种用途可能需要附加的功能(如合作伙伴关系管理)，这些功能不是 ESB 的一 部分，并且不一定受到 ESB 技术的支持。