转载

开源ESB对比分析

Mule ESB

Mule是一个基于Java的轻量级企业服务总线和集成平台。Mule通过Transports/Connectors与外围的异构系统连接，提供Routing（路由）、Transaction Management（事务管理）、Transformation（转换）、Message Broker（消息代理）、Transportation Management（传输管理）、Security（安全）等核心模块。Mule可以单独使用，也可以架设在常用的应用服务器上。

外围系统的服务请求通过Mule ESB的Transport接入，Mule通过Transformer进行数据的格式转换，然后经过Inbound Router进行消息过滤（内部通过配置filter实现）后交给Mule的Component进行业务逻辑处理，处理后的结果通过Outbound Router确定传递给哪个接收方，然后通过Transformer进行数据格式转换，通过Transport连接至接收方，传递信息。

基于J2EE1.4的企业消息总线(ESB)和消息代理(broker)；
可插入的连接性，支持20多种传输协议，比如：jms、jdbc、tcp、udp、multicast、http、servlet、smtp、pop3、file、xmpp等；
支持任何传输之上的异步，同步和请求响应事件处理机制；
支持Axis或者Glue的Web Service；
灵活的部署结构，包括Client/Server, P2P, ESB 和Enterprise Service Network；
与Spring 框架集成:可用作ESB 容器，也可以很容易的嵌入到Spring应用中；
使用基于SEDA处理模型的高度可伸缩的企业服务器；
强大的基于EIP模式的事件路由机制等。

主要优点

在开源ESB中，活跃程度最高，用户量大，不断推出新版本。
基于模式的配置以及热部署；Mule IDE3.0，将支持图元拖拽，简化开发。
扩展性：增加一个新协议非常简单，只需实现5个接口类。
管理性：推出Console（收费），管理、部署和监控应用。
文档：文档非常丰富，降低了使用门槛。

主要缺点

集群非常弱，只能配置一个主实例和一个从实例，不支持flow和基于模式的配置
目前的IDE只提供XML级别的编辑，还不能实现图元的拖拽
稳定性：开源项目的通病，需要在测试场景下进行验证

Apache ServiceMix

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

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

主要优点：

JBI的优势:组件BC，SE可以在任何JBI容器（比限于ServiceMix）中直接运行，复用性强
基于OSGi:具备OSGi的优势：模块化，热部署，易扩展
基于Karaf:提供了非常丰富的命令，管理、部署和监控ServiceMix

主要缺点：

JBI规范太复杂,已被主流中间件厂商抛弃,没有受到业界的青睐
架构复杂,由于JBI的复杂性所致，其架构并非轻量级
缺少IDE的支持,必须手写大量的XML配置文件
学习门槛高，用户文档和相关资料比较少

Apache Synapse/WSO2

由Axis构成底层支持的Web Service总线，WSO2基于Synapse。

主要优点：

借助于Axiss的特性，能非常好的支持WS及WS-*。因此非常适合Web Service的场景
支持集群，集群中节点间的通信框架基于Apache Tribes（组通信框架）
支持一个主节点和多个从节点，支持Failover Routing
在集群环境中，所有的请求只能被主节点接收，从节点只能作为备份节点。
支持流量控制，在单个ESB实例或者集群中，可以在服务级别配置流量控制。
持数据缓存,集群中的各个ESB实例共享缓存的数据。

主要缺点：

架构不够清晰,显得有点臃肿、不简洁、不够优雅
扩展性差,新增一个协议/transport非常困难
组件比较凌乱,对多种协议（HTTP,WebService，JMS,FTP,EMAIL）的支持，部分依赖于Axis2,部分依赖于synapse

JBOSS ESB

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

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

Ultra ESB

UltraESB 是一个开源的企业服务总线 ESB 项目，特点是高性能和易用。提供一个强大而具备良好伸缩性的架构，在性能方面表现优异，根据性能测试数据可以看到，其性能优于常见Mule和WSO2，对于TPS数据可以达到3000TPS以上。而且轻量级，易于使用和管理。

支持传输层：

HTTP/S

JMS

Email (POP3/IMAP/SMTP)

AMQP

File/SFTP/FTP/FTPS/Samba

Timer (Scheduled Job)

TCP/S

MLLP/S

支持协议：

REST

SOAP

Hessian

FastInfoset

AS2

Protocol Buffers

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

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

正文到此结束