在面向消息的中間件(MOM)這個領域，IBM MQSeries (又稱WebSphere MQ)一直是當仁不讓的超級大哥， 其它還有一些小兄弟，比如SwiftMQ、SonicMQ之類。但近年來隨着J2EE中的JMS規範的建立，完備地支持JMS的服務器如雨後春筍般地出現，比如BEA WebLogic Server的JMS Server就是其中一個佼佼者。
僅僅就JMS規範來說，MQSeries與WebLogic JMS沒有什麼不同之處。但JMS規範僅僅定義了消息服務器的一個開發接口，而且還忽略了許多細節，所以不同之處就在JMS規範之外的這些內容，很多也是非常重要的。總的來說，MQSeries的功能和性能方面明顯佔優，而WebLogic JMS的某些JMS配置更加簡單易行。
在本文中，我儘量試圖從客觀的角度分析兩種產品的差異，如有不妥之處，請讀者不吝賜教。
1. 產品體系架構不同造成的差異
WebLogic JMS是一個純Java實現的支持C-S架構的 實現JMS規範的服務器產品；而MQSeries是使用本地語言(比如在UNIX和Windows上的C語言)編寫的既支持C-S架構，又支持對等訪問的 實現完備MOM(包括JMS規範)的產品。 於是就產生出以下的不同點：
1.1 MQSeries支持真正的異步數據傳輸；而WebLogic JMS不支持。
異步發送數據到遠端的消息服務器，是MQSeries等完備的MOM的特色。JMS規範規定了 一個C-S架構，定義了JMS客戶機與JMS服務器的開發接口，並沒有定義JMS服務器與JMS服務器的規範，而客戶機方面沒有任何隊列，所以只能說是規範了消息的存取，而沒有規範消息數據的傳輸。因爲JMS客戶機並不擁有存放數據的隊列，所以所有發送的操作都要由應用程序來控制，JMS服務器本身並不代理傳輸，也不保證數據在遠程隊列間傳輸的可靠性。WebLogic JMS就是這樣的體系。
這種體系結構有時候是不能直接滿足應用的要求的。首先，爲了充分利用資源和提高效率，許多應用需要採用異步消息的機制。其次，許多需要快速返回的應用也必須使用異步傳輸。比如電話自動語音應答(IVR)的程序，某個操作需要把數據傳輸到遠程的服務器上，但是必須立即返回，接受客戶的下一個按鍵。
MQSeries通過通道與傳輸隊列和遠程隊列來完成這一任務。能充分利用網絡的帶寬，甚至支持斷網續傳，保證數據傳輸的可靠性。 當然，雖然應用程序不必作任何工作，但配置方面確實還要多學一些概念。
1.2 MQSeries支持多種語言的開發；而WebLogic JMS基本上只支持JAVA
MQSeries支持的語言包括C, C++, COBOL, JAVA, PL/1, REXX, RPG, Visual Basic (使用COM/ActiveX)等。老闆本的MQSeries支持JAVA是通過一個叫MA88的SupportPac來實現，雖然經過廣泛的使用和驗證，但給人的感覺是不太方便。 好在從5.3版起(目前最新的是6.0版)，JAVA支持已經內置在MQSeries中。
WebLogic JMS一般只支持JAVA開發。但BEA也在dev2dev.bea.com網站上提供了一套免費的C的支持， 稱作“JMS C API”。參見http://dev2dev.bea.com/utilitiestools/environment.html?highlight=utilitiestools。但這個工具與老的MA88也是不能相提並論的，因爲BEA並不真正支持它，因此也基本沒有什麼用戶。參見BEA網站上 關於“JMS C API”的警告：
|
1.3 純JAVA實現的利與弊
MQSeries是用本地語言實現的，因此帶來的好處是高性能和高併發的支持能力。MQSeries相對WebLogic JMS等產品的性能優勢是非常明顯的，所以MQSeries非常適於企業級的大數據量和高併發的數據傳輸業務。誰也無法想象一個企業級的數據應用會採用一個純Java實現的數據庫，因爲其性能無法滿足要求，對較大的數據傳輸應用也是一樣的，純Java實現的JMS服務器 例如WebLogic JMS無法滿足其性能的要求。
純JAVA實現的JMS服務器也有其好處，就是與其它的J2EE服務完美地集成在一起。所以WebLogic的JMS配置顯得更簡潔。WebSphere+MQSeries也配合得很好，但總是能感覺到是這兩個產品。WebLogic JMS的對象體系完全符合JMS的概念體系。而MQSeries要通過WebSphere Application Server或者一個叫JMSAdmin的工具，藉助於目錄服務來完成MQSeries概念體系到JMS概念體系的映射。應該是看到了這件事造成的麻煩，所以IBM在WebSphere v6也提供了一套純JAVA實現的、與MQSeries可以互操作的JMS服務器。另外一點是WebLogic不需要WebSphere以及MQSeries那樣的冗長的CLASSPATH等環境變量的設置，這點對開發人員有吸引力。
1.4 MQSeries的通信功能更加強大，WebLogic JMS也有自己的一些特色
JMS對通信功能的要求很少，所以對二者對通信支持能力還是有很大的差別的。總的來說，歷史更悠久的MQSeries佔優，但WebLogic JMS也有自己的特色。
- MQSeries支持支持真正的遠程異步數據傳輸，甚至支持消息的路由，可以“多級跳”；WebLogic JMS不支持。
- MQSeries支持消息的分組和分段傳輸，對於大消息傳輸和不穩定的網絡非常有意義。WebLogic JMS沒有這方面的功能。
- 二者都支持SSL、持久性、優先級、超時等功能。除了完備的SSL實現之外，MQSeries的安全體系 遭到了一些批評，使用通道的安全出口程序顯得很麻煩，而使用用戶名稱但無須口令保護的遠程數據通信，如何能令人滿意？但在這一點上WebLogic JMS也很難說就好一些，因爲WebLogic JMS僅僅支持C-S的操作，系統本身並不支持遠程的數據傳輸(需要應用實現)。
- WebLogic JMS支持IP多播會話，能顯著地提高 局域網內廣播通信的性能，但這種方式不保證數據接收的可靠性，只適於某些特定的應用。MQSeries本身不提供此功能，但在Event Broker和Message Broker等MQSeries的升級產品中提供IP多播的支持。
1.5 MQSeries的管理功能更加強大
JMS對管理功能的要求很少，在這方面MQSeries也有比較明顯的優勢。
- JMS對事務處理的支持包括的對XASession和XAConnection實現，這一點對MQSeries和WebLogic JMS是相同的。MQSeries本身還可以作爲事務管理器，協調兩階段提交。
- MQSeries和WebLogic JMS都支持Message Driven Bean作爲觸發新的應用的一種方式。WebLogic JMS還支持一種稱作Session Pool的類似的觸發機制。但這類觸發機制過於簡化，也就是每個消息都觸發一個新的線程的應用。MQSeries的觸發機制更豐富，不但包括這種被稱作Every的方式，還包括First和Depth等方式。另外MQSeries還可以觸發各種執行程序或者MQSeries的通道。
- MQSeries擁有一套完備的日誌系統，可以進行獨立的系統備份和恢復，因此適於高規格的數據/消息傳輸的應用。WebLogic JMS沒有這方面的支持。
2. 產品歷史的不同造成的差異
MQSeries是個歷史悠久的產品，而WebLogic JMS是個新兵，因此會有以下的差異：
2.1 MQSeries支持更多的系統平臺
支持30多種系統平臺。當然值得注意的是某些平臺的MQSeries是由合作伙伴實現的。
WebLogic JMS是個新產品，支持的平臺數與WebLogic Server一樣，只有常用的幾個。有人說所有支持JDK的平臺都能跑WebLogic JMS的客戶機，這是不正確的說法。因爲JMS是J2EE規範的一種，J2SE的SDK並不包括JMS的支持，更不要說支持WebLogic的J2EE了。
2.2 MQSeries支持更多的通信協議
MQSeries支持很多通信協議，但目前在實踐中常用的是TCP/IP協議和SNA協議。
WebLogic JMS僅支持TCP/IP協議。
有些人對MQSeries的單向通道的概念提出了異議，認爲增加了配置的複雜性，僅僅是SNA協議的需要，而不是TCP/IP協議的需要。我個人認爲這點也不無一些道理。但是在有防火牆的TCP/IP網絡上，不同的方向還是有差異的。
3. 羣集實現的差異
MQSeries與WebLogic JMS在支持羣集時，差異比較大，應該說各有各的特點。
- MQSeries的羣集建立在配置庫和羣集通道基礎之上，可以定義“共享隊列”；WebLogic JMS的羣集建立在WebLogic羣集基礎之上，可以定義“分佈式隊列”。
- MQSeries在寫共享隊列時，如果發現本地有，就只寫本地的隊列(這稱作本地優先)；如果本地沒有，就會輪流寫到所有定義了此共享隊列的隊列管理器。MQSeries在讀共享隊列時，只能從本地取。WebLogic JMS在讀寫分佈式隊列時，不受本地影響，總是進行輪流或權重選擇。聽起來似乎WebLogic JMS的羣集更靈活，其實也不盡然。當取得了JMS的對象QueueSender或QueueReceiver後，WebLogic實際上已經綁定了一個JMS服務器的實例。如果每次寫或讀一個消息，都重新生成QueueSender或QueueReceiver，雖然比較好地支持了負載均衡，但勢必造成很大的性能損失。而MQSeries在輪流寫共享隊列時，沒有這方面的問題。
- WebLogic JMS的分佈式隊列有一個叫做Forward Delay的有意思的屬性，定義了一個時間的長度。系統一旦發現超過這個時間長度，還沒有人讀這個隊列，就把它的消息轉送給羣集中有消費者的隊列。有了這個屬性，應用程序就可以只從一個JMS服務器的實例讀消息了。