本文将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技术的支持。