Java Message Service（JMS，Java訊息服務）是一組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採用一種寬鬆結合方式整合企業系統的方法，其主要的目的就是創建能夠使用跨平台數據信息的、可移植的企業級應用程式，而把開發人力解放出來。
Java訊息服務支持兩種訊息模型：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做什麼呢？任何事情都可以。
例如，分別用於銷售、庫存、客戶服務和賬目處理的系統。這些部門之間的系統很可能已經存在了很長時間，這些處理要求把事務移動到系統中去，這並不是一個小的工作。這就是訊息服務適用的地點。
當售貨員完成銷售的時候，一條訊息被發給庫存系統；一旦訂單訊息傳送給收發貨人員，就可以按照訂單出貨了。當訂單成功地發貨，系統將通知顧客服務和會計系統這個訂單已經成功的交易了。所有對應的每個子系統都自動地根據收到的訊息進行更新。
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 | 沒有訊息體，只有訊息頭和屬性。 |
下例演示接收訊息並轉換為合適的訊息類型：
Message m = queueReceiver.receive(); if (m instanceof TextMessage) { TextMessage message = (TextMessage) m; System.out.println("Reading message: " + message.getText()); } else { // Handle error }