爱华网从上面可以看到ESB的基本功能仍然是数据传输，消息协议转化，路由三大核心功能。有这三大核心功能也可以看到在进行异构系统的整合时候往往根据需要ESB提供这些功能。没有ESB时候也可以实现SOA，比如借助SCA和BPEL来实现SOA，当时却很难实现消息协议转化和动态路由。
ESB在发展过程中有从原有的消息中间件转化为ESB产品的，这类消息中间件和数据总线产品在原有的EAI企业应用集成中应用比较多。而SOA根据强调了基于服务的集成，以WebService服务为基本的管理单元。一个服务的定位是关于如何把业务逻辑表现成为一组相互独立的，自描述的且能互操作的实体。
对于SOA关注的是服务全生命周期，通过服务实现业务价值。而ESB关注的是服务中介和服务的集成，是SOA的基础设施。SOA有两个核心组件，一个是ESB，一个是BPEL，而ESB是基础设施，BPEL是业务流程驱动下服务的集成和整合。离开了SOA，ESB将失去它所连接的服务，而仅仅是一个总线，同时也将变得毫无价值。Bobby做了一个比喻：路是没有任何价值的，除非你利用它把一个东西从一个地方移到另外一个地方。而离开SOA，ESB就像一个没人使用的道路。
做SOA的事情不要先上来建立一个大而全的ESB，相反是关注你的业务问题，找到用SOA的方法来解决业务上的需求，在解决这个问题的过程当中，你会看到一系列的业务服务。这些业务服务是会产生业务价值的。它可以灵活地组装，动态地解决你变化的业务需求。这是它的价值，只有这样才能使你的业务敏捷起来，随需应变起来。而在服务的组装过程中，你再去考虑利用ESB来把他们连接起来。
ESB 需要某种形式的服务路由目录（service routing directory）来路由服务请求。然而，SOA可能还有单独的业务服务目录（business servicedirectory），其最基本的形式可能是设计时服务目录，用于在组织的整个开发活动中实现服务的重用。Web服务远景在业务服务目录和服务路由目录的角色中都放置了一个 UDDI 目录，因而使得可以动态发现和调用服务。这样的目录可以视为 ESB的一部分；然而，在这样的解决方案变得普遍之前，业务服务目录可能与 ESB 是分离的。
标准的 ESB 功能
通信 | 服务交互 |
集成 | 服务质量 |
安全性 | 服务级别 |
消息处理 | 管理和自治 |
建模 | 基础架构智能 |
上面的许多功能既可以使用专有技术实现，也可以通过利用开放标准实现。然而，使用不同的技术来实现 ESB可能会使它们的性能、可伸缩性和可靠性这些特性显著不同，同时 ESB功能和所支持的开放标准也会有所不同。由于这些原因，再加上最近制订和正在兴起的一些相关标准，当今实现 ESB的许多关键决策都涉及到成熟的专有技术和不成熟的开放标准之间的权衡。
支持 SOA 的最低功能的 ESB 实现
如果在前面确定的功能中只有一部分和大多数 SOA 场景相关，我们可能会问：实现 ESB所需的一组最低功能由什么构成？为此，考虑最被普遍认同的 ESB 定义的原理：
最低的 ESB 功能
通信 | 集成 |
服务交互 | |
请注意这些最低功能并不需要使用特别的技术，比如 EAI 中间件、Web 服务、J2EE 或XML。这些技术的使用非常接近也非常符合需求，但是不必强制要求使用它们。相反，最低功能几乎只需简单地使用 SOAP/HTTP 和WSDL 就可以实现（当然不是所有的情况都这样）：
然而，这些 SOAP/HTTP 和 WSDL 的基本应用只是点到点（point-to-point）的集成，并不能实现一些 ESB需要的关键功能：
当然，在许多甚至是大多数情形中往往需要其他的功能，并且这种需要变得越来越常见。特别地，不管是现在还是以后，下面的需求类型可能会导致更复杂高级的技术的使用：
