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

• 支持JMS 1.1規(guī)范
• 持久化，能滿足商業(yè)應(yīng)用所需的穩(wěn)定性
• 滿足項目的性能需求
• 最好本身提供JNDI服務(wù)
• 最好支持JMX
• 最好本身提供一個友好的管理工具
• 最好提供一份完整的文檔

準(zhǔn)備進(jìn)行選擇的JMS服務(wù)器有：OpenJMS、UberMQ、ActiveMQ、MantaRay、JORAM

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

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

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

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

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

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

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