JMS开源比较

Java开源JMS消息中间件

mom4j  mom4j是一个完全实现JMS1.1规范的消息中间件并且向下兼容JMS1.0与1.02.它提供了自己的消息处理存储使它独立于关系数据与语言,所以它的客户端可以用任何语言开发.

OpenJMS OpenJMS是一个开源的Java Message Service API 1.0.2 规范的实现,它包含有以下特性: *. 它既支持点到点(point-to-point)(PTP)模型和发布/订阅(Pub/Sub)模型。 *. 支持同步与异步消息发送 *. JDBC持久性管理使用数据库表来存储消息 *. 可视化管理界面。 *. Applet支持。 *. 能够与Jakarta Tomcat这样的Servlet容器结合。 *. 支持RMI, TCP, HTTP 与SSL协议。 *. 客户端验证 *. 提供可靠消息传输、事务和消息过滤

UberMQ UberMQ完全实现了Java Message Service 规范。UberMQ是因为现有的许多JMS提供商已经违背了分布式计算的核心原则:快速与简单而开发的。

  Hermes JMS 利用它提供的Swing UI可以很好的实现监控JMS providers。

  ActiveMQ  ActiveMQ是一个开放源码基于Apache 2.0 licenced 发布并实现了JMS 1.1。它能够与Geronimo,轻量级容器和任Java应用程序无缝的给合。

  Somnifugi Somnifugi使得工作在同一个java虚拟机中的线程能实现消息互发。

  MantaRay  MantaRay基于peer-2-peer 技术。它具有以下特性: 1.它既支持点对点(point-to-point)的域,又支持发布/订阅(publish/subscribe)类型的域。 2.并且提供对下列类型的支持:经认可的消息传递,事务型消息的传递,一致性消息和具有持久性的订阅者支持。 3.消息过滤体制。 4.能与WebLogic and WebSphere 给合。 5.支持TCP, UDP 与 HTTP传输协。

  Presumo Presumo也是一个实现Java Message Service API的JMS消息中间件。

  JORAM JORAM一个类似于openJMS分布在ObjectWeb之下的JMS消息中间件。

 

  JMS4Spread JMS4Spread是一个消息系统.它部分地实现了Java消息服务(JMS) API. ------------------------------------------------------------------------------------------- 开源JMS简单比较 我考虑在公司的项目中采用JMS来降低服务器之间的耦合性,但为了降低成本,商业软件是不考虑的,于是只能在开源的并且对商业友好的JMS服务器中选择一个了。选择条件主要基于:

支持JMS 1.1规范 持久化,能满足商业应用所需的稳定性 满足项目的性能需求 最好本身提供JNDI服务 最好支持JMX 最好本身提供一个友好的管理工具 最好提供一份完整的文档准备进行选择的JMS服务器有:OpenJMS、UberMQ、ActiveMQ、MantaRay、JORAM

OpenJMS:老牌的JMS服务器了,也是我最早知道的开源JMS服务器,不过只支持JMS 1.02,已经很长时间没有更新了,因此不予考虑。

UberMQ:采用NIO的JMS服务器,以前我学习NIO的时候看过它的代码,写的蛮不错的,也支持JMS 1.1。由于采用了NIO,所以具有很高的弹性,在满足项目的性能需求上没有什么问题;本身也提供JNDI服务,但是遗憾的是我bind其他类型的数据时会出错;提供admin和viewer两个管理工具,但是在管理工具里不能创建ConnectionFactory和Destination并绑定到JNDI;文档不太完整;最头痛的对于持久化支持不好,如果关闭JMS服务器再开启,所有保存在JMS中的信息就全部丢失了,这点没有办法满足商业应用所需的稳定性。

ActiveMQ:最近比较活跃的一个JMS服务器,主页上的介绍说在协议配置上可以选择支持NIO,但是我仔细看它所支持的协议,却并没有提到如何配置,并且在实际的测试中也并没有发现其有采用NIO的迹象,多连接一个Client端,服务器端就增多了一个线程。满足JMS 1.1,有多种方法进行持久化;本身不提供JNDI,也没有对JMX的支持,本身不带管理工具,采用Hermes进行管理(这个我会在以后提到),文档也相对较少。

MantaRay:也是比较活跃的一个JMS服务器,采用的是P2P模型,但是我不喜欢这种模型,对于JMS服务来说,很大的一个特点就是客户端可以不用永远在线,比如在更新某一个客户端时需要暂停服务,等服务再度开启时,这段时间内所接收到的信息并不会丢失,保存在服务器上,所以我并不能看到P2P模型应用在JMS服务器上的优势,况且采用JMS服务就是为了解除耦合,速度并不是唯一需要考量的事情。出于我不喜欢其所采用模型,并且在运行其所带的示例时都出现了示例时都出现了问题,两个客户端互发互收,但是彼此之间都收不到消息,于是不予考虑。

JORAM:支持JMS 1.1,可以持久化到文件,本身提供JNDI服务和提供对JMX的支持,自带的管理工具可以添加ConnectionFactory和Destination并绑定到JNDI,这点对实现动态管理来说非常有用;文档非常完备,100多页的PDF,包含了各种配置和调整信息。其稳定性考虑的尤其好,不仅考虑到JMS服务器的集群,甚至连JNDI的集群也考虑进去(尽管暂时对我而言还用不上),这点对于商业应用而言应该会有加分。

ActiveMQ是Apache License,JORAM是LGPL,这两者对于商业应用都是友好的;UberMQ和MantaRay采用是Dual License,UberMQ的Dual License是只要你不分发,就可以允许使用;而MantaRay是商业使用需要应用一个商业的License。

比较上面的这些JMS服务器,最终我是选择了JORAM,其满足了我的绝大部分要求,唯一比较遗憾的是其采用传统的IO模型,每连接一个Client端会在服务器端增加两个线程,这点稍微影响了服务器的弹性。不过考虑到我们的项目应用,这点暂时可以不用考虑,实在压力过大了,最多到时候采用JMS集群呗:)

  开源JMS再比较                                       

四月份时我曾经比较了那时活跃度比较高的一些开源JMS——《开源JMS简单比较》,时隔四个月,重新回顾这些项目,发现与四个月以前的比较有一些出入,在这里再进行一些比较:)   比较的项目没有变化,OpenJMS、UberMQ、ActiveMQ、MantaRay、JORAM,这段时间内没有出现什么JMS新秀,JBoss计划在今年第四季度发布JBoss Messaging,但只要还是捆绑发行,我对其就没什么兴趣。   在上次的比较中,OpenJMS已经有比较长的一段时间没有更新了,但最近的四个月似乎又活跃了起来,其预备发行的0.7.7版计划支持JMS 1.1(这个来的太晚了些),其主页上的Changelog表明了接下来的这个版本有着较大的变化。这对那些以前将OpenJMS应用在项目中的人来说是一个不错的消息,但对正在选择JMS的人而言,OpenJMS的这些改进来的还是稍稍晚了些。   UberMQ这段时间没有更新,我对它的评价与以前一样,没有任何变化。   MantaRay在其主页上更新了一系列的Flash Demos,通过这些Demo,我更坚定了我的看法——MantaRay并不适合用于企业的JMS服务。   P2P这个词虽然热,但是不是什么地方都需要P2P的,在我看来JMS就是用于解除各个应用之间的耦合,速度是个关键指标,但比起这个关键指标更重要的是它存在的意义。我更倾向于采用MantaRay在Flash中所反对的那种模型,通过中心服务器进行转发,可以存放离线消息以及解除耦合。更何况,企业应用中很少有类似MantaRay演示DEMO中出现的那种网络拓扑图,并不是任何两个节点之间都是互联互通的。当然,如果MantaRay能够做一些改进,先尝试采用点对点模型,如果点对点失败,这时将消息发送到中心服务器上(但这一切必须对用户透明),我会比较赞成,既具有传统优势,又能提高消息发送接收速度。   至于上篇文章中提到的运行其自带的示例出现了问题,这次在Flash演示中终于找到了答案。看来MantaRay真应该提高其示例程序的易用性,这么复杂的操作,要是不看Flash演示,还真难想到该这样操作:(   ActiveMQ是让我感到惊讶的一个项目,上次对它的评价似乎有失偏颇。 ActiveMQ支持多种网络拓扑模型,既可以采用传统JMS的Client-Server模型,也可以采用MantaRay的P2P模型,还可以仅仅支持同一JVM内的JMS应用。持久化机制一如既往的优秀,默认采用Apache Derby数据库持久化,也可以配置为各种主流数据库来持久。目前也提供了一简单的JNDI实现,对于JMS应用而言,这已经够用了。   但是其缺点也同样明显,本身不提供管理工具;示例代码非常少;虽然主页上的文档看上去比较全面,但是一来缺乏一种有效的组织方式(文档凌乱,用户很难由浅入深进行了解,提高了门槛),二来文档整体的专业性太强(不了解ActiveMQ?看文档去吧,可是文档是写给了解ActiveMQ的用户看的……),对于普通用户而言,门槛有点高。   而且感觉ActiveMQ有点不安于JMS的本份,开始做一些周边应用了,看其主页就可以看出来,多了很多比较流行的词汇。说不上这是优点还是缺点,但就我的角度而言,我更希望其专注于做好它的JMS。    JORAM在这段期间推出了4.3.x的版本,也是我们在应用中所采用的版本,我的评价和上次相比没有什么大的变化。主页上说其速度有了提高,但我们应用中JMS数据量相对较少,没有感觉出来。稍微遗憾的是在我们试用的过程中,从4.2.3升级到4.3,老版本的持久化消息都无法在新版本上识别出来,只能全部清空。在兼容性上,看来JORAM还得多下功夫。总而言之,我们在应用中采用JORAM,感觉就是波澜不惊,没碰到什么大问题,也没有什么惊喜。   就目前情况,我觉得ActiveMQ和JORAM的竞争力相对较强。再次提醒,JMS的选择一定要慎重,一旦选择好,换起来可是要伤筋动骨的……

转载---------------------------------------

你可能感兴趣的:(jms)