我沒有確定的答案,因爲我專門研究WMQ。但是,我相信大部分答案都是「否」。 (更多內容請見一分鐘。)
關於WMQ IBM提供了可用的出口點來定製渠道,API調用和授權的行爲。退出文件非常詳細,並且在特定操作的範圍內執行狹窄功能 - 即接收消息,啓動連接等。這些都是用C語言編寫的,最近用Java編寫。在大多數情況下,這些都是未使用的,我所談論的客戶通常會提到複雜性。他們希望通過配置而不是通過低級代碼來進行定製。我懷疑其他MOM供應商會遇到與客戶類似的要求。
這與你的問題有什麼關係?我認爲,如果客戶不願意以有限的功能對代碼進行編碼,那麼他們會編寫一個功能全面且強大的客戶端來支持可靠的消息傳遞,一階段和兩階段提交,側面退出,診斷以及WMQ渠道提供的所有其他功能。
假設這項任務是由一個具有這種代碼級別的開源團隊進行的,誰會支持它? MOM供應商目前在使用其專有客戶端時提供端到端的支持。在使用社區支持的第三方客戶端時,如何解決故障單可能會得到解決的想法對許多客戶來說有點可怕。例如,IBM爲WMQ提供名爲SupportPacs的附件。儘管SupportPac完全支持並被視爲產品擴展,但部分SupportPac仍按原樣提供。即使由供應商供應,我的許多客戶也不會按原樣運行代碼。
最後,還有接口契約的概念。 WMQ支持一些有很多選項的動詞。基礎信道協議更復雜。當WMQ v7推出時,這些頻道具有相當多的新功能和優化。這在這個規模上是可能的,因爲內部部件不會暴露給客戶,所以IBM能夠做出巨大的改變,而不用擔心會對第三方客戶產生負面影響。公開所有這些都會在比API公開時更高的級別上創建依賴關係。因此,根據我的理論(我不打算在這裏爲MQ開發團隊發言),大MOM供應商在中擁有既得利益,而不是將其渠道協議公開給獨立開發人員。這裏的新皺紋是我上面提到的AMQP。它定義了有線協議,並允許每個供應商編碼符合標準的產品。雖然這爲您提供了描述開源解決方案的機會,但任何一種實現改進產品的能力都受限於它們不擁有協議。目前,雖然我不指望你會發現任何大型MOM供應商暴露他們的有線協議的第三方開發。這就是說,這只是一個猜測,如果我錯了,我肯定有人會跳進來提供反例。
那麼,由於JMS是一個Java API,所以JMS客戶端是由Java客戶端定義的。也許你應該在你的問題中用MOM取代「JMS經紀人」。 – 2010-09-21 12:22:57