Java中間件JMS(五)之JMS入門

  前面幾章講了ActiveMQ以及ActiveMQ與spring的整合,這是jms的ActiveMQ實現。但是jms到底是什麼呢。如果開始就講解這些理論比較強的東西，可能比較難理解，但是現在結合前面幾章的實例對比就比較容易上手了。

1、.JMS 的概念

    JMS(Java Message Service)，即 Java 消息服務，是一組 Java 應用程序接口，用以提供創建、發接、接收、讀取消息的服務。SUN 只提供接口，由不同的廠商根據該接口提供自己的實現。

2、.JMS 的目標

   更好地理解 JMS 有助於瞭解 JMS 規範的制定者設置的目標。現在，市場上有許多企業消息產品，生產這些產品的幾家公司也參與了 JMS 的開發。

   現有的這些系統的能力和功能各不相同。這些制定者知道如果 JMS 結合所有現有系統的所有功能，那麼它會變得過於複雜。同樣，他們相信，他們也不能讓 JMS 只侷限於所有系統共有的那些特性。

   制定者相信，讓 JMS 包括實現“高級的企業應用程序”所需要的所有功能是很重要的。

   JMS 規範中聲明， JMS 的目標是：

• 定義一組消息公用概念和實用工具。
  
• 最少化程序員使用消息時必須學習的概念。
  
• 最大化消息應用程序的可移植性。 
  
• 最小化實現一個提供者所需的工作量。
  
• 爲點對點和 pub/sub 域 提供客戶機接口。“域”是用於在前面討論的消息模型的 JMS 術語。（注意：提供者不需要實現兩個域。）

3、.JMS 中間件

  1).IBM MQ 系列產品提供的服務使得應用程序可以使用消息隊列進行交流，通過一系列基於 Java 的 API 提供了 MQseries 在 Java 中應用開發的方法。它支持點到點和發佈/訂閱兩種消息模式。

  2).WebLogic是BEA公司實現的基於工業標準的J2EE應用服務器，支持大多數企業級JavaAPI，它完全兼容 JMS 規範，支持點到點和發佈/訂閱消息模式，它支持消息的多點廣播、持久消息存儲的文件和數據庫、XML 消息，以及動態創建持久隊列和主題。

  3).JBoss 是 JBoss 公司開發的一個免費開源的應用服務器，它提供了 EJB 運行的環境，並能夠結合 EJB 進行 JMS 消息的收取，支持點到點模型和發佈/訂閱模型。

  4).ActiveMQ 是一個基於 Apache 2.0 Licenced 發佈的開放源代碼的 JMS 產品，它能夠提供點到點消息模式和發佈/訂閱消息模式，支持 JBoss、Geronimo 等開源應用服務器，支持 Spring 框架的消息驅動，新增了一個 P2P 傳輸層，可以用於創建可靠的 P2P JMS 網絡連接，擁有消息持久化、事務、集羣支持等 JMS 基礎設施服務。

  5).OpenJMS 是一個開源的 JMS 規範的實現，它支持點對點模型和發佈/訂閱模型，支持同步與異步消息發送、可視化管理界面，支持 Applet，能夠與 Jakarta Tomcat 這樣的 Servlet容器結合，支持 RMI、TCP、HTTP 與 SSL 協議。

4、.JMS特性

     在 JMS 之前，每一家 MOM 廠商都用專有 API 爲應用程序提供對其產品的訪問，通常可用於許多種語言，其中包括 Java 語言。JMS 通過 MOM 產品爲 Java 程序提供了一個發送和接收消息的標準的、便利的方法。用 JMS 編寫的程序可以在任何實現 JMS 標準的 MOM 上運行。JMS 是由 Sun Microsystems 開發的，它爲 Java 程序員提供一種訪問企業消息系統的方法，即 面向消息的中間件 （MOM）。MOM 通過中間媒介以間接方式在應用程序之間異步傳送數據，用這種方法提供一種以鬆散耦合的靈活方式集成應用程序的機制。

    要執行並測試這些程序，需要訪問 JMS 的供應商實現。大多數 Java 2 Enterprise Edition （J2EE）供應商都會提供 JMS 的一種實現(也就是上面說的JMS中間件)。要想獲得設置 JMS 運行時程序和執行程序的有關信息，請參閱供應商文檔。

    它爲 Java 程序提供一種訪問 企業消息系統 的方法。在討論 JMS 之前，我們分來析一下企業消息系統。

   企業消息系統，即 面向消息的中間件（MOM），提供了以鬆散耦合的靈活方式集成應用程序的一種機制。它們提供了基於 存儲和轉發 的應用程序之間的異步數據發送，即應用程序彼此不直接通信，而是與作爲中介的 MOM 通信。

MOM 提供了有保證的消息發送（至少是在儘可能地做到這一點），應用程序開發人員無需瞭解遠程過程調用（PRC）和網絡/通信協議的細節。

    1)消息靈活性

MOM 將消息路由給應用程序 B，這樣，消息就可以存在於完全不同的計算機上，MOM 負責處理網絡通信。如果網絡連接不可用， MOM 會存儲消息，直到連接變得可用時，再將消息轉發給應用程序 B。

靈活性的另一方面體現在，當應用程序 A 發送其消息時，應用程序 B 甚至可以不處於執行狀態。MOM 將保留這個消息，直到應用程序 B 開始執行並試着檢索消息爲止。這還防止了應用程序 A 因爲等待應用程序 B 檢索消息而出現阻塞。

這種異步通信要求應用程序的設計與現在大多數應用程序不同，不過，對於時間無關或並行處理，它可能是一個極其有用的方法。

    2)鬆散耦合

企業消息系統的真正威力在於應用程序的 鬆散耦合。在前一頁的圖表中，由應用程序 A 發送消息指定一個特定目標，如“訂單處理”。而現在，是由應用程序 B 提供訂單處理功能。

但是在將來，我們可以用不同的訂單處理程序替換應用程序 B，應用程序 A 將不再是明智之選。替換應用程序將繼續發送消息完成“訂單處理”，而消息也仍將得到處理。

同樣，我們也可以替換應用程序 A，只要替換應用程序繼續發送消息進行“訂單處理”，訂單處理程序就無需知道是否有一個新的應用程序在發送訂單。

5.JMS模式

最初，開發企業消息系統是爲了實現 點對點模型 （PTP），由一個應用程序生成的每個消息都由另一個應用程序接收。近年來，出現了一種新的模型，叫做 發佈與訂閱 （或者 pub/sub）。

Pub/sub 用稱爲 主題（topic） 的內容分層結構代替了 PTP 模型中的惟一目的地，發送應用程序 發佈 自己的消息，指出消息描述的是有關分層結構中的一個主題的信息。

希望接收這些消息的應用程序 訂閱了 這個主題。訂閱包含子主題的分層結構中的主題的訂閱者可以接收該主題和其子主題發表的所有消息。

多個應用程序可以就一個主題發佈和訂閱消息，而應用程序對其他人仍然是匿名的。MOM 起着 代理（broker） 的作用，將一個主題已發表的消息路由給該主題的所有訂閱者。

JMS 應用程序由以下元素組成：

• JMS 客戶機。 用 JMS API 發送和接收消息的 Java 程序。
  
• 非 JMS 客戶機。 認識到傳統程序通常整個 JMS 應用程序的一部分是非常重要的，在規劃時必須優先考慮它們的存在。
  
• 消息。就JMS 應用程序設計而言，通過JMS 和非 JMS 客戶機所交換的消息的格式和內容是完整的。
  
• JMS 提供者。 如前所述，JMS 定義了一組接口，供應者必須提供特定於其 MOM 產品的具體實現。
  
• 管理對象。 消息系統提供者的管理員創建的、獨立於提供者的專有技術的對象。

6、.JMS管理對象

MOM 產品的提供者在實現消息時使用的機制和技術有很大不同。爲了保持 JMS 客戶機的可移植性，實現了 JMS 接口的對象必須與提供者的專有技術隔離。

完成這項任務的機制是 管理對象。這些實現 JMS 接口的對象由提供者的消息系統的管理員創建，並被放置在 JNDI 名字空間中。

然後由 JMS 程序檢索這些對象，通過它們實現的 JMS 接口訪問這些對象。JMS 提供者必須提供允許創建受管理對象及它們在 JNDI 名字空間中的存放地的工具。

有兩種受管理對象：

• ConnectionFactory：用於創建到提供者的底層消息系統的連接。
  
• Destination：用 JMS 客戶機來指定正發送消息的目的地或正接收消息的來源。

儘管受管理對象本身就是特定於提供者實現的類的例子，但可以使用可移植機制（JNDI）檢索它們，並且可以通過可移植接口（JMS）訪問它們。JMS 程序只需要知道管理對象的 JNDI 名稱和 JMS 接口類型即可，無需瞭解特定於提供者的知識。

7、.JMS接口

JMS 定義了一組封裝各種消息概念的高級接口。而這些接口又因爲兩個消息域——PTP 和 pub/sub——進行了進一步地定義和定製。

高級接口包括：

• ConnectionFactory：一個創建 Connection 的受管理對象。
  
• Connection：連接到提供者的活動連接。
  
• Destination：一個封裝消息目的地的身份的受管理對象，如消息的來源地和發送地。
  
• Session：發送和接收消息的單線程環境。爲了簡化，並且因爲 Session 控制事務的緣故，通過多個線程進行併發訪問受到了限制。可以將多個 Session 用於多線程應用程序。
  
• MessageProducer：用於發送消息。
  
• MessageConsumer：用於接收消息。

下表列出了從每一個高級接口繼承的特定於域的接口。

高級接口	PTP 域	Pub/sub 域
ConnectionFactory	QueueConnectionFactory	TopicConnectionFactory
Connection	QueueConnection	TopicConnection
Destination	Queue	Topic
Session	QueueSession	TopicSession
MessageProducer	QueueSender	TopicPublisher
MessageConsumer	QueueReceiver，QueueBrowser	TopicSubscriber

在 JMS 以前的版本中，高級接口是特定於域的接口的父接口，並且只包含在兩個域中共有的那些功能。JMS 提供者沒有提供高級接口的實現。在 JMS 1.1 中，一些高級接口現在則被認爲是“公用接口”，並且它們包含兩個域的所有功能； JMS 提供者必須提供這些接口的實現。儘管公用接口仍然是特定於域的接口的父接口，但它們現在是 JMS 客戶機編程的首選方法，並且它們提供特定於域的接口只爲了後向兼容。

下面重新列出了前一小節中的表，展示了一些公用接口。

JMS 公用接口	PTP 域	Pub/sub 域
ConnectionFactory	QueueConnectionFactory	TopicConnectionFactory
Connection	QueueConnection	TopicConnection
Destination	Queue	Topic
Session	QueueSession	TopicSession
MessageProducer	QueueSender	TopicPublisher
MessageConsumer	QueueReceiver,QueueBrowser	TopicSubscriber

統一有公用接口的域會導致繼承這些方法的一些特定於域的類不再適合它的域。如果在客戶機代碼中出現這種情況，JMS 提供者需要使用 IllegalStateException。

8、jms開發

一個典型的 JMS 程序要經過以下步驟才能開始產生和使用消息：

1. 通過 JNDI 查詢 ConnectionFactory 。
   
2. 通過 JNDI 查詢一個或者多個 Destination。
   
3. 用 ConnectionFactory 創建一個 Connection。
   
4. 用 Connection 創建一個或者多個 Session。
   
5. 用 Session 和 Destination 創建所需要的 MessageProducer 和 MessageConsumer。
   
6. 啓動 Connection。

這時，消息就可以開始流動，應用程序可以根據需要接收、處理和發送消息。 在後面幾節中，我們將開發 JMS 程序，您將會看到這些步驟的細節。

9、jms消息

消息系統的核心當然是消息。JMS 爲不同類型的內容提供了幾種消息類型，但所有消息都是從 Message 接口派生出來的。

Message 分爲三個組成部分：

• header 是一組標準字段，客戶機和提供者都用它們來標識和路由消息。
  
• Properties 提供了一個給消息添加可選標題字段的實用工具。如果應用程序需要用標準標題字段沒有提供的方法對消息進行歸類或分類，那麼可以爲消息添加一個屬性來實現這種歸類和分類；提供了 set<Type>Property(...) 和 get<Type>Property(...) 方法來設置和獲得各種 Java 類型的屬性，其中包括 Object。JMS 定義了提供者可以選擇性提供的一組標準屬性。
  
• 消息的 body 包含將 發送到接收應用程序的內容。每一個消息接口都專用於它所支持的內容類型。

10、header屬性

下面列出了 Message 的每一個標題字段的名稱、它對應的 Java 類型和字段的描述：

• JMSMessageID——類型爲 string

  惟一標識提供者發送的每一條消息。這個字段是在發送過程中由提供者設置的，客戶機只能在消息發送後才能確定消息的 JMSMessageID。

• JMSDestination——類型爲 Destination

  消息發送的 Destination，在發送過程中由提供者設置。

• JMSDeliveryMode——類型爲 int

  包含值 DeliveryMode.PERSISTENT 或者 DeliveryMode.NON_PERSISTENT。持久性消息被傳輸並且只被傳輸一次，非持久性消息最多被傳輸一次。要知道“最多一次”包括根本不傳輸。非持久性消息在應用程序或者系統出故障時被提供者弄丟。因此要格外小心，確保持久性消息不受故障的影響。這比開銷通常被認爲是發送持久性消息方面的開銷，在決定消息的發送模式時，必須仔細考慮，在可靠性和性能之間進行權衡。

• JMSTimestamp——類型爲 long

  提供者發送消息的時間，由提供者在發送過程中設置。

• JMSExpiration——類型爲 long

  消息失效的時間。這個值是在發送過程中計算的，是發送方法的生存時間（time-to-live）值和當前時間值的和。提供者不應發送過期的消息。值 0 表明消息不會過期。

• JMSPriority——類型爲 int

  消息的優先級，由提供者在發送過程中設置。優先級 0 的優先級最低，優先級 9 的優先級最高。

• JMSCorrelationID——類型爲 string

  通常用來鏈接響應消息與請求消息，由發送消息的 JMS 程序設置。響應來自另一個 JMS 程序的消息的 JMS 程序將正響應消息的 JMSMessageID 拷貝到這個字段中，這樣，正作出響應的程序就可以與它所發出的特定請求的響應相 關聯。

• JMSReplyTo——類型爲 Destination

  請求程序用它來指出回覆消息應發送的地方，由發送消息的 JMS 程序設置。

• JMSType——類型爲 string

  JMS 程序用它來指出消息的類型。一些提供者維護着一個消息類型倉庫，並用該字段引用倉庫中的定義類型，在這裏，JMS 程序不應該使用這個字段。

• JMSRedelivered——類型爲 boolean

  指出消息被過早地發送給了 JMS 程序，程序不知道消息的接收者是誰；由提供者在接收過程中設置。

11、標準屬性

下面列表給出了 Message 的每一個標準屬性的名稱、它對應的 Java 類型和該屬性的說明。提供者對標準屬性的支持是可選的。JMS 爲這些屬性和將來 JMS 定義的屬性保留了 “JMSX” 屬性名。

• JMSXUserID——類型爲 string

  發送消息的用戶的身份。

• JMSXApplID——類型爲 string

  發送消息的應用程序的身份。

• JMSXDeliveryCount——類型爲 int

  已經嘗試發送消息的次數。

• JMSXGroupID——類型爲 string

  該消息所屬的消息組的身份。

• JMSXGroupSeq——類型爲 int

  該消息在消息組中的序號。

• JMSXProducerTXID——類型爲 string

  生成該消息的事務的身份。

• JMSXConsumerTXID——類型爲 string

  使用該消息的事務的身份。

• JMSXRcvTimestamp——類型爲 long

  JMS 將消息發送給客戶的時間。

• JMSXState——類型爲 int

  提供者用它來維護消息的消息倉庫，通常，它與 JMS 生產者和客戶關係不大。

• JMSX_<vendor_name>

  爲特定於提供者的屬性而保留。