深入淺出JMS——JMS簡介

原貼地址：http://blog.csdn.net/aking21alinjuju/archive/2010/12/02/6051421.aspx

 

如果手機只能進行即時通話，沒有留言和簡訊功能會怎麼樣？一個電話打過來，正好沒有來得及接上，那麼這個電話要傳遞的資訊肯定就收不到了。為什麼不
能先將資訊存下來，當使用者需要查看資訊的時候再去獲得資訊呢？伴隨著這個疑惑，短息和留言應運而生，無論手機是否開機、是否未及時接到，我們都能得到其中
的資訊。JMS提供了類似這樣的功能，本章我們將系統的學習JMS中的相關重要內容。

      Ø 掌握JMS基本概念及適用範圍

      Ø 點對點模型與發布/訂閱模型的區別和使用場合

      Ø 熟悉核心和通用的JMS API

      Ø 熟悉並理解JMS用戶端開發的步驟

      Ø 訊息的同步和非同步接收的實現方式

      Ø 串包問題的解決辦法

企業訊息系統

      Java Message Service是由Sun開發的，它為 Java程式提供一種訪問企業訊息系統的方法。在討論JMS之前，我們分來析一下企業訊息系統。
     

企業訊息系統，即面向訊息的中介軟體（MOM），提供了以鬆散耦合的靈活方式整合應用程式的一種機制。它們提供了基於儲存和轉寄的應用程式之間的非同步資料發
送，即應用程式彼此不直接通訊，而是與作為中介的MOM
通訊。MOM提供了有保證的訊息發送，應用程式開發人員無需瞭解遠端程序呼叫（PRC）和網路/通訊協定的細節。ActiveMQ正是MOM中優秀的一
員。

企業訊息系統的好處

我們先來看看，應用程式A將Message發送到伺服器上，然後應用程式B從伺服器中接收A發來的訊息，通過這個圖我們一起來分析一下JMS的好處

圖 1 JMS通訊

提供訊息靈活性

      應用程式A與應用程式B通過使用MOM的API（API）發送訊息進行通訊。MOM
將訊息路由給應用程式B，這樣訊息就可以存在於MOM中，MOM
負責處理網路通訊。如果網路連接不可用，MOM會儲存訊息，直到串連變得可用時，再將訊息轉寄給應用程式B。
      靈活性的另一方面體現在，當應用程式A發送其訊息時，應用程式B甚至可以不處於執行狀態。MOM將保留這個訊息，直到應用程式B開始執行並試著檢索訊息為止。這還防止了應用程式A因為等待應用程式B檢索訊息而出現阻塞。
      這種非同步通訊要求應用程式的設計與現在大多數應用程式不同，不過對於時間無關或平行處理，它可能是一個極其有用的方法。

鬆散耦合

      企業訊息系統的真正威力在於應用程式的鬆散耦合。在上面的圖中，由應用程式A發送訊息指定一個特定目標，如“訂單處理”。而現在，是由應用程式B提供訂單處理功能。
      但是在將來，我們可以用不同的訂單處理常式替換應用程式B，應用程式A將不再是明智之選。替換應用程式將繼續發送訊息完成“訂單處理”，而訊息也仍將得到處理。
      同樣，我們也可以替換應用程式A，只要替換應用程式繼續發送訊息進行“訂單處理”，訂單處理常式就無需知道是否有一個新的應用程式在發送訂單。

JMS是什麼

      JMS是一系列的介面及相關語義的集合，通過這些介面和和其中的方法，JMS用戶端如何去訪問訊息系統，完成建立、發送、接收和讀取企業訊息系統中訊息。
     

在JMS之前，每一家MOM廠商都用專有API為應用程式提供對其產品的訪問，通常可用於許多種語言，其中包括Java語言。JMS通過MOM為Java
程式提供了一個發送和接收訊息的標準的、便利的方法。用JMS編寫的程式可以在任何實現JMS標準的MOM上運行。
      JMS可移植性的關鍵在於：JMS API是由Sun作為一組介面而提供的。提供了JMS功能的產品是通過提供一個實現這些介面的提供者來做到這一點的。開發人員可以通過定義一組訊息和一組交換這些訊息的應用程式，建立JMS應用程式，實現非同步通訊。

JMS的目標

      JMS從提出以來，致力於完成如下幾個目標：
定義一組訊息公用概念和工具 + 生產力。
     
所有Java應用程式都可以使用JMS中定義的API去完成訊息的建立、接收與發送，任何實現了JMS標準的MOM都可以作為訊息的中介，完成訊息的儲存轉寄。
最大化訊息應用程式的可移植性。

     
MOM提供了有保證的訊息發送，應用程式開發人員無需瞭解遠端程序呼叫（PRC）和網路/通訊協定的細節，提供了程式的可移植性。
最大化降低應用程式與應用系統之間的耦合度。
     
由於MOM的存在，各個應用程式只關心和MOM之間如何進行訊息的接收與發送，而無需關注MOM的另一邊，其他程式是如何接收和發送的。

JMS兩種訊息模型

JMS提供了兩種訊息通訊模型：

      Ø 點到點（P2P）模型

      Ø 發布/訂閱（Pub/Sub）模型

圖 2 JMS通訊模型

可以看出，ClientA和ClientB是訊息生產者，通過兩種不同的目的地分別向ClientC、ClientD、ClientE和ClientF發送訊息。
     

在ClientA、C、D之間的訊息是點對點模型，使用這種模型，用戶端發送訊息到隊列目的地（Queue），從這個隊列裡面只有一個訊息接收者可以收到
那個訊息，其他訪問同一目的地的接收者不會接收到該訊息。如ClientC接收Queue中的Msg1訊息，ClientD接收Queue中的Msg2消
息。
      在ClientB、E、F之間的訊息是發布／訂閱模型。使用這種廣播模型，一個用戶端發送訊息給主題目的地（Topic），任何數量的消費訂閱者可以從這個主題目的地來接收它們。如：ClientE和ClientF都接收這個Msg3這條訊息。

點到點模型

點對點傳遞模型：生產者發送訊息到一個特定的隊列（Queue）中，而消費者從一個訊息佇列中得到訊息，如所示：

圖 3 點到點通訊模型

點對點模型的特點：

Ø  每條訊息有一個消費者

      每條只有一個消費者，如果一條訊息被訊息者接收，那麼其他的消費者就不能得到這條訊息了。

Ø 發送和接受訊息與時間沒有關係

      也就是說，生產者在發送訊息後，消費者可以在任意的時刻接收，但有兩個前提：

            1、訊息未到期

            2、訊息沒有被其他的使用者接收

      消費者也可以先運行，當生產者一運行，將訊息發送到隊列中，消費者即可從隊列中獲得訊息，這叫“守株待兔“。

Ø  消費者必須確認對訊息的接收

      收到訊息後消費者必須確認訊息已被接收，否則JMS服務提供者會認為該訊息沒有被接收，那麼這條訊息仍然可以被其他人接收。程式可以自動進行確認，不需要人工幹預。

Ø  非持久的訊息最多隻發送一次

      非持久的訊息最多隻發送一次，表示訊息有可能未被發送，造成未被發送的原因可能有：

            1、 JMS服務提供者出現宕機等情況，造成非持久資訊的丟失

            2、 隊列中的訊息到期，未被接收

Ø  持久的訊息嚴格發送一次

      我們可以將比較重要的訊息設定為持久化的訊息，持久化後的訊息不會因為JMS服務提供者的故障或者其他原因造成訊息丟失。

發布/訂閱模型

     
發布/訂閱模型：發布/訂閱傳遞訊息類型與主題（Topic）有關。生產者發布訊息，而消費者訂閱感興趣的訊息，生產者將訊息和一個特定的主題
（Topic）連在一起，訊息傳遞系統（MOM）根據消費者註冊的興趣，將訊息傳遞給消費者。這種類型非常類似出版報紙、雜誌的形式，如所示：

圖 4 發布/訂閱通訊模型

發布
/
訂閱模型的特點：

Ø  每個訊息都可以有多個（0，1，……）訂閱者

      每條訊息可以有多個消費者，如果報紙和雜誌一樣，誰訂閱了誰都可以獲得。

Ø  訂閱者只能消費他們訂閱之後出版的訊息

      這就要求訂閱者必須先訂閱，生產者再發布。即訂閱者必須先運行，再等待生產者的運行，這和點對點類型有所差異。

Ø  訂閱者必須保持為活動狀態才能使用這些訊息

      即訂閱者必須保持活動狀態等待發行者發布的訊息，如果訂閱者在發行者發布訊息之後才運行，則不能獲得先前發行者發布的訊息。