Java開源JMS消息中間件

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

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

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

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

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

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

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

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

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

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

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

開源JMS簡單比較

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

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

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

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

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

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

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

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

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

 
開源JMS再比較
                                      

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