移植JMS應用程序，如果我們建立一個使用JMS API應用程序MQ

Question

今天（利用多邊開發銀行作爲消息監聽器，主機它可以說的GlassFish或Weblogic的10），明天讓說的流量都瘋了，我們才能端口這個應用程序無需更改代碼像WebSphere MQ的一些產品......堂妹理論上MQ更像是一個專用的JMS提供者...

Answer 1

是，也不是。 （回答所有的問題，最好的永遠是「看情況」。）

如果應用程序遵循JMS規範，那麼它應該運行在任何兼容JMS提供者不變。這是個好消息。

壞消息是，提供者如何實現JMS確實很重要。例如，JMS 1.1規範的6.5節說，這大約主題：

很多的Pub/Sub提供商組主題 成層次結構和訂閱的 層次結構零件提供各種 選項。 JMS對主題對象 所代表的內容沒有限制 。這可能是在 主題層次葉子，或者它可能是分層的 較大部分（ 訂閱一般類的 信息）。

主題的組織和 訂閱的粒度 是Pub/Sub 應用程序體系結構的重要組成部分。 JMS does 沒有指定應該如何完成這個 的策略。如果某個應用程序 利用了提供程序特定的 主題分組機制，則應該在 文檔中對此進行說明。如果應用程序是使用不同供應商安裝的 ，則 管理員的工作是 構建等效主題 體系結構並創建等效的 主題對象。

這是什麼意思是規範的某些部分可以用來解釋JMS傳輸提供者。應用程序所有者決定如何在移植應用程序時映射這些差異。

這個問題的另一個方面是，即使當規範由兩個傳送提供者嚴格遵守，則API背後的行爲可以不同。連接管理就是一個例子。某些提供程序通過透明方式將連接故障切換到客戶端，而其他提供程序則要求客戶端在發生故障後重新驅動連接順序。兩種方法都可以100％兼容JMS，但都需要不同的應用程序邏輯。

所以答案是，堅持JMS API使您非常接近完全可移植性，並且所需的移植量取決於傳輸提供程序如何解釋部分規範和/或實現的功能的差異規範中含糊不清。

Answer 2

的WebSphere MQ是一個非常成熟的，穩定的平臺，該平臺 - 據我所知 - 完全符合JMS標準。許多組織使用MQ上的JMS作爲其傳輸。我曾在幾個同時使用JMS和本機MQ機制的MQ機制中討論MQ層，並且我沒有遇到任何關於IBM JMS實現的抱怨。我沒有和任何改變了JMS提供者的人一起工作，但是......

IBM提供了一大堆只引用javax.jms包的Java庫，所以只要您沒有在代碼中進行任何特定於供應商的增強功能，就應該能夠插入MQ庫MQ成爲您的JMS提供者。 （您可能需要使用MQ工具進行一些管理來執行設置JMS訂閱等操作，但是...我沒有使用MQ的JMS方面，僅使用核心庫。）

檢出this IBM page有關MQ JMS庫的更多詳細信息。

如果您只使用WebSphere MQ作爲示例，那麼可以，您可能仍然需要檢查候選供應商是否符合規範，但JMS已經出現一段時間了，我認爲所有大型廠商的產品都是一個合適的JMS提供者。

Answer 3

由於JMS是一個相對簡單的API（與JDBC等相比），它提供了take some basic measures to begin with之間的實現之間保持相當便攜。

只要從WebSphereMQ獲得更好的性能，我不確定你會發現情況如此。如果您正在使用點對點，也許。但是如果你在做Pub/Sub，這是不太可能的。請參閱benchmark，這是由競爭對手公開承認的，但它使用第三方基準，實際上對於某些開源參賽者非常慷慨。

Answer 4

對於開發人員來說，在基於JMS的應用程序中使用供應商專有的功能很容易受到誘惑（或者有時需要）。在使用JMS的短時間內，我注意到開發人員可能會訴諸使用專有API的四個原因。

首先，從命名服務中獲取Destination和ConnectionFactory對象是不方便的，特別是對於一個新的JMS開發人員來說，他不希望在編寫應用程序之前花費時間學習JMS管理命令。使用供應商專有功能可以更方便地直接創建Destination和ConnectionFactory對象。其次，JMS產品通常提供超出JMS規範中定義的服務質量。如果這些服務質量與例如Session,Producer或Consumer有關，那麼供應商很自然地在這些類型上提供專有的操作set<Name>()。簡而言之，並非所有專有服務質量都可以封裝在管理對象中。

三，JMS相關操作失敗時，會拋出（子類型）JMSException。應用程序的開發人員可能希望以多種方式之一處理捕獲的異常，具體取決於異常的性質。但是，JMS規範指出，由JMSException提供的三條信息中的兩條是JMS供應商專有的。因此，開發人員在決定如何處理異常時可能需要依賴異常中包含的供應商專有信息。 （1）頭域，（2）任意屬性（即，名稱=值對），和（3）一個正文組成。 （2）的預期用途是在消費者應用程序中支持靈活的消息選擇。例如，在倫敦運行的生產者應用程序可能會在發送消息之前將location = London添加到消息的屬性中。消費者應用程序然後可以使用消息選擇器"(location = 'London')"來確保它僅接收具有該屬性值的消息。聽起來不錯。壞的一面是JMS規範保留了由供應商開始使用JMS_<vendor>的屬性名稱，一些供應商使用這些屬性來指定每個消息的專有服務質量。希望利用專有的，按消息的服務質量的開發人員必須修改生產者應用程序的代碼，以便在發送消息之前設置專有屬性。

T.Rob對主題層次結構的警告是另一個值得警惕的問題。