开源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的选择一定要慎重，一旦选择好，换起来可是要伤筋动骨的……

转自Learning的blog