开源企业服务总线ESB汇总与对比
Bitmap Bitmap Bitmap
|
|||||||||||||||||||||||||||||
| Mule ESB | Apache ServiceMix | Open ESB | Apache Synapse | JBoss ESB | WSO2 | OpenAdaptor | |||||||||||||||||||||||
| 产品描述与定位 | 轻量级的消息框架和整合平台；基于EIP实现；核心组件UMO实现整合逻辑；支持20多种传输协议（File、FTP、UDP、SMTP、POP、HTTP、SOAP、JMS等）。并整合了许多流行的开源项目，比如Spring,ActiveMQ,CXF,Axis,Drools等 | 它是JBI规范的一种实现；包含很熟JBI组件。这些组件支持多种协议，比如JMS,HTTP,FTP,FILE等。同时也实现了EIP，规则和调度。ApacheServiceMix 也整合了其他的开源项目，比如Apache、Apache、ActiveMQ CXF,Apahe Camel,Apache ODE以及Apache Geronimo。 | Open ESB可运行在由SUN支持的Glassfish应用服务中。同时SUN的Netbeans IDE为Open ESB提供了拖拉式的开发工具，这是其他开源ESB不可匹敌的，尽管Mule也提供了基于Eclipse的插件工具，但目前仍然不够强大。 | 虽然Apache Synapse具备一些ESB所必备的功能，但是从本质上而言Synapse更是一个web服务仲裁框架，它是构建在Apache Axis2之上的。Synapse的关注点是路由，转换，消息验证以及基于web服务和xml标准的注册。它支持HTTP, SOAP, SMTP, JMS,FTP ,MTOM/XOPPOP3/IMAP/SMTP 等传输协议，还支持多种web服务规范(WS-*)，比如WS-Addressing,WS-Security,WS-Policy以及WS- Reliable Messaging；支持多种语言；比如Java, JavaScript, Ruby, Groovy等。 | JBoss ESB是基于JBoss公司的ESB产品Rosetta的。Jboss ESB将JbossMQ作为其消息层，将JBoss rules为其提供路由功能， 将jBPM为其提供服务编排功能；JBoss ESB是JBoss社区为面向SOA而提出的一个EAI系统平台；它提供了很多EAI本身所应具有的功能，例如业务流程监控、集成开发环境、工作流用户接口、业务流程管理、分布式计算架构以及作为应用容器的功能等。 |
WSO2是基于Apache Synapse产品的，通过它可以在web服务，REST/POX服务以及遗留系统间连接，管理和转换服务交互。它还提供了一个基于AJAX的ESB管理控制台对其配置文件进行统计分析，管理（添加，删除以及修改等），和指定执行相应的配置文件。这在开源ESB中是非常少见的。 | OpenAdaptor定位于EAI （Enterprise Application Integration，企业应用集成）软件。它支持各种传输协议，如JMS, JDBC, IBM MQ Series, TIBCO Rendezvous, TCP/IP Sockets, SOAP, HTTP 和 File等 | ||||||||||||||||||||||
| 官方网站 | http://mule.codehaus.org/ |
http://servicemix.apache.org/ |
https://open-esb.dev.java.net/ | http://ws.apache.org/synapse | http://labs.jboss.com/jbossesb/ |
http://wso2.com/products/esb/ |
https://www.openadaptor.org/ |
||||||||||||||||||||||
| 缺陷与不足 | 没法热部署新的集成流程。 | 如果要做进一步的总线上的扩展，则需要对源代码和例子进行较为深入的学习和研究，当然这一切的基础是对JBI的规范有较为全面的了解。 |
如果要对OpenESB进行按照自身的要求进行扩展则较为困难，除非对OpenESB的源代码进行全面的分析。 |
相对于上面的总线而言，它的技术架构方案是最独立的。因为它除了支持J2EE标准外，对于JBI规范压根就不沾边；当然也就不存在JBI规范中的规范化消息路由、服务引擎和绑定组件了。 | |||||||||||||||||||||||||
| 对比 | Mule提供了以Java为中心的模型，支持jBPM，支持消息无关，没有热部署功能。 Mule的优点： 1，架构简单清晰、容易上手； 2，它有非常广泛的传输器、路由器和转换器，且易于扩展； 3，Mule不需将消息转换成统一的格式，而只在需要时进行转换，提高了性能； 4，开发过程中无需关注Mule代码，只需通过配置即可将服务暴露，减少了侵入性； 5，文档清晰而完善； Mule的缺点： 1，没有实现任何ESB规范（但遵循了《Enterprise Intergration Patterns》与 SEDA (Staged Event-Driven Architecture)）； 2，不支持热部署（企业版支持）； Mule选择不实现JBI的理由：为保持其轻量级和灵活性，提高效率和易用性。 Mule提供了一个JBI适配器来与JBI容器保持联通性。 |
ServiceMix提供了JBI支持，BPEL集成，关注XML消息和热部署功能。 Servicemix的优点： 1，基于JBI规范； 2，可以热部署； 3，支持Camel（可以用DSL去开发集成流程）； Servicemix的缺点： 1，JBI规范带来了使用上的繁琐，且JBI规范没有得到太多的青睐，前途未卜； 2，过多依赖XML的配置； 3，由于所有消息要进行标准化处理，即生成和解析XML文件，所以会导致性能下降； 4，开发过程中需要实现框架特定接口(MessageExchangeListener)接收和处理上述标准消息，侵入性强； 5，文档不健全、不够清晰； |
|||||||||||||||||||||||||||
| 结论 | 综上所述，Mule和Servicemix都实现了ESB的核心功能，都提供了广泛的可用组件和良好的扩展性，从功能上看差别不大，但从稳定性、易用性和性能上比较，Mule可能是更好的选择。 |
||||||||||||||||||||||||||||
