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