JMS
開放分類： 程序、計算機、網絡用語
JMS（Java Messaging Service）是Java平臺上有關面向消息中間件的技術規範，翻譯為Java消息服務。JMS支持點對點和發布/訂閱兩種消息模型。
JMS基本概念
1.JMS(Java Message Service)是訪問企業消息系統的標準API,它便於消息系
統中的Java應用程序進行消息交換,並且通過提供標準的產生、發送、接收消息的接口簡化企業應用的開發。
2. JMS基本功能
JMS是用於和面向消息的中間件相互通信的應用程序接口。它既支持點對點(point-to-point)的域，又支持發布/訂閱(publish/subscribe)類型的域，並且提供對下列類型的支持：經認可的消息傳遞,事務型消息的傳遞，壹致性消息和具有持久性的訂閱者支持。JMS還提供了另壹種方式來對您的應用與舊的後臺系統相集成。
3. 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數據庫).
WebLogic JMS特性
1. 消息通信模型
JMS 支持兩種消息通信模型：點到點（point-to-point）（PTP）模型和發布/訂閱（Pub/Sub）模型。除了下列不同之外，這兩種消息通信模型非常地相似：
PTP 模型規定了壹個消息只能有壹個接收者;Pub/Sub 模型允許壹個消息可以有多個接收者。
2. 消息組成
消息傳遞系統的中心就是消息。
壹條 Message 分為三個組成部分：
· 頭（header）是個標準字段集，客戶機和供應商都用它來標識和路由消息。
· 屬性（property）支持把可選頭字段添加到消息。如果您的應用程序需要不使用標準頭字段對消息編目和分類，您就可以添加壹個屬性到消息以實現這個編目和分類。提供 set<Type>Property(...) 和 get<Type>Property(...) 方法以設置和獲取各種 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 提供的