文章來源……IMB中國
應用程序
JMS 應用程序由以下元素組成：
- JMS 客戶機。 用 JMS API 發送和接收消息的 Java 程序。
- 非 JMS 客戶機。 認識到傳統程序通常整個 JMS 應用程序的一部分是非常重要的，在規劃時必須優先考慮它們的存在。
- 消息。就JMS 應用程序設計而言，通過JMS 和非 JMS 客戶機所交換的消息的格式和內容是完整的。
- JMS 提供者。 如前所述，JMS 定義了一組接口，供應者必須提供特定於其 MOM 產品的具體實現。
- 管理對象。 消息系統提供者的管理員創建的、獨立於提供者的專有技術的對象。
管理對象
MOM 產品的提供者在實現消息時使用的機制和技術有很大不同。爲了保持 JMS 客戶機的可移植性，實現了 JMS 接口的對象必須與提供者的專有技術隔離。
完成這項任務的機制是 管理對象。這些實現 JMS 接口的對象由提供者的消息系統的管理員創建，並被放置在 JNDI 名字空間中。
然後由 JMS 程序檢索這些對象，通過它們實現的 JMS 接口訪問這些對象。JMS 提供者必須提供允許創建受管理對象及它們在 JNDI 名字空間中的存放地的工具。
有兩種受管理對象：
ConnectionFactory：用於創建到提供者的底層消息系統的連接。Destination：用 JMS 客戶機來指定正發送消息的目的地或正接收消息的來源。
儘管受管理對象本身就是特定於提供者實現的類的例子，但可以使用可移植機制（JNDI）檢索它們，並且可以通過可移植接口（JMS）訪問它們。JMS 程序只需要知道管理對象的 JNDI 名稱和 JMS 接口類型即可，無需瞭解特定於提供者的知識。
接口
JMS 定義了一組封裝各種消息概念的高級接口。而這些接口又因爲兩個消息域——PTP 和 pub/sub——進行了進一步地定義和定製。
高級接口包括：
ConnectionFactory：一個創建Connection的受管理對象。Connection：連接到提供者的活動連接。Destination：一個封裝消息目的地的身份的受管理對象，如消息的來源地和發送地。Session：發送和接收消息的單線程環境。爲了簡化，並且因爲Session控制事務的緣故，通過多個線程進行併發訪問受到了限制。可以將多個Session用於多線程應用程序。MessageProducer：用於發送消息。MessageConsumer：用於接收消息。
下表列出了從每一個高級接口繼承的特定於域的接口
| 高級接口 | PTP 域 | Pub/sub 域 |
|---|---|---|
ConnectionFactory |
QueueConnectionFactory |
TopicConnectionFactory |
Connection |
QueueConnection |
TopicConnection |
Destination |
Queue |
Topic |
Session |
QueueSession |
TopicSession |
MessageProducer |
QueueSender |
TopicPublisher |
MessageConsumer |
QueueReceiver，QueueBrowser |
TopicSubscriber |
開發 JMS 程序
一個典型的 JMS 程序要經過以下步驟才能開始產生和使用消息：
- 通過 JNDI 查詢
ConnectionFactory。 - 通過 JNDI 查詢一個或者多個
Destination。 - 用
ConnectionFactory創建一個Connection。 - 用
Connection創建一個或者多個Session。 - 用
Session和Destination創建所需要的MessageProducer和MessageConsumer。 - 啓動
Connection。
這時，消息就可以開始流動，應用程序可以根據需要接收、處理和發送消息。 在後面幾節中，我們將開發 JMS 程序，您將會看到這些步驟的細節。
消息
消息系統的核心當然是消息。JMS 爲不同類型的內容提供了幾種消息類型，但所有消息都是從 Message 接口派生出來的。
Message 分爲三個組成部分：
- header 是一組標準字段，客戶機和提供者都用它們來標識和路由消息。
- Properties 提供了一個給消息添加可選標題字段的實用工具。如果應用程序需要用標準標題字段沒有提供的方法對消息進行歸類或分類，那麼可以爲消息添加一個屬性來實現這種歸類和分類；提供了
set<type></type>Property(...)和get<type></type>Property(...)方法來設置和獲得各種 Java 類型的屬性，其中包括Object。JMS 定義了提供者可以選擇性提供的一組標準屬性。 - 消息的 body 包含將 發送到接收應用程序的內容。每一個消息接口都專用於它所支持的內容類型。
header 字段
下面列出了 Message 的每一個標題字段的名稱、它對應的 Java 類型和字段的描述：
JMSMessageID——類型爲string惟一標識提供者發送的每一條消息。這個字段是在發送過程中由提供者設置的，客戶機只能在消息發送後才能確定消息的
JMSMessageID。JMSDestination——類型爲Destination消息發送的
Destination，在發送過程中由提供者設置。JMSDeliveryMode——類型爲int包含值
DeliveryMode.PERSISTENT或者DeliveryMode.NON_PERSISTENT。持久性消息被傳輸並且只被傳輸一次，非持久性消息最多被傳輸一次。要知道“最多一次”包括根本不傳輸。非持久性消息在應用程序或者系統出故障時被提供者弄丟。因此要格外小心，確保持久性消息不受故障的影響。這比開銷通常被認爲是發送持久性消息方面的開銷，在決定消息的發送模式時，必須仔細考慮，在可靠性和性能之間進行權衡。JMSTimestamp——類型爲long提供者發送消息的時間，由提供者在發送過程中設置。
JMSExpiration——類型爲long消息失效的時間。這個值是在發送過程中計算的，是發送方法的生存時間（time-to-live）值和當前時間值的和。提供者不應發送過期的消息。值 0 表明消息不會過期。
JMSPriority——類型爲int消息的優先級，由提供者在發送過程中設置。優先級 0 的優先級最低，優先級 9 的優先級最高。
JMSCorrelationID——類型爲string通常用來鏈接響應消息與請求消息，由發送消息的 JMS 程序設置。響應來自另一個 JMS 程序的消息的 JMS 程序將正響應消息的
JMSMessageID拷貝到這個字段中，這樣，正作出響應的程序就可以與它所發出的特定請求的響應相 關聯。JMSReplyTo——類型爲Destination請求程序用它來指出回覆消息應發送的地方，由發送消息的 JMS 程序設置。
JMSType——類型爲stringJMS 程序用它來指出消息的類型。一些提供者維護着一個消息類型倉庫，並用該字段引用倉庫中的定義類型，在這裏，JMS 程序不應該使用這個字段。
JMSRedelivered——類型爲boolean指出消息被過早地發送給了 JMS 程序，程序不知道消息的接收者是誰；由提供者在接收過程中設置。
標準屬性
下面列表給出了
Message的每一個標準屬性的名稱、它對應的 Java 類型和該屬性的說明。提供者對標準屬性的支持是可選的。JMS 爲這些屬性和將來 JMS 定義的屬性保留了 “JMSX” 屬性名。JMSXUserID——類型爲string發送消息的用戶的身份。
JMSXApplID——類型爲string發送消息的應用程序的身份。
JMSXDeliveryCount——類型爲int已經嘗試發送消息的次數。
JMSXGroupID——類型爲string該消息所屬的消息組的身份。
JMSXGroupSeq——類型爲int該消息在消息組中的序號。
JMSXProducerTXID——類型爲string生成該消息的事務的身份。
JMSXConsumerTXID——類型爲string使用該消息的事務的身份。
JMSXRcvTimestamp——類型爲longJMS 將消息發送給客戶的時間。
JMSXState——類型爲int提供者用它來維護消息的消息倉庫，通常，它與 JMS 生產者和客戶關係不大。
JMSX_<vendor_name></vendor_name>爲特定於提供者的屬性而保留。
消息正文
有五種消息正文格式，每一種格式都是由一個擴展 Message 的接口定義的。這些接口是：StreamMessage：包含一組 Java 原始值，這些值是通過標準流操作按順序進行填充和讀取的。MapMessage：包含一組名稱-值（ name-value ）對，其中名稱是string的類型，值是 Java 原始值。TextMessage：包含一個String。ObjectMessage：包含一個SerializableJava 對象，可以使用 JDK 1.2 的 collection類。BytesMessage：包含一些未解釋字節；允許對正文進行編碼來匹配現有的消息格式。
每一個提供者都提供了一些特定於實現這些接口的其產品的類。一定要注意的是， JMS 規範命令提供者必須準備接收和處理不屬於它自己的
Message類的實例的Message對象。儘管提供者處理這些“外來”對象時不能像處理自己對象那樣有效，但他們必須處理這些對象來確保與所有 JMS 提供者的互操作性。
事務-
JMS 事務將一組已產生的消息和一組已使用的消息組織爲原子工作單位。如果事務中出現故障，那麼可以“取消”出現錯誤之前產生和使用消息的操作。
Session對象控制事務，創建SessionSessionbegin()；commit()和rollback()可以終止一個事務並自動開始另一個事務。可以通過 Java Transaction API （JTA）XAResource API 支持分佈式事務，儘管這提供者而言是可選擇的。
確認
確認是通知提供者已經成功接收到消息的一種機制。
如果被處理的是接收消息的
Session，則確認的處理是自動的。如果被處理的不是Session，則在創建Session時確定確認的類型。有三種類型的確認：
Session.DUPS_OK_ACKNOWLEDGE：消息發送的延遲迴執，它通過最小化工作的重複來減少開銷，只有在可以預計和處理重複消息時，纔可以使用這種確認。Session.AUTO_ACKNOWLEDGE：在完成接收消息的方法時自動確認消息的發送。Session.CLIENT_ACKNOWLEDGE：通過調用Message的acknowledge()方法顯式確認消息發送。
消息選擇
JMS 提供了一種稱爲 message selector 的機制，以便 JMS 程序對收到的消息進行過濾和分類。
消息選擇器是一個包含表達式的 String ，該表達式的語法是基於 SQL92 的子集的。在嘗試接收消息時，對消息選擇器進行求值，只有與選擇器的選擇標準相匹配的消息才能讓程序變得可用。
選擇是基於與標題字段和屬性的匹配度的，正文值不能用於選擇。JMS 規範中詳細描述了消息選擇器的語法。
JMS 和 XML
基於將大量使用 String 消息的假設，JMS 的制定者加入了 TextMessage 消息類型。
他們的理由是， XML 將會成爲一種流行———否則就是最流行——的表示消息內容的方法。可移植的傳輸機制（JMS）結合可移植的數據表示（XML）被證實是企業應用程序集成（EAI）和其他數據交換領域中的一個強大的工具。
JMS 和 J2EE
J2EE 版本 1.2 要求兼容應用服務器包含 JMS API，但並不強制要求提供 JMS 提供者。
J2EE 版本 1.3 要求應用服務器提供 JMS 提供者。J2EE 版本 1.3 還引入了 消息驅動 bean，爲 Enterprise JavaBeans 容器增加了異步通知能力，並將此作爲 EJB 2.0 規範的一部分。消息驅動 bean 可以實現 MessageListener 接口（請參閱本教程後面的 MessageListener ），並且可以通過EJB 容器在消息到達在部署時指定的目的地時調用消息驅動 bean 。消息驅動 bean 包含處理消息的業務邏輯，如果需要，它還可以調用其他企業 bean 。
J2EE 版本 1.4 要求 J2EE 產品包含支持點對點和發佈/訂閱消息的 JMS 版本 1.1 提供者。它規定， J2EE 應用程序不能使用 JMS 客戶機 API 進行事務處理，事務將由 J2EE 容器處理。J2EE 版本 1.4 還要求 Web 和 EJB 容器中的組件只爲每一個連接創建一個活動 Session。