现有一些开源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社区,周围齐全的开源项目支持,为后期的平台扩展提供了丰富的选择空间。

现有一些开源ESB总线的比較,布布扣,bubuko.com

时间: 2024-11-10 00:20:08

现有一些开源ESB总线的比較的相关文章

几种开源分词工具的比較

搜集了一些资料,与同学一起进行了简单的測试,总结例如以下. 分词工  具 特点 支持语言 原理 词典及扩展性 StandardAnalyzer 中文.英文(unicode) 中文:单字符切分 英文:依据空格切分 ChineseAnalyzer 中文,不支持中文和英文及数字混合的文本分词 按字分词,与StandardAnalyzer对中文的分词没有大的差别 CJKAnalyzer 中文,英文,不支持中文和英文及数字混合的文本分词 採用的双字切分,也就是对一段文字按每两个字来进行切分 IKAnaly

做移动端视频通话软件,大致看了下现有的开源软件(转)

转自:链接 要做一个移动端视频通话软件,大致看了下现有的开源软件 一) sipdroid1)架构sip协议栈使用JAVA实现,音频Codec使用skype的silk(Silk编解码是Skype向第三方开发人员和硬件制造商提供免版税认证(RF)的Silk宽带音频编码器)实现.NAT传输支持stun server.2)优缺点:NAT方面只支持STUN,无ICE框架,如需要完全实现P2P视频通话需要实现符合ICE标准的客户端,音频方面没看到AEC等技术,视频方面还不是太完善,目前只看到调用的是系统自带

开源消息总线ActiveMQ

一.消息中间件MOM(Message-Oriented Middleware) 消息中间件是解决异步分布式系统中通讯和排队问题的中间件技术.它利用高效可靠的消息传递机制进行平台无关的数据交流,并基于数据通信来进行分布式系统的集成.通过提供消息传递和消息排队模型,它可以在分布式环境下扩展进程间的通信. 二.ActiveMQ 1.概述 ActiveMQ 则是MOM的一个跨语言跨平台实现,它是Apache出品,最流行的.能力强劲的开源消息总线.它完整实现了JMS1.1和J2EE1.4中JMS服务(JS

Java开源电商项目比較

这里比較的都是国外的开源项目,备选项目有: Smilehouse Workspace.Pulse.Shopizer.ofbiz.bigfish.broadleaf 1.Smilehouse Workspace 是一个採用 Java 开发的电子商务应用程序.用来做产品.定案和客户信息管理.(从官网看,更像是一个管理系统) 2.Pulse没有使用spring,使用了hibernate,不清楚V端用了什么,使用的开源列表例如以下 http://pulse.torweg.org/site/Pulsar/

SOA服务总线设计

背景 基于总线的设计,借鉴了计算机内部硬件组成的设计思想(通过总线传输数据).在分布式系统中,不同子系统之间需要实现相互通信和远程调用,比较直接的方式就是“点对点”的通信方式,但是这样会暴露出一些很明显的问题:系统之间紧密耦合.配置和引用混乱.服务调用关系错综复杂.难以统一管理.异构系统之间存在不兼容等.而基于总线的设计,正是为了解决上述问题.总线则作为中枢系统,提供统一的服务入口,并实现了服务统一管理.服务路由.协议转换.数据格式转换等功能.这样能够将不同系统有效地连接起来,并大大降低了连接数

SOA实践之基于服务总线的设计

在上文中,主要介绍了SOA的概念,什么叫做“服务”,“服务”应该具备哪些特性.本篇中,我将介绍SOA的一种很常见的设计实践--基于服务总线的设计. 基于服务总线的设计 基于总线的设计,借鉴了计算机内部硬件组成的设计思想(通过总线传输数据).在分布式系统中,不同子系统之间需要实现相互通信和远程调用,比较直接的方式就是“点对点”的通信方式,但是这样会暴露出一些很明显的问题:系统之间紧密耦合.配置和引用混乱.服务调用关系错综复杂.难以统一管理.异构系统之间存在不兼容等.而基于总线的设计,正是为了解决上

几种ESB(企业服务总线)介绍

ESB(Enterprise Service Bus,即企业服务总线)是传统中间件技术与XML.Web服务等技术结合的产物.ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素. 企业服务总线ESB就是一种可以提供可靠的.有保证的消息技术的最新方法.ESB中间件产品利用的是Web服务标准和与公认的可靠消息MOM协议接口(例如 IBM的WebSphere MQ.Tibco的Rendezvous和Sonic Software的SoniCMQ).ESB产品的共有特性包括:连接异构的MOM.

Shuttle ESB(六)——在工程中的应用

假设你可能浏览在前面几篇文章ESB介绍,我相信,在这篇文章中,你会发现很多共鸣. 虽然.市面上开源的ESB确实很之多.像Java中的Mule ESB.Jboss ESB:.Net中的NServiceBus.而Shuttle ESB是一个新兴的开源框架,网络上资源也比較少.我们当初为什么会选用Shuttle ESB呢? 正所谓没有最好.仅仅有更合适.多次调研发现,Shuttle ESB有下面几大长处: 1.Shuttle ESB是基于EDA的: 2.Shuttle ESB的实现以公布订阅为核心:

架构设计:系统间通信(35)——被神化的ESB(下)

(接上文:<架构设计:系统间通信(34)--被神化的ESB(上)>) 2-4.ESB与版本控制 企业中的系统集成过程,存在很多非技术因素引起的变化.可能出现的情况是,某个一直能够正常使用的调用功能A,在某一天突然就不能使用了.技术团队和业务团队排查了许久才发现功能A中对某个业务系统的调用接口已经被私自更改(可能只是多传递了一个参数.或者减少了一个参数的传递).这种情况在现实中经常出现,可能是业务部门出于私利对外屏蔽了这个接口,也可能是技术人员在改动接口时,忘记了这个接口还有外部系统进行使用.