这是一个相当高层次的抽象概念。核心概念是ESB提供中间件和接口，使企业能够在不编写代码的情况下连接其应用程序。
这可能包括通过调解来协调不兼容的协议、数据和交互。
将所有内容都经过中央总线传递的想法为附加层次的抽象提供了机会。使用行业标准将其他应用程序、客户端等“插入”到这个总线中，使得连接新服务、数据源和具有不同需求的客户端变得相对容易。
就实际实现而言，这是非常大型企业支持企业的领域。虽然它非常时髦，但目标是理想状态，可以通过与互联网进行比较，在某些小范围内理解：
一个大型通信总线，具有广泛不同的用途和数据，但所有运行标准化协议。
事实上，可以编写一个HTTP到FTP连接器，使浏览器可以访问FTP站点而不需要调用FTP客户端（通常已内置于浏览器中）。
混搭演示了一种有趣的实现方式-从旧金山机构获取公交路线数据，从谷歌地图中获取地图数据，从雅虎地图中获取带评级的寿司餐厅位置，并运行一个简单的查询，以便找到最近的寿司餐厅，如果餐厅更好，则愿意走更远的路程。
所有完全不同的服务，本身不兼容，但使用标准连接器（例如Yahoo Pipes），它们可以被组合成一个连贯且有用的整体。
-Adam
我对商业ESB的经验是它是一种过度夸大和昂贵的技术，解决问题的同时也会创造许多问题。ESB将连接新系统和旧系统，消息将通过总线传输，所有东西都能够无缝地相互通讯。加入一些弹性、编排等功能，就可以拥有一个非常强大的企业应用软件。
问题出现在尝试实际使用它们时，撰写总线、创建消息结构等管理开销可能会超过其好处。作为高成本的项目，ESB被视为解决所有技术问题的万灵药，但事实并非如此，太多时间花费在总线上而非应用程序/数据连接上。通常情况下，多个竞争标准会在同一组织内争夺统治地位，导致这些系统实际上应该修复的典型技术主导的孤立状况。
在我看来，更好的做法是创建一小部分特定接口，通常在仅需要的系统之间使用Web服务。
这基本上是一种设计系统的概念方法 - 软件公司试图通过在其上贴上“ESB”标签来卖更多的软件，而经理们喜欢它，因为ESB从“高层次”看起来很好。
ESB基本上是带有附加数据模型和结构定义管理的消息导向中间件（MOM）。您可以为总线上的所有应用程序和适配器定义一个公共的数据定义（可以是具有共享XSD的XML）。连接到总线上的任何内容都必须按照此数据定义发送其信息。ESB支持加载、共享和版本控制此通用数据定义。将新组件连接到ESB时，您可以期望开箱即用的更多“兼容性”，而不是将其连接到MOM。总线上的每个组件在概念上都被视为“资源”，因此引入了其他抽象以解耦发送方和接收方。
例如：假设您想在标准的消息导向中间件中（例如JMS）将应用程序A与应用程序B连接起来，您需要与正在处理应用程序B的同事交谈，达成有关主题、消息类型和字段的协议，并发送以下伪代码：sendJms("TRADE.MSFT", {MapMessage trader="pete" price=101.4 vol=100})
如果您在面向服务的架构中执行同样的操作，则需要：
第一次可能有点痛苦，但我想您可以适应它，就像适应EJB一样。
您可以说MOM系统是“无类型”的（动态结构），而ESB是“类型化”的（静态结构）。与其他未命名/已命名的选择相比，原始消息传递和ESB之间的权衡类似于：
对于较小的项目，快速确定功能很好（例如Groovy代码），但对于较大的项目，拥有调试器很重要（例如Java），可以在出现故障之前提前警告，并为人们在提交项目之前提供标准。
因此，如果您的项目遭受太多人通过提交未经验证的更改来破坏系统，请向更具结构化的方向发展（使用ESB而非MOM）。 如果您的项目无法按时完成足够的任务，请选择更简单、无类型的解决方案。 如果两者都存在，则需要顾问（开个玩笑;-)
这要看你问的是谁了... 许多人会说ESB是一种“中间件”，它将各种“业务逻辑”模块连接在一起，以消除模块之间的编码消息传递。我认为这是一个足够概括的定义，但是我相信你已经通过维基百科等了解了这些内容。
那些希望ESB拯救世界的人们认为，它最常见的用途是作为一个可做任何事情的中心枢纽。大多数ESB实现致力于封装我们在商业软件中看到的所有重复任务。这意味着大多数ESB负责数据传输、安全性、日志记录、协议转换、事件系统、通过Web服务公开API等。
我想这是我能做到的最清楚的表述了... 希望对你有所帮助。
请查看我的演示文稿 "纠结不已 - 如何选择合适的ESB".
我解释了何时使用ESB、集成套件或仅使用集成框架（如Apache Camel），同时讨论开源和专有ESB之间的差异。
然而，它相当昂贵、复杂且不方便维护和扩展，这使得它作为一个通用工具来扩展您的应用程序的技术选择较差。
