http://www.cnblogs.com/skyme/archive/2012/08/06/2623414.html

企业服务总线（Enterprise Service Bus，ESB）的概念是从面向服务体系架构(Service Oriented Architecture， SOA)发展而来的。SOA描述了一种IT基础设施的应用集成模型；其中的软构件集是以一种定义清晰的层次化结构相互耦合。一个ESB是一个预先组装的SOA实现，它包含了实现SOA分层目标所必需的基础功能部件。

在企业计算领域，企业服务总线是指由中间件基础设施产品技术实现的、 通过事件驱动和基于XML消息引擎，为更复杂的面向服务的架构提供的软件架构的构造物。企业服务总线通常在企业消息系统上提供一个抽象层，使得集成架构师能够不用编码而是利用消息的价值完成集成工作。

企业服务总线提供可靠消息传输，服务接入，协议转换，数据格式转换，基于内容的路由等功能，屏蔽了服务的物理位置，协议和数据格式。

什么是SOA

面向服务的体系结构（Service-Oriented Architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。

实现SOA的常用技术

实现SOA架构的常用技术有Web Services，JMS和BPEL等。

• ESB技术。企业服务总线（Enterprise ServiceBus，ESB）是构建基于SOA解决方案时所使用基础架构的关键部分，是由中间件技术实现并支持SOA的一组基础架构功能。它是一种为进 行连接服务提供的标准化的通信基础结构。基于开放的标准，为应用提供了一个可靠的、可度量的和高度安全的环境，并可帮助企业对业务流程进行设计和模拟。对 每个业务流程实施控制和跟踪、分析并改进流程和性能。目前各大IT公司都推出了基于自己的平台工具的ESB产品，如IBM的WebSphere ESB、BEA的AqusLogic Service Bus等。除此之外，也出现了众多的开源ESB产品，如Mule、ServiceMix和Apache Synapse等。
• web Services技术。Web Services主要是为了使原来各孤立的站点之间的信息能够相互通信、共享而提出的一种接口。该接口隐藏了服务实现的细节，允许通过独立于服务实现、独 立于硬件或软件平台、独立于编写服务所使用的编程语言的方式使用该服务。Web Services可以通过HTTP、SOAP（XML）、SMTP等协议的组合被访问，利用标准网络协议和XML数据进行通信，具有良好的普适性和灵活 性，这使得基于web Services的应用程序具备松散耦合、面向组件和跨技术实现的特点例5。Web Services技术的主要目标是在各种异构平台的基础之上构建一个同样的、与平台与语言无关的技术层，各种应用都可以靠这个技术层来实施彼此的连接和集成。
• JMS技 术。Java消息服务（Java Message Ser．vice，JMS）是访问企业消息系统的标准API，是Sun公司提出的Java消息服务规范，是用于访问消息系统的不依赖于某个具体厂商的 API，它提供给应用程序创建、发送、接受和渎取消息的接口，具体实现可以不同。JMS技术采用异步通信模式，发送消息者将需要变更的数据消息提交到消息 平台后，就完成了自己的任务，就可以进行其他的操作。不需要等待服务器端的消息处理结果。这时即使网络出现故障甚至服务器崩溃也不会造成数据的丢失或不一 致，消息会保存在消息队列中直到被最终接收。

SOA的环境

从下面的图中来看SOA是实现架构：

　　　　　　　　　　　　　　　　　　图：SOA部署环境图

我们从下向上看：

• Business Systems：最下边也就是我们的业务系统，可以是ERP，可以是CRM也可以是OA等我们正在使用的业务系统。
• Low Level Services：低层次服务，就是我们直接暴露出来并没有经过加工处理的服务，比如说一个数据的抽取、一个业务模块的管理，也就是比较细粒度的服务。
• Composite Services：综合服务，可以理解成更高层次的服务，因为接口暴露出来后并不是直接给应用程序调用或者是给其它服务使用，当然那样也是可以的。我们对低层次的服务进行必要的封装，形成高层次的服务，好处是显而易见的，安全性、应用逻辑的封装，必要的负载，也就是说，更高层次只需要关心他需要的接口，至于如何实现，通过多少细粒度的服务完成这个不是它所关心的东西。
• Orchestrated Business Processes：业务流程，也就是我们常说的BPM，有了上边的解释，这一部分就很清晰了，对于用户来说，比如他通过互联网交话费，他只需要确认自己已经交成功就可以了，也就是说，页面上有了相应的提示，OK，他就可以去做其它事情了，而下边需要如何处理，怎样走流程，就是按照BPM中设计好的流程执行。
• ESB：从图上看ESB放在了最左边，也就是上面几个应用的左边，而且全部包含在内，那么也就是说，ESB处理的就是各个层次之间的通信，包括路由、协议转换和消息传递等。
• Presentation Services：表示层服务，其实这个就很容易理解了，也就是我们对外暴露的接口或者服务内容，可以是一个jms、一个webservice调用、甚至是一个页面。

ESB解决的问题

当你的应用像下面一样时，这个时候就需要考虑使用ESB了，如图：

　　　　　　　　　　图：未使用ESB的应用架构

各个应用系统之间的调用形成了一张网，没有逻辑，随着业务的增加，维护简直就是一场恶梦。

　　　　　　　　　　图：使用ESB中介和代理之后

 各个应用的逻辑很清晰，每个应用都只需要关心如何暴露自己的服务，而调用的应用只需要知道如何调用服务，至于怎么做，去找谁，则完全交给ESB来完成。

开源ESB

以下是几个比较流行且好用的开源的esb：

• Mule ESB：MuleSoft是Mule ESB创建者。Mule ESB是一种广泛的开源ESB下载。
• WSO2 ESB：WSO2 ESB旨在极端轻量型和可扩展性。它包括服务交互图形编辑和XML支持。
• Apache ServiceMix ESB：Apache Service Mix ESB以Java业务集成为标准为基础，支持Spring。

如何选择ESB

所有的ESB产品都应该可以构建和部署服务。包括对遗留系统的整理、消息的路由、消息格式的转换、执行协议的调解等。

首先我们要看ESB是否具有以下特性：

• 互通性
• 抽象化
• 资源位置的虚拟化
• 扩展能力和管理服务
• 是否具有平台无关性，即跨平台
• 松耦合

等。

上面列出的往往很评估，但是ESB本身具有的特性往往更容易识别和评估。

ESB所必须具备的功能：

• 路由
• 协议桥接
• 消息转换
• 服务代理托管

扩展的功能有：

• 资源适配器
• 可靠的消息传递
• 事件处理
• 交易的完整性管理
• 消息格式调解
• 负载均衡
• 消息验证
• 能力调解

等。

其实，对于如何选择本身就是一个跟业务相关的问题，以确定你是否选择ESB以及选择什么样的esb来满足你的应用需求。

1. 你选要集成三个或者更多的应用或服务吗？如果你需要在两个应用间通信，使用点对点集成更容易。
2.  未来你真的需要插入更多的应用吗？如果是需要的，那么你可以选择使用ESB。
3. 你是否需要使用不止一种类型的通信协议？如果是多种协议，那么可以选择使用ESB。
4. 你需要象分叉和聚集消息流或者基于内容的路由的消息路由功能吗？许多应用不需要这些扩展。
5. 你需要通过其他应用为消费发布服务吗？如果需要可以考虑选择ESB。
6. 你拥有多于10个的应用要集成吗？如果需要可以考虑选择ESB。
7. 你真的需要ESB的可扩展性吗？如果需要可以考虑选择ESB。

以上仅仅是列出了想到的一些问题，具体的情况还需要根据具体的需求进行分析和处理，如果简单的业务其实不必“大炮打蚊子”，毕竟合适才是最好的！