开源企业服务总线ESB汇总与对比

Bitmap Bitmap Bitmap
开源ESB汇总表
  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可能是更好的选择。
                   

你可能感兴趣的:(apache,jboss,activemq,jms,SOAP,web服务)