我考慮在公司的項(xiàng)目中采用JMS來降低服務(wù)器之間的耦合性，但為了降低成本，商業(yè)軟件是不考慮的，于是只能在開源的并且對(duì)商業(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)很長(zhǎ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；文檔不太完整；最頭痛的對(duì)于持久化支持不好，如果關(guān)閉JMS服務(wù)器再開啟，所有保存在JMS中的信息就全部丟失了，這點(diǎn)沒有辦法滿足商業(yè)應(yīng)用所需的穩(wěn)定性。

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

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

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

ActiveMQ是Apache License，JORAM是LGPL，這兩者對(duì)于商業(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集群?jiǎn)h：）