尽管企业服务总线（ESB）不是什么新东西，但却仍旧是一个充满困惑的交集点。经过这么多年的那么多的实施，它们是做什么的、它们是怎么做的，以及具体的产品是否有助于创建一个面向服务架构，这一切仍都是需要讨论的东西。

　　Chris Harding是开放群组（The Open Group）负责SOA及客户计算的论坛管理员，他则认为ESB的性质并不总是清晰的。他指出，互联网有TCP，这个东西是一切的标准与核心。而在ESB的企业软件栈上面则没有类似的东西。“你所拥有的不过是在对ESB是做什么事情的这方面，有一个良好的共同理解，但却又缺乏严格定义的接口。这个东西要松散得多。”他说。

　　按照Harding的说法，人们在讨论ESB的时候，他们想要的一个关键的东西是利用ESB作为消息传递总线来交换信息的能力。“在消息转换方面，在你的组合服务乃至作为复合引擎的能力方面，这一基本愿景都可以增加许多其他的东西，但是其核心是消息传递”。

　　从历史上看，Harding介绍，一度有许多关注于ESB是否是SOA必不可少的部分的讨论。他表示：“从理论上看，答案是否定的。”相反，SOA需要的是面向服务的架构，对组件即服务的定义，对服务定义的识别以及那些服务的松耦合，他这样解释。

　　然而，Harding指出，一旦组织实现了服务之间消息交换的松耦合，通常他们会发现其面向服务架构的关键部分是ESB作为消息交换的方式。

　　Ken Volmer是研究机构Forrester的一位分析师，他说ESB处理不同组件之间的交互，创建并引导服务，甚至还提供组件之间的协调。

　　“ESB是使得某人有效实现SOA的管道”，他补充道。

　　实现那个远大的架构愿景则是另一回事。Volmer说一个好的起点是架构参考模型。他说：“自从首次ESB讨论以来，人们就其应该包含一个架构层、一个连接层、一个中介层以及一个协调层已经达成了广泛的共识。”

　　引用Forrester最近的一份报告《ESB参考架构模型》（The ESB Reference Architecture Model）的说法，Volmer说，若干ESB组件必须协同工作以提供基本的ESB框架来实现可用性（通常而言，是通过集群的方式）、联邦（为了支持ESB的互操作）、拓扑结构（如星形结构）及可扩展性（这样客户就可以自行增加容量）。

　　ESB是面向服务的一个例子，对于许多组织来说它仍是“一种不同的做事方式”。他认为人们习惯于进行点到点的集成，而通过ESB的话你可以用多种方式对代码进行一次创建多次重用。克服那种开发任何东西都要白手起家的思想很关键——然后利用ESB来帮助实现SOA可以令生活更简单。“但是开发人员仍然喜欢写代码，而这一点会是个问题”，他补充道。

　　Volmer说其中一个主要的挑战是实现ESB市要确保你在购买产品前能拥有合适的产品。如果吞吐量是关键需求，那么你必须在购买前产品前在本地对其进行测试。他表示：“耳听为虚眼见为实，不要乱买东西。”。

　　根据Volmer的说法，实现ESB并不尽然是那么困难的。他说挑战的难度严重依赖于参与ESB的人的技术水平。他说：“实现它并不简单，但是我们已经突破了前沿阶段；ESB已经发展了有8到10个年头了，因此供应商已经让其使用起来要容易得多了。”
“因此”，他说：“实现ESB对于一个组织得当的IT部门来说不是什么重大挑战”。

　　Volmer说Forrester已经访问了20家最近实现了ESB的公司，并没有发现有什么特别困难繁重的领域。“最重要的是，集成已经是一种不同的方式了，”他补充道。然而，他指出，在问题浮出水面的初步实现阶段，约有80%的问题似乎都与架构和平衡有关，只有20%的问题与调优相关联。

　　“从我的理论视角来看，ESB最能激发我兴趣的东西是，从一个ESB将服务输送到另一个ESB究竟有多容易，” Hardy补充说。