Java開源JMS消息中間件

mom4j 
mom4j是一個(gè)完全實(shí)現(xiàn)JMS1.1規(guī)范的消息中間件并且向下兼容JMS1.0與1.02.它提供了自己的消息處理存儲(chǔ)使它獨(dú)立于關(guān)系數(shù)據(jù)與語言,所以它的客戶端可以用任何語言開發(fā).

OpenJMS
OpenJMS是一個(gè)開源的Java Message Service API 1.0.2 規(guī)范的實(shí)現(xiàn),它包含有以下特性：
*. 它既支持點(diǎn)到點(diǎn)（point-to-point）（PTP）模型和發(fā)布/訂閱（Pub/Sub）模型。
*. 支持同步與異步消息發(fā)送
*. JDBC持久性管理使用數(shù)據(jù)庫表來存儲(chǔ)消息
*. 可視化管理界面。
*. Applet支持。
*. 能夠與Jakarta Tomcat這樣的Servlet容器結(jié)合。
*. 支持RMI, TCP, HTTP 與SSL協(xié)議。
*. 客戶端驗(yàn)證
*. 提供可靠消息傳輸、事務(wù)和消息過濾

UberMQ
UberMQ完全實(shí)現(xiàn)了Java Message Service 規(guī)范。UberMQ是因?yàn)楝F(xiàn)有的許多JMS提供商已經(jīng)違背了分布式計(jì)算的核心原則：快速與簡單而開發(fā)的。

 
Hermes JMS
利用它提供的Swing UI可以很好的實(shí)現(xiàn)監(jiān)控JMS providers。

 
ActiveMQ 
ActiveMQ是一個(gè)開放源碼基于Apache 2.0 licenced 發(fā)布并實(shí)現(xiàn)了JMS 1.1。它能夠與Geronimo，輕量級容器和任Java應(yīng)用程序無縫的給合。

 
Somnifugi
Somnifugi使得工作在同一個(gè)java虛擬機(jī)中的線程能實(shí)現(xiàn)消息互發(fā)。

 
MantaRay 
MantaRay基于peer-2-peer 技術(shù)。它具有以下特性:
1.它既支持點(diǎn)對點(diǎn)(point-to-point)的域，又支持發(fā)布/訂閱(publish/subscribe)類型的域。
2.并且提供對下列類型的支持：經(jīng)認(rèn)可的消息傳遞,事務(wù)型消息的傳遞，一致性消息和具有持久性的訂閱者支持。
3.消息過濾體制。
4.能與WebLogic and WebSphere 給合。
5.支持TCP, UDP 與 HTTP傳輸協(xié)。

 
Presumo
Presumo也是一個(gè)實(shí)現(xiàn)Java Message Service API的JMS消息中間件。

 
JORAM
JORAM一個(gè)類似于openJMS分布在ObjectWeb之下的JMS消息中間件。

 
JMS4Spread
JMS4Spread是一個(gè)消息系統(tǒng).它部分地實(shí)現(xiàn)了Java消息服務(wù)(JMS) API.

-------------------------------------------------------------------------------------------

開源JMS簡單比較

我考慮在公司的項(xiàng)目中采用JMS來降低服務(wù)器之間的耦合性，但為了降低成本，商業(yè)軟件是不考慮的，于是只能在開源的并且對商業(yè)友好的JMS服務(wù)器中選擇一個(gè)了。選擇條件主要基于：

支持JMS 1.1規(guī)范
持久化，能滿足商業(yè)應(yīng)用所需的穩(wěn)定性
滿足項(xiàng)目的性能需求
最好本身提供JNDI服務(wù)
最好支持JMX
最好本身提供一個(gè)友好的管理工具
最好提供一份完整的文檔
準(zhǔn)備進(jìn)行選擇的JMS服務(wù)器有：OpenJMS、UberMQ、ActiveMQ、MantaRay、JORAM

OpenJMS：老牌的JMS服務(wù)器了，也是我最早知道的開源JMS服務(wù)器，不過只支持JMS 1.02，已經(jīng)很長時(shí)間沒有更新了，因此不予考慮。

UberMQ：采用NIO的JMS服務(wù)器，以前我學(xué)習(xí)NIO的時(shí)候看過它的代碼，寫的蠻不錯(cuò)的，也支持JMS 1.1。由于采用了NIO，所以具有很高的彈性，在滿足項(xiàng)目的性能需求上沒有什么問題；本身也提供JNDI服務(wù)，但是遺憾的是我bind其他類型的數(shù)據(jù)時(shí)會(huì)出錯(cuò)；提供admin和viewer兩個(gè)管理工具，但是在管理工具里不能創(chuàng)建ConnectionFactory和Destination并綁定到JNDI；文檔不太完整；最頭痛的對于持久化支持不好，如果關(guān)閉JMS服務(wù)器再開啟，所有保存在JMS中的信息就全部丟失了，這點(diǎn)沒有辦法滿足商業(yè)應(yīng)用所需的穩(wěn)定性。

ActiveMQ：最近比較活躍的一個(gè)JMS服務(wù)器，主頁上的介紹說在協(xié)議配置上可以選擇支持NIO，但是我仔細(xì)看它所支持的協(xié)議，卻并沒有提到如何配置，并且在實(shí)際的測試中也并沒有發(fā)現(xiàn)其有采用NIO的跡象，多連接一個(gè)Client端，服務(wù)器端就增多了一個(gè)線程。滿足JMS 1.1，有多種方法進(jìn)行持久化；本身不提供JNDI，也沒有對JMX的支持，本身不帶管理工具，采用Hermes進(jìn)行管理（這個(gè)我會(huì)在以后提到），文檔也相對較少。

MantaRay：也是比較活躍的一個(gè)JMS服務(wù)器，采用的是P2P模型，但是我不喜歡這種模型，對于JMS服務(wù)來說，很大的一個(gè)特點(diǎn)就是客戶端可以不用永遠(yuǎn)在線，比如在更新某一個(gè)客戶端時(shí)需要暫停服務(wù)，等服務(wù)再度開啟時(shí)，這段時(shí)間內(nèi)所接收到的信息并不會(huì)丟失，保存在服務(wù)器上，所以我并不能看到P2P模型應(yīng)用在JMS服務(wù)器上的優(yōu)勢，況且采用JMS服務(wù)就是為了解除耦合，速度并不是唯一需要考量的事情。出于我不喜歡其所采用模型，并且在運(yùn)行其所帶的示例時(shí)都出現(xiàn)了示例時(shí)都出現(xiàn)了問題，兩個(gè)客戶端互發(fā)互收，但是彼此之間都收不到消息，于是不予考慮。

JORAM：支持JMS 1.1，可以持久化到文件，本身提供JNDI服務(wù)和提供對JMX的支持，自帶的管理工具可以添加ConnectionFactory和Destination并綁定到JNDI，這點(diǎn)對實(shí)現(xiàn)動(dòng)態(tài)管理來說非常有用；文檔非常完備，100多頁的PDF，包含了各種配置和調(diào)整信息。其穩(wěn)定性考慮的尤其好，不僅考慮到JMS服務(wù)器的集群，甚至連JNDI的集群也考慮進(jìn)去（盡管暫時(shí)對我而言還用不上），這點(diǎn)對于商業(yè)應(yīng)用而言應(yīng)該會(huì)有加分。

ActiveMQ是Apache License，JORAM是LGPL，這兩者對于商業(yè)應(yīng)用都是友好的；UberMQ和MantaRay采用是Dual License，UberMQ的Dual License是只要你不分發(fā)，就可以允許使用；而MantaRay是商業(yè)使用需要應(yīng)用一個(gè)商業(yè)的License。

比較上面的這些JMS服務(wù)器，最終我是選擇了JORAM，其滿足了我的絕大部分要求，唯一比較遺憾的是其采用傳統(tǒng)的IO模型，每連接一個(gè)Client端會(huì)在服務(wù)器端增加兩個(gè)線程，這點(diǎn)稍微影響了服務(wù)器的彈性。不過考慮到我們的項(xiàng)目應(yīng)用，這點(diǎn)暫時(shí)可以不用考慮，實(shí)在壓力過大了，最多到時(shí)候采用JMS集群唄：）

 
開源JMS再比較
                                      

四月份時(shí)我曾經(jīng)比較了那時(shí)活躍度比較高的一些開源JMS——《開源JMS簡單比較》，時(shí)隔四個(gè)月，重新回顧這些項(xiàng)目，發(fā)現(xiàn)與四個(gè)月以前的比較有一些出入，在這里再進(jìn)行一些比較：）
 
比較的項(xiàng)目沒有變化，OpenJMS、UberMQ、ActiveMQ、MantaRay、JORAM，這段時(shí)間內(nèi)沒有出現(xiàn)什么JMS新秀，JBoss計(jì)劃在今年第四季度發(fā)布JBoss Messaging，但只要還是捆綁發(fā)行，我對其就沒什么興趣。
 
在上次的比較中，OpenJMS已經(jīng)有比較長的一段時(shí)間沒有更新了，但最近的四個(gè)月似乎又活躍了起來，其預(yù)備發(fā)行的0.7.7版計(jì)劃支持JMS 1.1（這個(gè)來的太晚了些），其主頁上的Changelog表明了接下來的這個(gè)版本有著較大的變化。這對那些以前將OpenJMS應(yīng)用在項(xiàng)目中的人來說是一個(gè)不錯(cuò)的消息，但對正在選擇JMS的人而言，OpenJMS的這些改進(jìn)來的還是稍稍晚了些。
 
UberMQ這段時(shí)間沒有更新，我對它的評價(jià)與以前一樣，沒有任何變化。
 
MantaRay在其主頁上更新了一系列的Flash Demos，通過這些Demo，我更堅(jiān)定了我的看法——MantaRay并不適合用于企業(yè)的JMS服務(wù)。
 
P2P這個(gè)詞雖然熱，但是不是什么地方都需要P2P的，在我看來JMS就是用于解除各個(gè)應(yīng)用之間的耦合，速度是個(gè)關(guān)鍵指標(biāo)，但比起這個(gè)關(guān)鍵指標(biāo)更重要的是它存在的意義。我更傾向于采用MantaRay在Flash中所反對的那種模型，通過中心服務(wù)器進(jìn)行轉(zhuǎn)發(fā)，可以存放離線消息以及解除耦合。更何況，企業(yè)應(yīng)用中很少有類似MantaRay演示DEMO中出現(xiàn)的那種網(wǎng)絡(luò)拓?fù)鋱D，并不是任何兩個(gè)節(jié)點(diǎn)之間都是互聯(lián)互通的。當(dāng)然，如果MantaRay能夠做一些改進(jìn)，先嘗試采用點(diǎn)對點(diǎn)模型，如果點(diǎn)對點(diǎn)失敗，這時(shí)將消息發(fā)送到中心服務(wù)器上（但這一切必須對用戶透明），我會(huì)比較贊成，既具有傳統(tǒng)優(yōu)勢，又能提高消息發(fā)送接收速度。
 
至于上篇文章中提到的運(yùn)行其自帶的示例出現(xiàn)了問題，這次在Flash演示中終于找到了答案?？磥鞰antaRay真應(yīng)該提高其示例程序的易用性，這么復(fù)雜的操作，要是不看Flash演示，還真難想到該這樣操作：（
 
ActiveMQ是讓我感到驚訝的一個(gè)項(xiàng)目，上次對它的評價(jià)似乎有失偏頗。 ActiveMQ支持多種網(wǎng)絡(luò)拓?fù)淠Ｐ?，既可以采用傳統(tǒng)JMS的Client-Server模型，也可以采用MantaRay的P2P模型，還可以僅僅支持同一JVM內(nèi)的JMS應(yīng)用。持久化機(jī)制一如既往的優(yōu)秀，默認(rèn)采用Apache Derby數(shù)據(jù)庫持久化，也可以配置為各種主流數(shù)據(jù)庫來持久。目前也提供了一簡單的JNDI實(shí)現(xiàn)，對于JMS應(yīng)用而言，這已經(jīng)夠用了。
 
但是其缺點(diǎn)也同樣明顯，本身不提供管理工具；示例代碼非常少；雖然主頁上的文檔看上去比較全面，但是一來缺乏一種有效的組織方式（文檔凌亂，用戶很難由淺入深進(jìn)行了解，提高了門檻），二來文檔整體的專業(yè)性太強(qiáng)（不了解ActiveMQ？看文檔去吧，可是文檔是寫給了解ActiveMQ的用戶看的……），對于普通用戶而言，門檻有點(diǎn)高。
 
而且感覺ActiveMQ有點(diǎn)不安于JMS的本份，開始做一些周邊應(yīng)用了，看其主頁就可以看出來，多了很多比較流行的詞匯。說不上這是優(yōu)點(diǎn)還是缺點(diǎn)，但就我的角度而言，我更希望其專注于做好它的JMS。
 
 JORAM在這段期間推出了4.3.x的版本，也是我們在應(yīng)用中所采用的版本，我的評價(jià)和上次相比沒有什么大的變化。主頁上說其速度有了提高，但我們應(yīng)用中JMS數(shù)據(jù)量相對較少，沒有感覺出來。稍微遺憾的是在我們試用的過程中，從4.2.3升級到4.3，老版本的持久化消息都無法在新版本上識(shí)別出來，只能全部清空。在兼容性上，看來JORAM還得多下功夫?？偠灾覀冊趹?yīng)用中采用JORAM，感覺就是波瀾不驚，沒碰到什么大問題，也沒有什么驚喜。
 
就目前情況，我覺得ActiveMQ和JORAM的競爭力相對較強(qiáng)。再次提醒，JMS的選擇一定要慎重，一旦選擇好，換起來可是要傷筋動(dòng)骨的……