JavaMessage Service

 JavaMessage Service（Java Message Service，JMS）是一組Java應用程式介面(Java API)，它提供建立、發送、接收、讀取訊息的服務。由Sun公司和它的夥伴設計的JMS API定義了一組公用的應用程式介面和相應文法，使得Java程式能夠和其他訊息組件進行通訊。

      JMS是一種與廠商無關的 API，用來訪問訊息收發系統。它類似於 JDBC (Java Database Connectivity)：這裡，JDBC 是可以用來訪問許多不同關聯式資料庫的 API，而 JMS 則提供同樣與廠商無關的存取方法，以訪問訊息收發服務。許多廠商目前都支援 JMS，包括 IBM 的 MQSeries、BEA的 Weblogic JMS service和 Progress 的 SonicMQ，這隻是幾個例子。
JMS 使您能夠通過訊息收發服務（有時稱為訊息中介程式或路由器）從一個 JMS 客戶機向另一個 JML 客戶機發送訊息。訊息是 JMS 中的一種類型對象，由兩部分組成：前序和訊息主體。前序由路由資訊以及有關該訊息的中繼資料組成。訊息主體則攜帶著應用程式的資料或承載。根據承載的類型來劃分，可以將訊息分為幾種類型，它們分別攜帶：簡單文本 (TextMessage)、可序列化的對象 (ObjectMessage)、屬性集合 (MapMessage)、位元組流 (BytesMessage)、原始值流 (StreamMessage)，還有無承載的訊息 (Message)。

      訊息收發系統是非同步，也就是說，JMS 客戶機可以發送訊息而不必等待回應。比較可知，這完全不同於基於 RPC 的（基於遠程過程的）系統，如 EJB 1.1、CORBA 和 Java RMI 的引用實現。在 RPC 中，客戶機調用伺服器上某個分布式對象的一個方法。在方法調用返回之前，該客戶機被阻塞；該客戶機在可以執行下一條指令之前，必須等待方法調用結束。在 JMS 中，客戶機將訊息發送給一個虛擬通道（主題或隊列），而其它 JMS 客戶機則預訂或監聽這個虛擬通道。當 JMS 客戶機發送訊息時，它並不等待回應。它執行發送操作，然後繼續執行下一條指令。訊息可能最終轉寄到一個或許多個客戶機，這些客戶機都不需要作出回應。

　　JMS的通用介面集合以非同步方式發送或接收訊息。非同步方式接收訊息顯然是使用間斷網路連接的客戶機，諸如行動電話和PDA的最好的選擇。另外， JMS採用一種寬鬆結合方式整合企業系統的方法，其主要的目的就是建立能夠使用跨平台資料資訊的、可移植的企業級應用程式，而把開發人力解放出來。

　　JavaMessage Service支援兩種訊息模型：Point-to-Point訊息(P2P)和發布訂閱訊息（Publish Subscribe messaging，簡稱Pub/Sub）。JMS規範並不要求供應商同時支援這兩種訊息模型，但開發人員應該熟悉這兩種訊息模型的優勢與缺點。

　　P2P訊息模型是在點對點之間傳遞訊息時使用。如果應用程式開發人員希望每一條訊息都能夠被處理，那麼應該使用P2P訊息模型。與Pub/Sub訊息模型不同，P2P訊息總是能夠被傳送到指定的位置。

　　Pub/Sub模型在一到多的訊息廣播時使用。如果一定程度的訊息傳遞的不可靠性可以被接受的話，那麼應用程式開發人員也可以使用Pub/Sub訊息模型。換句話說，它適用於所有的訊息消費程式並不要求能夠收到所有的資訊或者訊息消費程式並不想接收到任何訊息的情況。

　　JMS通過允許建立持久訂閱來簡化時間相關性，即使訊息預訂者未啟用也可以接收到訊息。此外，使用持久訂閱還可通過隊列提供靈活性和可靠性，而仍然允許訊息被發給許多的接收者。 Topic Subscriber topic Subscriber = topicSession.createDurableSubscriber(topic, subscriptionName); 　　Connection對象表示了到兩種訊息模型中的任一種的訊息系統的串連。伺服器端和客戶機端對象要求管理建立的JMS串連的狀態。串連是由Connection Factory建立的並且通過JNDI查尋定位。 //取得用於 P2P的 QueueConnectionFactory QueueConnectionFactory = queueConnectionFactory( ); Context messaging = new InitialContext( ); QueueConnectionFactory = (QueueConnectionFactory) Messaging.lookup(“QueueConnectionFactory”); //取得用於 pub/sub的 TopicConnectionFactory TopicConnectonFactory topicConnectionFactory; Context messaging = new InitialContext(); topicConnectionFactory = (TopicConnectionFactory) messaging.lookup(“TopicConnectionFactory”); 　　注意：用於P2P的代碼和用於PublishSubscribe的代碼非常相似。

　　如果session被標記為transactional的話，確認訊息就通過確認和校正來自動地處理。如果session沒有標記為 transactional，你有三個用於訊息確認的選項。

　　· AUTO_ACKNOWLEDGE session將自動地確認收到一則訊息。

　　· CLIENT_ACKNOWLEDGE 用戶端程式將確認收到一則訊息，調用這則訊息的確認方法。 　　　· DUPS_OK_ACKNOWLEDGE 這個選項命令session“懶散的”確認訊息傳遞，可以想到，這將導致訊息提供者傳遞的一些複製訊息可能會出錯。這種確認的方式只應當用於訊息消費程式可以容忍潛在的副本訊息存在的情況。 queueSession = queueConnection.createQueueSession(false, session.AUTO_ACKNOWLEDGE);//P2P topicSession = topicConnection.createTopicSession(false, session.AUTO_ACKNOWLEDGE); //Pub-Sub

　　注意：在本例中，一個session目的從連結中建立，非值指出session是non-transactional的，並且 session將自動地確認收到一則訊息。

　　JMS現在有兩種傳遞訊息的方式。標記為NON_PERSISTENT的訊息最多投遞一次，而標記為PERSISTENT的訊息將使用暫存後再轉送的機理投遞。如果一個JMS服務離線，那麼持久性訊息不會丟失但是得等到這個服務恢複聯機時才會被傳遞。所以預設的訊息傳遞方式是非持久性的。即使使用非持久性訊息可能降低內務和需要的儲存空間，並且這種傳遞方式只有當你不需要接收所有的訊息時才使用。

　　雖然 JMS規範並不需要JMS供應商實現訊息的優先順序路線，但是它需要遞送加快的訊息優先於普通層級的訊息。JMS定義了從0到9的優先順序路線層級，0是最低的優先順序而9則是最高的。更特殊的是0到4是正常優先順序的變化幅度，而5到9是加快的優先順序的變化幅度。舉例來說： topicPublisher.publish (message, DeliveryMode.PERSISTENT, 8, 10000); //Pub-Sub 或 queueSender.send(message, DeliveryMode.PERSISTENT, 8, 10000);//P2P 　　這個代碼片斷，有兩種訊息模型，映射遞送方式是持久的，優先順序為加快型，生存周期是10000 (以毫秒度量 )。如果生存周期設定為零，這則訊息將永遠不會到期。當訊息需要時間限制否則將使其無效時，設定生存周期是有用的。

　　JMS定義了五種不同的訊息本文格式，以及調用的訊息類型，允許你發送並接收以一些不同形式的資料，提供現有訊息格式的一些層級的相容性。

　　· StreamMessage -- Java原始值的資料流

　　· MapMessage--一套名稱-值對

　　· TextMessage--一個字串對象

　　· ObjectMessage--一個序列化的 Java對象

　　· BytesMessage--一個未解釋位元組的資料流

　　JMS應用程式介面提供用於建立每種類型訊息和設定荷載的方法例如，為了在一個隊列建立並發送一個TextMessage執行個體，你可以使用下列語句： TextMessage message = queueSession.createTextMessage(); message.setText(textMsg); 　　以非同步方式接收訊息，需要建立一個訊息監聽器然後註冊一個或多個使用MessageConsumer的JMS MessageListener介面。會話(主題或隊列)負責產生某些訊息，這些訊息被傳送到使用onMessage方法的監聽者那裡。 import javax.jms.*; public class ExampleListener implements MessageListener { //把訊息強制轉化為TextMessage格式 public void onMessage(Message message) { TextMessage textMsg = null; // 開啟並處理這段訊息 } } 　　當我們建立QueueReceiver和TopicSubscriber時，我們傳遞訊息選取器字串： //P2P QueueReceiver QueueReceiver receiver; receiver = session.createReceiver(queue, selector); //Pub-Sub TopicSubscriber TopicSubscriber subscriber; subscriber = session.createSubscriber(topic, selector); 　　為了啟動訊息的交付，不論是Pub/Sub還是P2P，都需要調用start方法。 TopicConnection.start( ); //pub-sub QueueConnection.start( ); //P2P TopicConnection.start ( );// pub-sub QueueConnection.start ( );// P2P

　　當一條訊息被捕捉時，這條訊息做為一條必須被強制轉化為適當訊息類型的普通Message對象到達。這是一個被用來提取或開啟訊息內容的getter方法。下列程式碼片段使用StreamMessage類型。 private void unPackMessage (Message message) { String eName; String position; double rate; StreamMessage message; Message = session.createStreamMessage( ); //注意下面的代碼必須按照我給出的順序書寫 message.writeString(eName); message.writeString(position); message.writeDouble(rate); //實現處理訊息的必要的程式邏輯 }

　　停止訊息的傳遞，無論是Pub/Sub還是P2P，都調用stop方法。 TopicConnection.start( ); //pub-sub QueueConnection.start( ); //P2P TopicConnection.start ( );// pub-sub QueueConnection.start ( );// P2P 　　其他的J2EE組件--servlet或EJB--可以當作訊息生產者；然而，它們可能只能同步操作，這可能是因為它們的請求-應答的性質決定的。雖然XML目前還不是被支援的訊息類型，發送一個XML檔案和建立一條文本類型訊息以及把XML檔案添加到訊息的承載都一樣簡單，都是以非專有的方式傳送資料。值得注意的是，一些JMS供應廠商已經提供了可用的XML訊息類型。但是使用非標準的訊息類型可能會出現可移植性問題。 String reportData; //reportData內容為XML 文檔 TextMessage message; message = session.createTextMessage(); message.setText (reportData);

　　訊息驅動組件(MDB)是一個當訊息到達時被容器調用的非同步訊息消費程式。和entity和session EJB不同，MDB沒有本地和遠程介面並且是匿名的；它們對於客戶是不可見的。MDB是JMS系統的一部分，作為消費者實現伺服器上的商業邏輯程式。 一個客戶程式可能通過使用JNDI定位一個與MDB相關聯的JMS。 例如： Context initialContext = new InitialContext(); Queue reportInfoQueue = (javax.jms.Queue)initialContext.lookup (“java:comp/env/jms/reportInfoQueue”); 　　MDB是由Bean類和相應的XML部署描述符組成。 Bean 類實現MessageDriveBean 介面： import javax.ejb.*; import jms.Message.*; public interface MessageDriveBean { public void ejbCreate(); public void ejbRemove(); public void setMessageDrivenContext(MessageDrivenContext ctx); } 　　訊息監聽器介面： import javax.jms.*; public interface MessageListener { public void onMessage( ); }

　　部署描述符 ＜!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" "http://java.sun.com/j2ee/dtds/ejb-jar_2_0.dtd"＞ ＜ejb-jar＞ ＜enterprise-beans＞ ＜message-driven＞ ＜ejb-name＞MDB＜/ejb-name＞ ＜ejb-class＞MDB＜/ejb-class＞ ＜transaction-type＞Container＜/transaction-type＞ ＜message-driven-destination＞ ＜jms-destination-type＞javax.jms.Queue＜/jms-destination-type＞ ＜/message-driven-destination＞ ＜security-identity＞ ＜run-as-specified-identity＞ ＜role-name＞everyone＜/role-name＞ ＜/run-as-specified-identity＞ ＜/security-identity＞ ＜/message-driven＞ ＜/enterprise-beans＞ ＜/ejb-jar＞

 　　既然我們現在已經有了一些基本的JMS知識，那麼我們可以使用JMS做什麼呢？任何事情都可以。

 　　例如，分別用於銷售、庫存、客戶服務和賬目處理的系統。這些部門之間的系統很可能已經存在了很長時間，這些處理要求把事務移動到系統中去，這並不是一個小的工作。這就是Message Service適用的地點。

　　當售貨員完成銷售的時候，一條訊息被發給庫存系統；一旦訂單訊息發送給收發貨人員，就可以按照訂單出貨了。當訂單成功地發貨，系統將通知顧客服務和會計系統這個訂單已經成功的交易了。所有對應的每個子系統都自動地根據收到的訊息進行更新。

　　JMS一般都不是用來整合一個系統，而是整合許多可能參與訊息驅動環境的系統。JMS是一個用於開發和整合公司專屬應用程式程式的重要的工具。因為許多公司都有以前遺留下來的系統和新近開發的系統綜合起來的系統，訊息的使用是整合整個企業的重要的步驟。

　　

JMS介面描述

      JMS 支援兩種訊息類型PTP 和Pub/Sub，分別稱作：PTP Domain 和Pub/Sub Domain，這兩種介面都繼承統一的JMS Parent 介面，JMS 主要介面如下所示：

JMS Parent	PTPDomain	Pub/Sub Domain
ConnectionFactory	QueueConnectionFactory	TopicConnectionFactory
Connection	QueueConnection	TopicConnection
Destination	Queue	Topic
Session	QueueSession	TopicSession
MessageProducer	QueueSender	TopicPublisher
MessageConsumer	QueueReceiver,QueueBrowser	TopicSubscriber

      以下是對這些介面的簡單描述：
    ConnectionFactory ：串連工廠，JMS 用它建立串連
    Connection ：JMS 用戶端到JMS Provider 的串連
    Destination ：訊息的目的地
    Session： 一個發送或接收訊息的線程
    MessageProducer： 由Session 對象建立的用來發送訊息的對象
    MessageConsumer： 由Session 對象建立的用來接收訊息的對象

 

JMS訊息模型

JMS 訊息由以下幾部分組成：訊息頭，屬性，訊息體。

    訊息頭(Header) - 訊息頭包含訊息的識別資訊和路由資訊，訊息頭包含一些標準的屬性如：JMSDestination,JMSMessageID 等。

訊息頭	由誰設定
JMSDestination	send 或 publish 方法
JMSDeliveryMode	send 或 publish 方法
JMSExpiration	send 或 publish 方法
JMSPriority	send 或 publish 方法
JMSMessageID	send 或 publish 方法
JMSTimestamp	send 或 publish 方法
JMSCorrelationID	客戶
JMSReplyTo	客戶
JMSType	客戶
JMSRedelivered	JMS Provider

      屬性(Properties) - 除了訊息頭中定義好的標準屬性外，JMS 提供一種機制增加新屬性到訊息頭中，這種新屬性包含以下幾種：
    1. 應用需要用到的屬性;
    2. 訊息頭中原有的一些可選屬性;
    3. JMS Provider 需要用到的屬性。
    標準的JMS 訊息頭包含以下屬性：
   JMSDestination --訊息發送的目的地
   JMSDeliveryMode --傳遞模式， 有兩種模式： PERSISTENT 和NON_PERSISTENT，PERSISTENT 表示該訊息一定要被送到目的地，否則會導致應用錯誤。NON_PERSISTENT 表示偶然丟失該訊息是被允許的，這兩種模式使開發人員可以在訊息傳遞的可靠性和輸送量之間找到平衡點。
   JMSMessageID 唯一識別每個訊息的標識，由JMS Provider 產生。
   JMSTimestamp 一個訊息被提交給JMS Provider 到訊息被發出的時間。
   JMSCorrelationID 用來串連到另外一個訊息，典型的應用是在回複訊息中串連到原訊息。
   JMSReplyTo 提供本訊息回複訊息的目的地址。
   JMSRedelivered 如果一個用戶端收到一個設定了JMSRedelivered 屬性的訊息，則表示可能該用戶端曾經在早些時候收到過該訊息，但並沒有簽收(acknowledged)。
   JMSType 訊息類型的識別符。
   JMSExpiration 訊息到期時間，等於QueueSender 的send 方法中的timeToLive 值或TopicPublisher 的publish 方法中的timeToLive 值加上發送時刻的GMT 時間值。如果timeToLive值等於零，則JMSExpiration 被設為零，表示該訊息永不到期。如果發送後，在訊息到期時間之後訊息還沒有被發送到目的地，則該訊息被清除。
   JMSPriority 訊息優先順序，從0-9 十個層級，0-4 是普通訊息，5-9 是加急訊息。JMS 不要求JMS Provider 嚴格按照這十個優先順序發送訊息，但必須保證加急訊息要先於普通訊息到達。 

    訊息體(Body) - JMS API 定義了5種訊息體格式，也叫訊息類型，你可以使用不同形式發送接收資料並可以相容現有的訊息格式，下面描述這5種類型：

訊息類型	訊息體
TextMessage	java.lang.String對象，如xml檔案內容
MapMessage	名/值對的集合，名是String對象，實值型別可以是Java任何基本類型
BytesMessage	位元組流
StreamMessage	Java中的輸入輸出資料流
ObjectMessage	Java中的可序列化對象
Message	沒有訊息體，只有訊息頭和屬性。

下例示範建立並發送一個TextMessage到一個隊列：

 

TextMessage message = queueSession.createTextMessage();message.setText(msg_text); // msg_text is a StringqueueSender.send(message);

 

下例示範接收訊息並轉換為合適的訊息類型：

 

Message m = queueReceiver.receive();if (m instanceof TextMessage) {TextMessage message = (TextMessage) m;System.out.println("Reading message: " + message.getText());} else {// Handle error}