(from http://jmsmom.3322.net/mom_jms/jms.html)

當(dāng)前，CORBA、DCOM、RMI等RPC中間件技術(shù)已廣泛應(yīng)用于各個領(lǐng)域。但是面對規(guī)模和復(fù)雜度都越來越高的分布式系統(tǒng)，這些技術(shù)也顯示出其局限性： （1）同步通信：客戶發(fā)出調(diào)用后，必須等待服務(wù)對象完成處理并返回結(jié)果后才能繼續(xù)執(zhí)行；（2）客戶和服務(wù)對象的生命周期緊密耦合：客戶進程和服務(wù)對象進程 都必須正常運行；如果由于服務(wù)對象崩潰或者網(wǎng)絡(luò)故障導(dǎo)致客戶的請求不可達，客戶會接收到異常；（3）點對點通信：客戶的一次調(diào)用只發(fā)送給某個單獨的目標(biāo)對 象。
   面向消息的中間件（Message Oriented Middleware，MOM）較好的解決了以上問題。發(fā)送者將消息發(fā)送給消息服務(wù)器，消息服務(wù)器將消息存放在若干隊列中，在合適的時候再將消息轉(zhuǎn)發(fā)給接 收者。這種模式下，發(fā)送和接收是異步的，發(fā)送者無需等待；二者的生命周期未必相同：發(fā)送消息的時候接收者不一定運行，接收消息的時候發(fā)送者也不一定運行； 一對多通信：對于一個消息可以有多個接收者。
   已有的MOM系統(tǒng)包括IBM的MQSeries、Microsoft的MSMQ和BEA的MessageQ等。由于沒有一個通用的標(biāo)準(zhǔn)，這些系統(tǒng)很難實現(xiàn) 互操作和無縫連接。Java Message Service（JMS）是SUN提出的旨在統(tǒng)一各種MOM系統(tǒng)接口的規(guī)范，它包含點對點（Point to Point，PTP）和發(fā)布/訂閱（Publish/Subscribe，pub/sub）兩種消息模型，提供可靠消息傳輸、事務(wù)和消息過濾等機制。

1.JMS
   JAVA 消息服務(wù)(JMS)定義了Java 中訪問消息中間件的接口。JMS 只是接口，并沒有給予實現(xiàn)，實現(xiàn)JMS 接口的消息中間件稱為JMS Provider，iLink實現(xiàn)了JMS接口，用戶可以通過使用JMS接口，在iLink中進行JMS編程。 iLink支持JMS1.0.2版本。

2.JMS接口描述
   JMS 支持兩種消息類型PTP 和Pub/Sub，分別稱作：PTP Domain 和Pub/Sub Domain，這兩種接口都繼承統(tǒng)一的JMS父接口，JMS 主要接口如下所示：

MS父接口 PTP Pub/Sub ConnectionFactory QueueConnectionFactory TopicConnectionFactory Connection QueueConnection TopicConnection Destination Queue Topic Session QueueSession TopicSession MessageProducer QueueSender TopicPublisher MessageConsumer QueueReceiver,QueueBrowser TopicSubscriber

 

 

 

                    
   ConnectionFactory ：連接工廠，JMS 用它創(chuàng)建連接
   Connection ：JMS 客戶端到JMS Provider 的連接
   Destination ：消息的目的地
   Session： 一個發(fā)送或接收消息的線程
   MessageProducer： 由Session 對象創(chuàng)建的用來發(fā)送消息的對象
   MessageConsumer： 由Session 對象創(chuàng)建的用來接收消息的對象

3.JMS消息模型
JMS 消息由以下幾部分組成：消息頭，屬性，消息體。
  
3.1 消息頭(Header) - 消息頭包含消息的識別信息和路由信息，消息頭包含一些標(biāo)準(zhǔn)的屬性如：JMSDestination,JMSMessageID 等。

消息頭  由誰設(shè)置 JMSDestination send 或 publish 方法 JMSDeliveryMode send 或 publish 方法 JMSExpiration send 或 publish 方法 JMSPriority send 或 publish 方法 JMSMessageID send 或 publish 方法 JMSTimestamp send 或 publish 方法 JMSCorrelationID 客戶 JMSReplyTo 客戶 JMSType 客戶 JMSRedelivered JMS Provider

 

 

      
 

 

 

      
3.2 屬性(Properties) - 除了消息頭中定義好的標(biāo)準(zhǔn)屬性外，JMS 提供一種機制增加新屬性到消息頭中，這種新屬性包含以下幾種：
   1. 應(yīng)用需要用到的屬性;
   2. 消息頭中原有的一些可選屬性;
   3. JMS Provider 需要用到的屬性。
   標(biāo)準(zhǔn)的JMS 消息頭包含以下屬性：

JMSDestination 消息發(fā)送的目的地 JMSDeliveryMode 傳遞模式， 有兩種模式： PERSISTENT 和NON_PERSISTENT，PERSISTENT 表示該消息一定要被送到目的地，否則會導(dǎo)致應(yīng)用錯誤。NON_PERSISTENT 表示偶然丟失該消息是被允許的，這兩種模式使開發(fā)者可以在消息傳遞的可靠性和吞吐量之間找到平衡點。 JMSMessageID 唯一識別每個消息的標(biāo)識，由JMS Provider 產(chǎn)生。 JMSTimestamp 一個消息被提交給JMS Provider 到消息被發(fā)出的時間。 JMSCorrelationID 用來連接到另外一個消息，典型的應(yīng)用是在回復(fù)消息中連接到原消息。 JMSReplyTo 提供本消息回復(fù)消息的目的地址 JMSRedelivered 如果一個客戶端收到一個設(shè)置了JMSRedelivered 屬性的消息，則表示可能該客戶端曾經(jīng)在早些時候收到過該消息，但并沒有簽收(acknowledged)。 JMSType 消息類型的識別符。 JMSExpiration 消 息過期時間，等于QueueSender 的send 方法中的timeToLive 值或TopicPublisher 的publish 方法中的timeToLive 值加上發(fā)送時刻的GMT 時間值。如果timeToLive值等于零，則JMSExpiration 被設(shè)為零，表示該消息永不過期。如果發(fā)送后，在消息過期時間之后消息還沒有被發(fā)送到目的地，則該消息被清除。 JMSPriority 消息優(yōu)先級，從0-9 十個級別，0-4 是普通消息，5-9 是加急消息。JMS 不要求JMS Provider 嚴(yán)格按照這十個優(yōu)先級發(fā)送消息，但必須保證加急消息要先于普通消息到達。

 

 

 

 

 

 

 

 

3.3 消息體(Body) - JMS API 定義了5種消息體格式，也叫消息類型，你可以使用不同形式發(fā)送接收數(shù)據(jù)并可以兼容現(xiàn)有的消息格式，下面描述這5種類型：

消息類型 消息體 TextMessage java.lang.String對象，如xml文件內(nèi)容 MapMessage 名/值對的集合，名是String對象，值類型可以是Java任何基本類型 BytesMessage 字節(jié)流 StreamMessage Java中的輸入輸出流 ObjectMessage Java中的可序列化對象 Message 沒有消息體，只有消息頭和屬性

下例演示創(chuàng)建并發(fā)送一個TextMessage到一個隊列：
TextMessage message = queueSession.createTextMessage();
message.setText(msg_text); // msg_text is a String
queueSender.send(message);

下例演示接收消息并轉(zhuǎn)換為合適的消息類型：
Message m = queueReceiver.receive();
if (m instanceof TextMessage) {
 TextMessage message = (TextMessage) m;
 System.out.println("Reading message: " + message.getText());
} else {
 // Handle error
}

4. 消息的同步異步接收
   消息的同步接收是指客戶端主動去接收消息，JMS 客戶端可以采用MessageConsumer 的receive方法去接收下一個消息。
   消息的異步接收是指當(dāng)消息到達時，主動通知客戶端。JMS 客戶端可以通過注冊一個實 現(xiàn)MessageListener 接口的對象到MessageConsumer，這樣，每當(dāng)消息到達時，JMS Provider 會調(diào)用MessageListener中的onMessage 方法。


5. PTP模型
PTP(Point-to-Point)模型是基于隊列的，發(fā)送方發(fā)消息到隊列，接收方從隊列接收消息，隊列的存在使得消息的異步傳輸成為可能。和郵件系統(tǒng)中的郵箱一樣，隊列可以包含各種消息，JMS Provider 提供工具管理隊列的創(chuàng)建、刪除。JMS PTP 模型定義了客戶端如何向隊列發(fā)送消息，從隊列接收消息，瀏覽隊列中的消息。
   下面描述JMS PTP 模型中的主要概念和對象：

名稱 描述 Queue 由JMS Provider 管理，隊列由隊列名識別，客戶端可以通過JNDI 接口用隊列名得到一個隊列對象。 TemporaryQueue 由QueueConnection 創(chuàng)建，而且只能由創(chuàng)建它的QueueConnection 使用。 QueueConnectionFactory 客戶端用QueueConnectionFactory 創(chuàng)建QueueConnection 對象。 QueueConnection 一個到JMS PTP provider 的連接，客戶端可以用QueueConnection 創(chuàng)建QueueSession 來發(fā)送和接收消息。 QueueSession 提供一些方法創(chuàng)建QueueReceiver 、QueueSender、QueueBrowser 和TemporaryQueue。如果在QueueSession 關(guān)閉時，有一些消息已經(jīng)被收到，但還沒有被簽收(acknowledged)，那么，當(dāng)接收者下次連接到相同的隊列時，這些消息還會被再次接收。 QueueReceiver 客戶端用QueueReceiver 接收隊列中的消息，如果用戶在QueueReceiver 中設(shè)定了消息選擇條件，那么不符合條件的消息會留在隊列中，不會被接收到。 QueueSender 客戶端用QueueSender 發(fā)送消息到隊列。 QueueBrowser 客戶端可以QueueBrowser 瀏覽隊列中的消息，但不會收走消息。 QueueRequestor JMS 提供QueueRequestor 類簡化消息的收發(fā)過程。QueueRequestor 的構(gòu)造函數(shù)有兩個參數(shù)：QueueSession 和queue，QueueRequestor 通過創(chuàng)建一個臨時隊列來完成最終的收發(fā)消息請求。 可靠性(Reliability) 隊列可以長久地保存消息直到接收者收到消息。接收者不需要因為擔(dān)心消息會丟失而時刻和隊列保持激活的連接狀態(tài)，充分體現(xiàn)了異步傳輸模式的優(yōu)勢。

        
      
  
 

 

 

 

 

 

 

 

6. PUB/SUB模型
JMS Pub/Sub 模型定義了如何向一個內(nèi)容節(jié)點發(fā)布和訂閱消息，這些節(jié)點被稱作主題(topic)。
   主題可以被認為是消息的傳輸中介，發(fā)布者(publisher)發(fā)布消息到主題，訂閱者(subscribe) 從主題訂閱消息。主題使得消息訂閱者和消息發(fā)布者保持互相獨立，不需要接觸即可保證消息的傳送。
   下面描述JMS Pub/Sub 模型中的主要概念和對象：

名稱 描述 訂閱(subscription) 消 息訂閱分為非持久訂閱(non-durable subscription)和持久訂閱(durable subscrip-tion)，非持久訂閱只有當(dāng)客戶端處于激活狀態(tài)，也就是和JMS Provider 保持連接狀態(tài)才能收到發(fā)送到某個主題的消息，而當(dāng)客戶端處于離線狀態(tài)，這個時間段發(fā)到主題的消息將會丟失，永遠不會收到。持久訂閱時，客戶端向JMS 注冊一個識別自己身份的ID，當(dāng)這個客戶端處于離線時，JMS Provider 會為這個ID 保存所有發(fā)送到主題的消息，當(dāng)客戶再次連接到JMS Provider時，會根據(jù)自己的ID 得到所有當(dāng)自己處于離線時發(fā)送到主題的消息。 Topic 主題由JMS Provider 管理，主題由主題名識別，客戶端可以通過JNDI 接口用主題名得到一個主題對象。JMS 沒有給出主題的組織和層次結(jié)構(gòu)的定義，由JMS Provider 自己定義。 TemporaryTopic 臨時主題由TopicConnection 創(chuàng)建，而且只能由創(chuàng)建它的TopicConnection 使用。臨時主題不能提供持久訂閱功能。 TopicConnectionFactory 客戶端用TopicConnectionFactory 創(chuàng)建TopicConnection 對象。 TopicConnection TopicConnection 是一個到JMS Pub/Sub provider 的連接，客戶端可以用TopicConnection創(chuàng)建TopicSession 來發(fā)布和訂閱消息。 TopicSession TopicSession 提供一些方法創(chuàng)建TopicPublisher、TopicSubscriber、TemporaryTopic 。它還提供unsubscribe 方法取消消息的持久訂閱。 TopicPublisher 客戶端用TopicPublisher 發(fā)布消息到主題。 TopicSubscriber 客戶端用TopicSubscriber 接收發(fā)布到主題上的消息。可以在TopicSubscriber 中設(shè)置消息過濾功能，這樣，不符合要求的消息不會被接收。 Durable TopicSubscriber 如果一個客戶端需要持久訂閱消息，可以使用Durable TopicSubscriber，TopSession 提供一個方法createDurableSubscriber創(chuàng)建Durable TopicSubscriber 對象。 恢復(fù)和重新派送(Recovery and Redelivery) 非持久訂閱狀態(tài)下，不能恢復(fù)或重新派送一個未簽收的消息。只有持久訂閱才能恢復(fù)或重新派送一個未簽收的消息。 TopicRequestor JMS 提供TopicRequestor 類簡化消息的收發(fā)過程。TopicRequestor 的構(gòu)造函數(shù)有兩個參數(shù)：TopicSession 和topic。TopicRequestor 通過創(chuàng)建一個臨時主題來完成最終的發(fā)布和接收消息請求。 可靠性(Reliability) 當(dāng)所有的消息必須被接收，則用持久訂閱模式。當(dāng)丟失消息能夠被容忍，則用非持久訂閱模式。

 

 

 

 

 

 

 

 
 

 

 
 
 
 
 
 
 
 
 
7. 開發(fā)JMS的步驟
   廣義上說，一個JMS 應(yīng)用是幾個JMS 客戶端交換消息，開發(fā)JMS 客戶端應(yīng)用由以下幾步構(gòu)成：
用JNDI 得到ConnectionFactory 對象；
用JNDI 得到目標(biāo)隊列或主題對象，即Destination 對象；
用ConnectionFactory 創(chuàng)建Connection 對象；
用Connection 對象創(chuàng)建一個或多個JMS Session；
用Session 和Destination 創(chuàng)建MessageProducer 和MessageConsumer；
通知Connection 開始傳遞消息。