Java帝國之JMS的誕生
1.背景
本文續上篇《Java 帝國之消息隊列》
自從張家村的ZhangMQ問世以來，大家都看到了消息隊列在分布式系統中的巨大好處，紛紛另起爐灶搞一套自己的消息隊列，各種MQ產品如雨后春筍班出現，各家都瘋狂的宣傳自己的寶貝。
為了吸引程序猿來使用， 各家八仙過海，各顯神通，定義了各式各樣的API, 由于是獨立發展，這些API協議多樣，互不兼容， 學習成本高，使用起來非常不方便。
這是帝國所不能容忍的 !
其實Java 帝國非常擅長搞出標準的協議和接口， 之前的JDBC就是一個典型的例子(參見文章《JDBC的誕生》)， 制定了協議以后， 讓各個產品廠商去實現, 實現了針對數據庫編程的統一接口。
既然數據庫可以這么干， 消息隊列肯定也沒問題!
由于張家村開發了***個消息隊列產品， 帝國把制定標準接口的光榮使命交給了張家村。
2.消息隊列接口設計
張家村經驗豐富的老村長又把任務分給了小張， 告訴他我們要做的是一個廠商獨立的標準接口， 讓他先去調研一下時下流行的MQ的現狀。
小張先找到了某大廠著名MQ, 它占據了企業級市場不少份額， 但是直接使用它的 Java API 編程的話就不那么容易了， 大家可以快速瀏覽下：
小張能看的出這是在發送一個消息，但這MQEnvironment， openOptions，MQPutMessageOptions 看起來讓小張心煩，特別是還得理解Queue Manager這樣的概念，有點不容易。
小張又找了一個以開源吸引人的RabbitMQ ， 這個看起來清爽多了：
但是這queueDeclare方法 和 basicPublish 方法小張總覺得的不爽。
只看了兩個消息隊列， 小張就不想再看了， 他去找村長說： 這差別也太大了，根本無法統一。
村長說：”不要被紛繁的現象迷住了雙眼， 要看透背后的本質， 做出適當的抽象才可以。“
又是抽象! 小張暗自嘆氣， 這抽象實在是太難了。
”你深入思考下“ 村長看出了小張的困難， 鼓勵他說： ”其實也沒那么難， 我們先搞出幾個最基本的概念, 記不記得操作系統中學過的生產者-消費者模型? 我們完全可以應用到這里來啊， 消息生產者(Message Producer)， 消息消費者 (Messge Consumer) ， 生產者提供發送消息的方法， 消費者提供接收消息的方法， 如果加上消息隊列 (Message Queue) 的話就是這樣：“
小張說：”這也太抽象了吧， 我看人家還有什么Queue Manager, Connection ,Channel 之類的“
村長說： ”別急啊， 你看不管是生產者向隊列發送消息，還是消費者去接收消息， 其實都是在和消息隊列進行交互， 所以我們再引入一個會話(Session)的概念出來 。“
”奧， 我有點明白了 ，Session 可以創建消息， 還可以引入事務的支持呢“ 小張思維敏捷
“不錯， 其實消息生產者/消費者也應該由Session來創建，因為他們要發送/接收消息肯定是在一個會話中， 另外你想想， Session對象由誰來創建?”
小張說： “應該是Connection ” 說著小張畫了一張圖：
“你看這概念不就出來了，是不是很簡單? ” 村長笑著說。
小張撓撓頭說： “會者不難，難者不會啊， 對了，我們還缺乏最關鍵的連接參數(ip地址，端口等)還有隊列的名稱之類的信息。 這些信息怎么辦?”
“這確實有點復雜，各個廠商的具體情況差別太大。” 村長也表示犯難 ，“你讓我想想， 下午再聊。”
3.配置和代碼的分離
小張中午吃飯的時候也在想， 這些復雜的配置參數該怎么辦， 要是都讓程序員在代碼里寫，那就太丑陋了吧， 因為不同的MQ產品，配置都不一樣啊。
下午的時候，看到村長一副喜氣洋洋的表情， 小張知道問題解決了。
村長說： “我想到了一個辦法， 一個很簡單，但是有效的辦法。”
小張說：“別賣關子了，快說吧”
”其實也是又老又俗的辦法了， 這個辦法就是把配置和代碼分開， 你不是說這些連接參數很復雜，各個廠商不同嗎? 那就作為配置信息把它放到Web容器里，對外只提供一個簡單的ConnectionFactory的接口，由這個ConnectionFactory來創建Connection， 當然了各個廠商必須實現這個ConnectionFactory“
"那怎么才能得到這個ConnectionFactory ?"
"這就簡單了， 對程序員來講，通過JNDI 就可以輕松拿到了， 例如："
”這辦法不錯，把細節都隱藏起來了， 既然ConnectionFactory可以這么搞， 隊列(Queue)的配置信息也可以這么辦啊。“
村長說：”所以ConnectionFactory, Queue 就是隔離細節的抽象層。”
4.再次抽象
標準接口初具模型，小張很高興，晚上請喜歡的張二妮吃飯， 忍不住得瑟了一下。
張二妮說：“你們兩個老土，定義的標準接口，都已經過時了!”
小張很生氣： “怎么可能呢?”
二妮說：“告訴你們吧， 你們搞的這個叫Point to Point模型，就是一個發送方，對應一個接收方， 現在外邊有很多人在用 發布/訂閱 的模型，你們知道不? ”
“一個客戶端(Client1)對一個Topic發布了消息， 很多訂閱了這個Topic的客戶端(Client2, Client3) 都可以接收到這個消息的副本。”
小張呆住了， 這和以前ZhangMQ的方式完全不同， 隊列都不見了， 引入了一個新的主題(Topic)的概念。
第二天， 小張趕緊去找村長， 告訴他發生了新情況。
村長說： “你呀，還是太年輕， 慌什么，深入思考一下， 這個發布/訂閱的本質和我們之前的生產者/消費者沒什么不同。 ”
小張說： “那人家還有Topic的概念呢。”
“我們可以把Topic和Queue 變成一個更抽象的概念，他們都是消息的目的地， 嗯， 就叫做Destination吧，這個Destination的細節也是需要配置出來的， 通過JNDI來獲取。”
“那訂閱怎么處理?”
村長說： “原來我們定義的是MessageConsumer, 現在增加一個新概念叫做 TopicSubscriber ， 可以從Destination獲取消息，這不就行了， 其實從本質上來講Subscriber也是消息消費者的一種而已。”
“那怎么才能實現訂閱的功能呢?”
“別忘了， 我們只定義接口行為， 具體的實現需要由各個產品來負責!”
小張看著這幅圖， 深感抽象的威力巨大， 這么多的細節***變成了這幾個簡單的概念!
小張還特意寫了一段代碼，展示上面的概念：
張家村把這個設計交了上去， 帝國很滿意，把它起名為Java Message Service (JMS)， 隨后強制各大產品實現JMS， 否則就不頒發進京證， 沒這個證別想在帝國做生意!
JMS由于設計良好，概念清晰，其實不用怎么強制，很快就流行開了，成為了Java 帝國的事實標準。
【本文為51CTO專欄作者“劉欣”的原創稿件，轉載請通過作者微信公眾號coderising獲取授權】
