ESB（Enterprise Service Bus，企业服务总线）是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。
ESB（Enterprise Service Bus，企业服务总线），是过去消息中间件的发展。ESB采用了“总线”这样一种模式来管理和简化应用之间的集成拓扑结构，以广为接受的开放标准为基础来支持应用之间在消息、事件和服务的级别上动态的互连互通。 ESB是一种在松散耦合的服务和应用之间标准的集成方式。它可以作用于：面向服务的架构－分布式的应用由可重用的服务组成 面向消息的架构－应用之间通过ESB发送和接受消息 事件驱动的架构－应用之间异步地产生和接收消息
在SOA实现的早期阶段，当目录仅仅由一个或者两个基于项目的服务组成的时候，ESB看起来是英雄无用武之地。但是幸运的是，如果在企业中采用ESB，那么服务的部署会被加速。任何一项策略都被要求能够提供随需应变的扩展性，可靠性和足够的性能等特点。从构架的角度，使用一个合理的原则避免服务混乱不失为一个好的想法。随着企业SOA的逐步成熟，业务功能会从各种源头被挖掘和发现出来。这些服务的提供者可能是遗留的应用，第三方软件包或者主要解决方案提供的功能。虽然理想状态是所有这些服务都使用相同的技术，但是现实情况证明这是不可能的。很有可能Web Service标准仅仅是使用的技术中的一个而已。
ESB是逻辑上与SOA 所遵循的基本原则保持一致的服务集成基础架构，它提供了服务管理的方法和在分布式异构环境中进行服务交互的功能。可以这样说，ESB是特定环境下(SOA架构中)实施EAI的方式：首先，在ESB系统中，被集成的对象被明确定义为服务，而不是传统EAI中各种各样的中间件平台，其次，ESB明确强调消息(Message)处理在集成过程中的作用，这里的消息指的是应用环境中被集成对象之间的沟通。最后，事件驱动成为ESB的重要特征。
考虑一个ESB作为一个中间件平台提供许多与中央运行时处理过程和服务管理相关的特性。由ESB主导的服务能够以Web服务的形式发布，并且只要服务合约是由客户定制的(理想情况下是标准化的)，你可以非常确信地认为你能够暴露服务逻辑而不需要将合约匹配到任何底层基础服务实现细节上去。这将给你充分的自由去将服务安置到另外一个ESB平台上或者其它地方上。而且这个可选择性并不会让ESB变得孤立。
专家答疑
技巧
当我期望用BPM建模工具来配合面向服务架构的时候， 应该在工具中寻求的关键特征是什么呢？当设法确信你的BPM工具充分利用你的SOA成果时……
横跨许多大洲和时区，做分布式软件开发是现实的。根据我的经验，在分布式开发环境中，瀑布式和敏捷软件开发方案都有缺点。
假设：CEO或者CIO说我希望就我们可以在云端做什么做一下分析，特别是在节约成本方面。在回顾打算采纳云的提议的时候，架构师应该问些什么问题？
本周
本月
