激活SOA的全部潜力还需五年。即使用企业服务总线（Enterprise Service Bus，ESB）是实现ESB全部潜力4步中的第三步。模型中的步骤如下：
使用XML，以更标准的方式使用应用程序接口。
捕获一些业务过程，并将它们转化成为Web服务。
引入并全面使用企业服务总线。
产生业务过程执行语言（Business Process Execution Language，BPEL），它可由业务过程建模工具完成。BPEL可以改变应用程序的行为，而无需修改软件。
Rippert先生在采访中表示，尽管很多组织拥有ESB，但是它并没有被完全利用。他进一步的表示，大多数公司仍处于阶段1。与这个ESB所处位置的论断相对比的是，Burton Group的分析师Anne Thomas Manes的叙述，其发表于近期面向服务架构Yahoo Group的讨论中。Anne说：
......如果缺少我推荐启动SOA的“基本组件”，ESB将不会列在我的清单中。事实上，我并不鼓励人们由ESB开始。ESB并不会鼓励好的SOA行为。ESB本质上是集成系统，而非SOA系统。SOA是用于拆卸应用竖井（application silos），而集成系统则是修补这些竖井。
引用她的书，她接着提及的基本组件包括：
一个或多个服务平台（如，.NET，Java EE应用服务器等）
SOA管理解决方案
注册表
如果服务要被暴露在防火墙之外，那么需要XML网关
引用组员早期的帖子，她说道：
“......ESB特别适合桥接传统应用，因此，在服务基础设施中，它是一个有用的组件。很多ESB也支持可靠消息传递、异步消息传递和发布/订阅交换模式。这些能力都非常有用，但是，在SOA项目的初始阶段可能不会发挥多大的用途。（每个组织有很多不选用这些能力的项目。）在SOA项目的后期，你还可能需要一个编制（orchestration）引擎，并且大多数的ESB都会提供一个。即便如此，ESB也绝对不是组织启动SOA的起点。所有这些能力你一开始并不需要。因此，ESB应该在后期购买。”
这似乎符合Rippert先生的观点，即尽管很多组织拥有ESB，但是它并没有被完全利用。Manes女士的评论同样有助于定义ESB的范围，通过暗示许多ESB支持的特性，它确定了一组适当的能力。
根据维基百科的ESB定义，ESB有如下特性：
它是面向服务架构的实现。
它通常是操作系统和编程语言无关的；它应能在Java和.Net应用程序之间工作。
它使用XML（可扩展标识语言）作为标准通信语言。
它支持Web服务标准。
它支持消息传递（同步、异步、点对点、发布-订阅）。
它包含基于标准的适配器（如J2C/JCA），用于集成传统系统。
它包含对服务编制（orchestration）和编排（choreography）的支持。
它包含智能、基于内容的路由服务（itenerary路由）。
它包含标准安全模型，用于ESB的认证、授权和审计。
它包含转换服务（通常是使用XSLT），在发送应用和接收应用之间转换格式，简化数据格式和值的转换。
它包含基于模式（schema）的验证，用于发送和接收消息。
它可以统一应用业务规则，充实其它来源的消息，分拆和组合多个消息，以及处理异常。
它可以条件路由，或基于非集中策略的消息转换，即不需要集中规则引擎。
它可监视不同SLA（服务级别合约）的消息响应门限，以及在SLA中定义的其它特性。
它（常常）简化“服务类别”，向更高或更低优先级用户做出适当的响应。
它支持队列，在应用临时不可用时用来保存消息。
它由（地理）分布式环境中的选择性部署应用适配器组成。
看起来，共识之一是ESB是与编制（orchestration）和业务过程管理（Business Process Management）截然不同的单独一类产品。此外，对于ESB到底是产品还是模式还有很大的争议。
在本系列的第二部分，InfoQ调查了ESB的使用目的 - ESB的使用案例和需求是什么？
Sonic公司的Dave Chappell开启前文中的讨论，部分1暗示了Sonic软件公司可能事实上正试图标准化基于UML的模式集，实质上，它们定义了ESB的参考架构。
Stuart Charleton（BEA系统策略咨询服务的企业架构师，位于Canada的Toronto）提供了以下的使用例子：
消费者使用基于HTTP/S的认证，生产者使用WS-Security。
消费者使用HTTP/RSS，生产者使用WebSphere MQ或JMS。
消费者使用HTTP/REST和URI，生产者使用SOAP/WSDL。
消费者有一组证书，生产者有另一组（键链映射）。
一端使用FTP站点作为“服务接口”，而另一端文件被拆分成JMS消息。
在路由到目的地之前，消息需要被充实，这样就可以执行callout来收集额外信息。
生产者要求协议独立的负载均衡和/或故障转移。
消息需要被存储转发，在不可靠服务上改进可靠性。
同时，作为这些主题的补充，Paul Fremantle（WSO2的共同创建者和技术副总裁）增加道：
因此，ESB是实现仲裁（mediation）的通信基础设施。ESB应该有什么样的拓扑结构呢？我认为它应该是灵活的：你可以将ESB构建为中间层的单个且大的代理，也可是很多智能终端。当然，拓扑结构会影响可管理性，但是只要有配置ESB的中心注册表/仓库，那么它将工作很好。这其中的关键点是ESB应该由策略而非书写代码驱动。
Burton Group的Anne Thomas Manes也说道：
“......ESB特别适合桥接传统应用，因此，在服务基础设施中，它是一个有用的组件。很多ESB也支持可靠消息传递、异步消息传递和发布/订阅交换模式。这些能力都非常有用，但是，在SOA项目的初始阶段可能不会发挥多大的用途。（每个组织有很多不选用这些能力的项目。）在SOA项目的后期，你还可能需要一个编制（orchestration）引擎，并且大多数的ESB都会提供一个。即便如此，ESB也绝对不是组织启动SOA的起点。所有这些能力你一开始并不需要。因此，ESB应该在后期购买。”
以上强调将ESB作为桥接传统应用的手段。Network Computing的近期研究中：调查一组回答者，让他们使用“从强烈同意到强烈反对”的标准，为一组关于ESB技术的表述评分。回答者强烈同意的前4个表述是：
ESB必须给企业数据源（SAP、Peoplesoft、Oracle、SQL Server）提供适配器。
ESB必须至少支持基础的业务过程管理。
ESB实现需要支持开放标准（JMS、Web服务）。
ESB必须与现有的企业应用集成（EAI）和面向消息产品平滑集成。
这暗示着传统数据源（如ERP和EAI系统）是ESB的重要接口，并且它们应该将那些应用层作为基于标准的消息暴露。有趣的发现是，终端用户似乎同意"至少基础的"业务过程管理是ESB“必须支持的”。
关于最后的评论，Steve Jones（来自CapGemini）暗示，ESB的问题事实上是3个毫不相关的问题：集成、构建和业务。
……第一个挑战是利用现有资产发掘功能（集成），第二个则是构建新的应用（构建），最后则是管理新应用间的交互（业务）。待会儿我将在我的博客中讨论这些。
集成产品有很多非常不同的需求，并且驱动力来自于人们想在更面向标准的空间中实现交互，而我不太确定混淆这两个领域为什么有意义。同样的，构建新应用（使用过程或面向对象语言）则需要不同的技术和方法。
集成总线以其能力作为衡量标准，而业务服务总线则在于简单性和应用开发解决方案的灵活性。并且无论何种合理规模的业务也不会有一劳永逸的解决方案。
ESB综述的第二部分期望能帮助定义用户要求的使用案例，尤其是当他们需要ESB时。共识是：业务过程工具与ESB是不同的，加上ESB包含来自最终用户的完全相反的兴趣，这也暗示着可能将不同种类的产品合并为成了一个。
欲了解这个讨论，请关注适合于ESB的使用案例。
使用XML，以更标准的方式使用应用程序接口。
捕获一些业务过程，并将它们转化成为Web服务。
引入并全面使用企业服务总线。
产生业务过程执行语言（Business Process Execution Language，BPEL），它可由业务过程建模工具完成。BPEL可以改变应用程序的行为，而无需修改软件。
Rippert先生在采访中表示，尽管很多组织拥有ESB，但是它并没有被完全利用。他进一步的表示，大多数公司仍处于阶段1。与这个ESB所处位置的论断相对比的是，Burton Group的分析师Anne Thomas Manes的叙述，其发表于近期面向服务架构Yahoo Group的讨论中。Anne说：
......如果缺少我推荐启动SOA的“基本组件”，ESB将不会列在我的清单中。事实上，我并不鼓励人们由ESB开始。ESB并不会鼓励好的SOA行为。ESB本质上是集成系统，而非SOA系统。SOA是用于拆卸应用竖井（application silos），而集成系统则是修补这些竖井。
引用她的书，她接着提及的基本组件包括：
一个或多个服务平台（如，.NET，Java EE应用服务器等）
SOA管理解决方案
注册表
如果服务要被暴露在防火墙之外，那么需要XML网关
引用组员早期的帖子，她说道：
“......ESB特别适合桥接传统应用，因此，在服务基础设施中，它是一个有用的组件。很多ESB也支持可靠消息传递、异步消息传递和发布/订阅交换模式。这些能力都非常有用，但是，在SOA项目的初始阶段可能不会发挥多大的用途。（每个组织有很多不选用这些能力的项目。）在SOA项目的后期，你还可能需要一个编制（orchestration）引擎，并且大多数的ESB都会提供一个。即便如此，ESB也绝对不是组织启动SOA的起点。所有这些能力你一开始并不需要。因此，ESB应该在后期购买。”
这似乎符合Rippert先生的观点，即尽管很多组织拥有ESB，但是它并没有被完全利用。Manes女士的评论同样有助于定义ESB的范围，通过暗示许多ESB支持的特性，它确定了一组适当的能力。
根据维基百科的ESB定义，ESB有如下特性：
它是面向服务架构的实现。
它通常是操作系统和编程语言无关的；它应能在Java和.Net应用程序之间工作。
它使用XML（可扩展标识语言）作为标准通信语言。
它支持Web服务标准。
它支持消息传递（同步、异步、点对点、发布-订阅）。
它包含基于标准的适配器（如J2C/JCA），用于集成传统系统。
它包含对服务编制（orchestration）和编排（choreography）的支持。
它包含智能、基于内容的路由服务（itenerary路由）。
它包含标准安全模型，用于ESB的认证、授权和审计。
它包含转换服务（通常是使用XSLT），在发送应用和接收应用之间转换格式，简化数据格式和值的转换。
它包含基于模式（schema）的验证，用于发送和接收消息。
它可以统一应用业务规则，充实其它来源的消息，分拆和组合多个消息，以及处理异常。
它可以条件路由，或基于非集中策略的消息转换，即不需要集中规则引擎。
它可监视不同SLA（服务级别合约）的消息响应门限，以及在SLA中定义的其它特性。
它（常常）简化“服务类别”，向更高或更低优先级用户做出适当的响应。
它支持队列，在应用临时不可用时用来保存消息。
它由（地理）分布式环境中的选择性部署应用适配器组成。
看起来，共识之一是ESB是与编制（orchestration）和业务过程管理（Business Process Management）截然不同的单独一类产品。此外，对于ESB到底是产品还是模式还有很大的争议。
在本系列的第二部分，InfoQ调查了ESB的使用目的 - ESB的使用案例和需求是什么？
Sonic公司的Dave Chappell开启前文中的讨论，部分1暗示了Sonic软件公司可能事实上正试图标准化基于UML的模式集，实质上，它们定义了ESB的参考架构。
Stuart Charleton（BEA系统策略咨询服务的企业架构师，位于Canada的Toronto）提供了以下的使用例子：
消费者使用基于HTTP/S的认证，生产者使用WS-Security。
消费者使用HTTP/RSS，生产者使用WebSphere MQ或JMS。
消费者使用HTTP/REST和URI，生产者使用SOAP/WSDL。
消费者有一组证书，生产者有另一组（键链映射）。
一端使用FTP站点作为“服务接口”，而另一端文件被拆分成JMS消息。
在路由到目的地之前，消息需要被充实，这样就可以执行callout来收集额外信息。
生产者要求协议独立的负载均衡和/或故障转移。
消息需要被存储转发，在不可靠服务上改进可靠性。
同时，作为这些主题的补充，Paul Fremantle（WSO2的共同创建者和技术副总裁）增加道：
因此，ESB是实现仲裁（mediation）的通信基础设施。ESB应该有什么样的拓扑结构呢？我认为它应该是灵活的：你可以将ESB构建为中间层的单个且大的代理，也可是很多智能终端。当然，拓扑结构会影响可管理性，但是只要有配置ESB的中心注册表/仓库，那么它将工作很好。这其中的关键点是ESB应该由策略而非书写代码驱动。
Burton Group的Anne Thomas Manes也说道：
“......ESB特别适合桥接传统应用，因此，在服务基础设施中，它是一个有用的组件。很多ESB也支持可靠消息传递、异步消息传递和发布/订阅交换模式。这些能力都非常有用，但是，在SOA项目的初始阶段可能不会发挥多大的用途。（每个组织有很多不选用这些能力的项目。）在SOA项目的后期，你还可能需要一个编制（orchestration）引擎，并且大多数的ESB都会提供一个。即便如此，ESB也绝对不是组织启动SOA的起点。所有这些能力你一开始并不需要。因此，ESB应该在后期购买。”
以上强调将ESB作为桥接传统应用的手段。Network Computing的近期研究中：调查一组回答者，让他们使用“从强烈同意到强烈反对”的标准，为一组关于ESB技术的表述评分。回答者强烈同意的前4个表述是：
ESB必须给企业数据源（SAP、Peoplesoft、Oracle、SQL Server）提供适配器。
ESB必须至少支持基础的业务过程管理。
ESB实现需要支持开放标准（JMS、Web服务）。
ESB必须与现有的企业应用集成（EAI）和面向消息产品平滑集成。
这暗示着传统数据源（如ERP和EAI系统）是ESB的重要接口，并且它们应该将那些应用层作为基于标准的消息暴露。有趣的发现是，终端用户似乎同意"至少基础的"业务过程管理是ESB“必须支持的”。
关于最后的评论，Steve Jones（来自CapGemini）暗示，ESB的问题事实上是3个毫不相关的问题：集成、构建和业务。
……第一个挑战是利用现有资产发掘功能（集成），第二个则是构建新的应用（构建），最后则是管理新应用间的交互（业务）。待会儿我将在我的博客中讨论这些。
集成产品有很多非常不同的需求，并且驱动力来自于人们想在更面向标准的空间中实现交互，而我不太确定混淆这两个领域为什么有意义。同样的，构建新应用（使用过程或面向对象语言）则需要不同的技术和方法。
集成总线以其能力作为衡量标准，而业务服务总线则在于简单性和应用开发解决方案的灵活性。并且无论何种合理规模的业务也不会有一劳永逸的解决方案。
ESB综述的第二部分期望能帮助定义用户要求的使用案例，尤其是当他们需要ESB时。共识是：业务过程工具与ESB是不同的，加上ESB包含来自最终用户的完全相反的兴趣，这也暗示着可能将不同种类的产品合并为成了一个。
欲了解这个讨论，请关注适合于ESB的使用案例。