j**a jms为什么引入消息中间件

mom4j mom4j是一个完全实现jms1.1规范的消息中间件并且向下兼容jms1.0与1.02.它提供了自己的消息处理存储使它独立于关系数据与语言,所以它的客户端可以用任何语言开发.openjmsopenjms是一个开源的j**a ** service api 1.0.2 规范的实现,它包含有以下特性： *. 它既支持点到点（point-to-point）（ptp）模型和发布/订阅（pub/sub）模型。 *. 支持同步与异步消息发送 *. jdbc持久性管理使用数据库表来存储消息 *. 可视化管理界面。 *. applet支持。 *. 能够与jakarta tomcat这样的servlet容器结合。 *. 支持rmi, tcp, http 与ssl协议。 *. 客户端验证 *. 提供可靠消息传输、事务和消息过滤ubermqubermq完全实现了j**a ** service 规范。ubermq是因为现有的许多jms提供商已经违背了分布式计算的核心原则：快速与简单而开发的。hermes jms利用它提供的swing ui可以很好的实现监控jms providers。activemq activemq是一个开放源码基于apache 2.0 licenced 发布并实现了jms 1.1。它能够与geronimo，轻量级容器和任j**a应用程序无缝的给合。somnifug**omnifugi使得工作在同一个j**a虚拟机中的线程能实现消息互发。mantaray mantaray基于peer-2-peer 技术。它具有以下特性: 1.它既支持点对点(point-to-point)的域，又支持发布/订阅(publ**h/subscribe)类型的域。 2.并且提供对下列类型的支持：经认可的消息传递,事务型消息的传递，一致性消息和具有持久性的订阅者支持。 3.消息过滤体制。 4.能与weblogic and websphere 给合。 5.支持tcp, udp 与 http传输协。presumopresumo也是一个实现j**a ** service api的jms消息中间件。joramjoram一个类似于openjms分布在objectweb之下的jms消息中间件。jms4spreadjms4spread是一个消息系统.它部分地实现了j**a消息服务(jms) api.-------------------------------------------------------------------------------------------开源jms简单比较我考虑在公司的项目中采用jms来降低服务器之间的耦合性，但为了降低成本，商业软件是不考虑的，于是只能在开源的并且对商业友好的jms服务器中选择一个了。选择条件主要基于：支持jms 1.1规范 持久化，能满足商业应用所需的稳定性 满足项目的性能需求 最好本身提供jndi服务 最好支持jmx 最好本身提供一个友好的管理工具 最好提供一份完整的文档准备进行选择的jms服务器有：openjms、ubermq、activemq、mantaray、joramopenjms：老牌的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新秀，**oss计划在今年第四季度发布**oss 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，感觉就是波澜不惊，没碰到什么大问题，也没有什么惊喜。 20210311