企业服务总线，即ESB全称为Enterprise Service Bus，指的是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。
面向服务的体系结构已经逐渐成为IT集成的主流技术。面向服务的体系结构(service-oriented architecture，SOA)是一种软件系统设计方法，通过已经发布的和可发现的接口为终端用户应用程序或其它服务提供服务。
定义
面向服务的体系结构已经逐渐成为IT集成的主流技术。面向服务的体系结构(service-oriented architecture，SOA)是一种软件系统设计方法，通过已经发布的和可发现的接口为终端用户应用程序或其它服务提供服务。
SOA把IT架构分为组件层、Web服务层、业务流程层等。组件层包括各种应用组件，它们通常是技术相关的具体实现，各种具体的分布式组件技术(CORBA、COM/DCOM、J2EE)都可以用于实现组件层的应用组件。通常复杂的IT环境中的组件层都同时使用了多种分布式组件技术，而不同实现技术之间的互联性障碍给应用集成带来了极大的困难，进而形成了一个个信息孤岛。SOA引入了Web服务层来解决此种情况下的应用集成问题。Web服务是独立于各种分布式组件技术的，它使用标准的基于XML的服务描述语言(Web Service Description Language，WSDL)来定义和封装离散的业务功能，各种支持Web服务的分布式组件技术能够将其上的业务组件发布成Web服务并产生相应的WSDL文档，并且只需要依据WSDL描述的信息就能够调用Web服务，即WSDL所描述的业务功能。Web服务在系统集成方面得到了广泛的应用。在SOA中，需要进入系统集成环节的业务组件都被映射为Web服务，形成了Web服务层。业务流程层则处于Web服务层之上，通过对Web服务的流程编排来实现商业流程。业务流程层通过Web服务层能够调用到基于各种分布式组件技术实现的业务组件，实现了复杂IT系统环境的应用集成。
在SOA的组件层、Web服务层、业务流程层三层模型中，组件层使用具体的分布式组件技术实现业务功能，Web服务层则为组件层提供了一种技术无关的通用访问方式，屏蔽组件层具体技术之间的差异，突出业务逻辑的封装性。组件层中的业务组件和Web服务层的Web服务构成了企业IT架构的主要可重用部件，它们应该保持相对的稳定，业务流程层则通过对服务进行编排，来适应业务需求的变化。将组件层的业务组件映射为Web服务层的服务是成功实现SOA的关键步骤，目前对于特定的业务组件，业界广泛使用具体于分布式组件技术内建的支持Web服务的功能来实现组件与服务的映射。这种映射方法高度依赖于具体分布式组件技术本身，并且在使用和定制的过程中缺乏灵活性，当某个Web服务的实现需要多个分布式组件技术中的业务组件实现时，这种映射方法就会无法支持 [1]
总线
企业服务总线(EnterpriseServiceBus，ESB)是构建基于面向服务体系结构(SOA)解决方案时所使用基础架构的关键部分，是由中间件技术实现并支持SOA的一组基础架构功能。ESB支持异构环境中的服务、消息，以及基于事件的交互，并且具有适当的服务级别和可管理性。简而言之，ESB提供了连接企业内部及跨企业间新的和现有软件应用程序的功能，以一组丰富的功能启用管理和监控应用程序之间的交互。在SOA分层模型中，ESB用于组件层以及服务层之间，它能够通过多种通信协议连接并集成不同平台上的组件将其映射成服务层的服务。
作为SOA基础架构的关键部分，ESB的功能主要体现在通信、服务交互、应用集成、服务质量、安全性以及管理和监控等方面。在通信方面，ESB能够支持消息路由/寻址，支持多种通信技术、通信协议(如JMS、HTTP)，支持发布/订阅的通信模式，能够处理请求/响应、同步以及异步的消息传递方式，并且要求以可靠的方式传递消息。服务交互方面，ESB上所发布的服务是以当前标准的Web服务描述语言(WebServicesDescriptionLanguage)来定义Web服务的，并且ESB上通常配备有服务目录和发现机制。ESB的重要功能就是集成不同的系统，必须能够支持多种接入ESB的方式(例如将ESB、WebService、CORBA以及使用Socket等方式访问的遗留系统接入到ESB系统)，将接入的系统映射成Web服务。在集成不同系统的同时，必须考虑服务质量方面的问题，如事务性和消息传递的可靠性。对于关键的Web服务，ESB需要以加密的方式进行消息传递，并且必须验证访问者的权限。ESB软件作为SOA基础架构的一个复杂子系统，还必须配有相应的管理和监控功能，用于ESB软件自身的系统管理、日志记录、测量和监控等。目前国内外对企业服务总线的研究都比较积极，IBM的ISV、BEA的AquaLogicServiceBus、开源的Mule、Sun领导的JBI规范草案等，都是企业服务总线的具体实现。但是这些公司的ESB实现都更关注于对自有品牌产品的支持，对如何集成更多分布式组件技术考虑得不够。
功能
1、总线基础服务框架：提供系统一致性、安全性、可靠性，以及性能和扩展能力保障的基础技术手段。
2、集成服务：提供基础的集成服务与用户定制的应用服务；支持多种集成服务模式；支持服务的封装、重用、服务组合、服务调度。
3、公用服务：提供内置的各种公用服务。例如，渠道认证服务，日志服务等公用服务。
4、服务管理和服务标准：提供服务配置管理的前台工具集合，并提供行业的服务规约标准。
5、系统监控：提供多角度的系统实时监控与交易报表，提供用户定制的告警。
6、安全体系：提供多种安全机制并支持和第三方安全系统的有效集成，提供有效的安全监控机制。
优势
1、可用性和可靠性
支持群集物理部署来保证系统的高可用性，支持系统的长期稳定运行。
2、性能和可伸缩性
支持在达到系统性能指标峰值要求的同时，系统处理能力还能够留有足够的余量。
3、扩展性和灵活性
支持系统扩展部署和多个逻辑单元的分离部署。提供对系统的维护与参数配置的管理功能。
4、安全性
提供安全认证和授权机制，提供不可否认和机密性，支持安全标准。
从理论上讲，集中式 ESB 有可能标准化和大幅简化整个企业中服务的通信及集成。 硬件和软件成本可以共享，只需供应服务器一次，还可以指派单支专家团队（必要时进行培训）来开发和维护集成。
开发人员可使用单个协议与 ESB“对话”，并发出命令来指导服务间的交互，然后交给 ESB 转换这些命令、路由消息并根据需要变换数据以便顺利执行这些命令。 这样，开发人员就不需要将大量时间用于集成，而是将更多的时间用于配置和改进应用程序。 由于能够在不同项目之间复用这些集成，因此可以提高生产力并节省下游成本。
虽然有不少组织成功部署了 ESB，但在许多其他组织中，ESB 被视为 SOA 部署的瓶颈。 更改或增强某个集成通常会干扰到其他集成。 ESB 中间件更新通常会影响现有集成。 由于 ESB 是集中管理的，因此应用程序团队很快就发现需要排队等待集成。 随着集成量的增长，ESB 服务器实现高可用性和灾难恢复的成本变得更高。 作为跨企业项目，ESB 筹集资金较为困难，因而加大了相关技术难题的解决难度。
最终，维护、更新和扩展集中式 ESB 变得十分复杂且代价昂贵，以至于 ESB 经常会造成自身和 SOA 预期可得到的生产力效益迟迟无法实现，从而使期待锐意创新的业务团队感到挫败。
