JMS基本功能
JMS是用於和麵向訊息的中介軟體相互通訊的應用程式介面。它既支援點對點(point-to-point)的域，又支援釋出/訂閱(publish/subscribe)型別的域，並且提供對下列型別的支援：經認可的訊息傳遞,事務型訊息的傳遞，一致性訊息和具有永續性的訂閱者支援。JMS還提供了另一種方式來對您的應用與舊的後臺系統相整合。
WebLogic JMS Server介紹
WebLogic Server8.1符合JAVA規範,並通過Sun Microsystems J2EE 1.3認證.作為WebLogic的一部分,當然WebLogic JMS Server也完全遵從JMS規範,還支援叢集,並可以應用於實際企業系統.下圖是WebLogic JMS Server體系結構.圖中可以看到WebLogic JMS Server主要元件有: WebLogic JMS servers(用於訊息通訊),Java客戶端,JNDI(用於域名查詢), 後備儲存(用於持久訊息儲存,基於檔案或者JDBC資料庫).
JMS流程圖
WebLogic JMS特性 1. 訊息通訊模型
JMS 支援兩種訊息通訊模型：點到點（point-to-point）（PTP）模型和釋出/訂閱（Pub/Sub）模型。除了下列不同之外，這兩種訊息通訊模型非常地相似：
PTP 模型規定了一個訊息只能有一個接收者;Pub/Sub 模型允許一個訊息可以有多個接收者。
2. 訊息組成
訊息傳遞系統的中心就是訊息。
一條 Message 分為三個組成部分：
· 頭（header）是個標準欄位集，客戶機和供應商都用它來標識和路由訊息。
· 屬性（property）支援把可選頭欄位新增到訊息。如果您的應用程式需要不使用標準頭欄位對訊息編目和分類，您就可以新增一個屬性到訊息以實現這個編目和分類。提供 setProperty(...) 和 getProperty(...) 方法以設定和獲取各種 Java 型別的屬性，包括 Object。JMS 定義了一個供應商選擇提供的標準屬性集。
· 訊息的主體（body）包含要傳送給接收應用程式的內容。每個訊息介面特定於它所支援的內容型別。
JMS 為不同型別的內容提供了它們各自的訊息型別，但是所有訊息都派生自 Message 介面。
· StreamMessage：包含 Java 基本數值流，用標準流操作來順序的填充和讀取。
· MapMessage：包含一組名/值對；名稱為 string 型別，而值為 Java 的基本型別。
· TextMessage：包含一個 String。
· ObjectMessage：包含一個 Serializable Java 物件；能使用 JDK 的集合類。
· BytesMessage：包含未解釋位元組流: 編碼主體以匹配現存的訊息格式。
· XMLMessage: 包含XML內容。擴充套件TextMessage,XMLMessage 型別的使用，使得訊息過濾非常便利。
3. 訊息確認模式
非事務性會話中，應用程式建立的會話有5 種確認模式,而在事務性會話中，確認模式被忽略。
五種確認模式說明:
· AUTO_ACKNOWLEDGE：自動確認模式。一旦接收方應用程式的方法呼叫從處理訊息處返回，會話物件就會確認訊息的接收。
· CLIENT_ACKNOWLEDGE：客戶端確認模式。會話物件依賴於應用程式對被接收的訊息呼叫一個acknowledge()方法。一旦這個方法被呼叫，會話會確認最後一次確認之後所有接收到的訊息。這種模式允許應用程式以一個呼叫來接收，處理並確認一批訊息。注意：在管理控制檯中，如果連線工廠的Acknowledge Policy（確認方針）屬性被設定為"Previous"（提前），但是你希望為一個給定的會話確認所有接收到的訊息，那麼就用最後一條訊息來呼叫acknowledge()方法。
· DUPS_OK_ACKNOWLEDGE：允許副本的確認模式。一旦接收方應用程式的方法呼叫從處理訊息處返回，會話物件就會確認訊息的接收；而且允許重複確認。在需要考慮資源使用時，這種模式非常有效。注意：如果你的應用程式無法處理重複的訊息的話，你應該避免使用這種模式。如果傳送訊息的初始化嘗試失敗，那麼重複的訊息可以被重新傳送。
· NO_ACKNOWLEDGE：不確認模式。不確認收到的訊息是需要的。訊息傳送給一個NO_ACKNOWLEDGE 會話後，它們會被WebLogic 伺服器立即刪除。在這種模式下，將無法重新獲得已接收的訊息，而且可能導致下面的結果：1. 訊息可能丟失；和（或者）另一種情況：2. 如果傳送訊息的初始化嘗試失敗，會出現重複訊息被髮送的情況。
· MULTICAST_NO_ACKNOWLEDGE：IP組播下的不確認模式，同樣無需確認。傳送給一個MULTICAST_NO_ACKNOWLEDGE會話的訊息， 會共享之前所述的NO_ACKNOWLEDGE 確認模式一樣的特徵。這種模式支援希望通過IP 組播方式進行訊息通訊的應用程式，而且無需依賴會話確認提供的服務質量。注意：如果你的應用程式無法處理訊息的丟失或者重複，那麼你應該避免使用這種模式。如果傳送訊息的初始化嘗試失敗的話，重複的訊息可能會被再次傳送。
注：在上表的5 種確認模式中，AUTO_ACKNOWLEDGE ，DUPS_OK_ACKNOWLEDGE 和
CLIENT_ACKNOWLEDGE 是JMS 規範定義的，NO_ACKNOWLEDGE 和MULTICAST_NO_ACKNOWLEDGE是WebLogic JMS 提供的。
參考資料：Roslin http://www.垃圾廣告.cn/articleview/2007-1-16/article_view_854.htm
JMS（Java Message Service，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 沒有訊息體，只有訊息頭和屬性。
下例演示建立併傳送一個TextMessage到一個佇列：
TextMessage message = queueSession.createTextMessage(); message.setText(msg_text); // msg_text is a String queueSender.send(message);
下例演示接收訊息並轉換為合適的訊息型別：
Message m = queueReceiver.receive(); if (m instanceof
JMS:不要瞎譯~！
到百度百科來做廣告太誇張了吧~~！