ESB(Enterprise Service Bus)企业服务总线介绍

ESB(Enterprise Service Bus)企业服务总线介绍

ESB全称为Enterprise Service Bus，即企业服务总线。
它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信与整合。从功能上看，ESB提供了事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口。

在探讨信息系统的SOA架构概念时，一个非常重要的概念是：企业服务总线（ESB）。可以说，企业服务总线也是SOA的核心构成部分。要真正实现应用架构完善的SOA结构，简化SOA构件间的关系，就一定要建设好信息系统的企业级服务总线。

基本功能
1)服务的MetaData管理：在总线范畴内对服务的注册命名及寻址进行管理。
2)传输服务：确保通过企业总线互连的业务流程间的消息的正确交付，还包括基于内容的路由功能。
3)中介：提供位置透明的路由和定位服务；提供多种消息传递形式；支持广泛使用的传输协议。
4)多服务集成方式： 如JCA，Web服务，Messaging ，Adapter等。
5)服务和事件管理支持： 调用服务的记录、测量和监控数据；提供事件检测、触发和分布功能；
扩展功能
1) 面向服务的元数据管理： 他必须了解被他中介的两端,即服务的请求以及请求者对服务的要求，以及服务的提供者和他所提供的服务的描述；
2) Mediation ：它必须具有某种机制能够完成中介的作用，如协议转换；
3) 通信：服务的发布/订阅、响应/请求、同步/异步消息、路由和寻址等；
4) 集成： 遗留系统适配器，服务编排和映射，协议转换，数据变换，企业应用集成中间件的连续等。
5) 服务交互： 服务接口定义，服务实现的置换，服务消息模型，服务目录和发现等。
6) 服务安全： 认证和授权、不可否认和机密性、安全标准的支持等；
7) 服务质量： 事务，服务的可交付性等；
8) 服务等级： 性能、可用性等。
ESB 中最常提到的两个功能是消息转换和消息路由。

ESB架构
ESB 是传统中间件技术与XML、Web服务等技术相互结合的产物，ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信与整合。从功能上看，ESB提供了事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口。

现有的开源ESB总线中，自从2003年第一个开源总线Mule出现后，如今已经是百花争鸣的景象了。如今我就对现有的各种开源ESB总线根据性能、可扩展性、资料文档完整程度以及整合难易程度等方面展开。
一．CXF
CXF的定位不是ESB总线，而是一个服务框架（Service Framework），主要还是为关于服务的应用提供API上的支持，或者上下文上的管理。

可是它的前身之中的一个的Celtix就是IONA公司捐献给开源界的ESB总线，所以总体上还是能提供ESB总线的功能（需依靠与其他的容器）。在CXF中的总线仅仅是起到一个共享资源的提供者的作用。这些贡献资源就相当于JBI规范中的绑定组件（BC）或服务引擎（SE）。即使如此CXF并没有提供了对JBI规范的完整实现。能够说它仅仅是一个相似的JBI容器。

CXF支持与除了HTTP之外的其他协议的通信绑定，比如REST、JSON和CORBA等，所以对于Ajax有较强的兼容性。这相对与其他的ESB总线而言能够说是一个较大的优势。

可是CXF的ESB总线是根据Spring框架来实现的，由Spring来管理Bus中的各个组件。而Spring对各个Bean或组件的管理是通过一个上下文的配置文件来实现的。这种方式相对与其它的ESB总线（比如根据JMX）的方式而言，则不支持动态的热部署。也就是说CXF不是一个JBI容器，它必须依附与其它的容器来执行。现有的资料来看，CXF眼下能够部署在JBoss和BEA Weblogic中，Tomcatserver因为不支持完整的J2EE规范，特别是基于JCA的EJB，所以对CXF支持的程度不理想。尽管资料中没有涉及到Geronimo，可是以Geronimo对J2EE规范的兼容程度来看，特别是EAR文档的支持，在Geronimo中部署CXF应该没有什么太大的障碍。

相同你能够在使用Spring的应用中嵌入CXF，而这仅仅须要在Spring的配置文件里填写对应的配置信息就可以。

关于CXF的文档较为丰富，这部分是因为它本身是整合了Xfire和Celtix这两个本身较为成熟的开源项目。另外它较大的依赖于Spring框架，所以假设对Spring较为熟悉的话，在使用上一般就没有太大的障碍了。

二．Open ESB

OpenESB是Sun公司提出来的开源ESB项目，所以对JBI规范的支持程度就不用多说了。而GlassFish ESB则是将OpenESB的核心执行环境与GlassFish应用server以及NetBean的集成开发环境整合在一起的有一个ESB项目，当然当中还包括了一些OpenESB中已有的组件（子集）。

在OpenESB中提供了可以支持WS-BPEL2.0的引擎。可是如今这个组件支持WSDL1.1，暂不支持WSDL2.0。并且这个引擎要依托与NetBean集成开发平台，起码仅仅能得到基于NetBean的对应开发包和组件包。可是这个组件对BPEL提供了强大的支持，当中包含支持端点状态的监控、支持多线程运行、业务流程的调试、系统错误的可靠性恢复中各个业务流程实例的数据库持久化以及负载均衡等。

在资料方面仅仅有一个演示视频，主要还是基于NetBean平台的使用介绍。其它发布的资料则则较少，特别是API方面差点儿没有。所以假设要对OpenESB进行依照自身的要求进行扩展则较为困难，除非对OpenESB的源码进行全面的分析。

三．ServiceMix

ServiceMix是Apache基金会下的一个ESB总线，同一时候也是一个独立的JBI容器（也就是说它支持完整的JBI规范）。说它是一个独立的JBI容器，是由于它拥有自己独立的执行环境，能像应用server一样启动，并支持动态的热部署等，这一点则差别于CXF。

ServiceMix的容器执行环境採用内核的架构，并以Geronimo关于J2EE方面的实现为基础（当然也就支持J2EE的各方面规范，比如安全性方面的JAAS等），所以在性能上还是较为出色的。在通信上，整合了ActiveMQ，也支持多种的通信协议，比如HTTP和JMS。同一时候在管理组件上採用了JMX的管理架构，从而可以对部署在总线上的各种组件进行动态的配置和管理，或通过Web的形式，或通过JMX远程訪问均可。ServiceMix内核可以整合到所处的操作系统中，从而作为OS的对外提供的服务。差别与其它总线的是，ServiceMix还提供了自己的脚本命令控制台，并通过一些简单命令来管理应用组件以及ServiceMix内核实例。

关于ServiceMix的资料也较为的完备，当中当然也包含一些简单的小样例。关于组件扩展方面和流程引擎整合方面的具体资料则不够具体。假设要做进一步的总线上的扩展，则须要对源码和样例进行较为深入的学习和研究，当然这一切的基础是对JBI的规范有较为全面的了解。

四．JBoss ESB

JBoss ESB是JBoss社区为面向SOA而提出的一个EAI系统平台。它提供了非常多EAI本身所应具有的功能，比如业务流程监控、集成开发环境、工作流用户接口、业务流程管理、分布式计算架构以及作为应用容器的功能等。能够说JBossESB在功能上是较为强大的。但相对于上面的总线而言，它的技术架构方案是最独立的。由于它除了支持J2EE标准外，对于JBI规范压根就不沾边。当然也就不存在JBI规范中的规范化消息路由、服务引擎和绑定组件了。JBossESB除了支持 Web Service外，还支持多种的远程调用协议，比如JMS。仅仅是相对于ServiceMix和CXF而言，假设要对JBossESB进行扩展，可能要花费较大的时间和精力。

JBossESB相对上述的开源项目而言，一个非常大的优势在于文档资料是最为丰富和完备的。所以在开发和扩展上减小了不小的阻力。它而且依托于成熟的JBoss社区，周围齐全的开源项目支持，为后期的平台扩展提供了丰富的选择空间。