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