Java 是當前IT 領域中比較流行的技術之一。J2EE 是當前比較流行的企業級應用架構。本人一直致力于J2EE 架構的學習和研究，但是總是對英文文檔有不可言語的恐懼。我想很多J2EE 愛好者和我有同樣的感覺。這樣就影響了我們深入學習J2EE 原始規范的興趣。但是 J2EE 原始的規范文檔對我們深入理解J2EE 有很大的幫助，因為它闡述了規范的來龍去脈，以及違反了規范會造成什么樣的影響。了解了這些緣由和影響，會使我們對J2EE 架構有更深層次的理解。這也是我做該筆記是該規范的動力所在。

　　當前，CORBA、DCOM、RMI 等RPC 中間件技術已廣泛應用于各個領域。但是面對規模和復雜度都越來越高的分布式系統，這些技術也顯示出其局限性：（1）同步通信：客戶發出調用后，必須等待服務對象完成處理并返回結果后才能繼續執行；（2）客戶和服務對象的生命周期緊密耦合：客戶進程和服務對象進程都必須正常運行；如果由于服務對象崩潰或者網絡故障導致客戶的請求不可達，客戶會接收到異常；（3）點對點通信：客戶的一次調用只發送給某個單獨的目標對象。面向消息的中間件（Message Oriented Middleware，MOM）較好的解決了以上問題。發送者將消息發送給消息服務器，消息服務器將消息存放在若干隊列中，在合適的時候再將消息轉發給接收者。這種模式下，發送和接收是異步的，發送者無需等待；二者的生命周期未必相同：發送消息的時候接收者不一定運行，接收消息的時候發送者也不一定運行； 一對多通信：對于一個消息可以有多個接收者。已有的 MOM 系統包括IBM 的MQSeries、Microsoft 的MSMQ 和BEA 的Mes sageQ 等。由于沒有一個通用的標準，這些系統很難實現互操作和無縫連接。Java Message Service（JMS）是SUN 提出的旨在統一各種MOM 系統接口的規范，它包含點對點（Point to Point，PTP）和發布/訂閱（Publish/Subscribe， pub/sub）兩種消息模型，提供可靠消息傳輸、事務和消息過濾等機制。

　　在 JMS 編程模型中，JMS 客戶端（組件或應用程序）通過 JMS 消息服務交換消息。消息生產者將消息發送至消息服務，消息消費者則從消息服務接收這些消息。這些消息傳送操作是使用一組實現 JMS 應用編程接口 （API） 的對象（由 JMS Provide 提供）來執行的。在 JMS 編程模型中，JMS 客戶端使用 ConnectionFactory 對象創建一個連接，向消息服務發送消息以及從消息服務接收消息均是通過此連接來進行。Connection 是客戶端與消息服務的活動連接。創建連接時，將分配通信資源以及驗證客戶端。這是一個相當重要的對象，大多數客戶端均使用一個連接來進行所有的消息傳送。連接用于創建會話。Session 是一個用于生成和使用消息的單線程上下文。它用于創建發送的生產者和接收消息的消費者，并為所發送的消息定義發送順序。會話通過大量確認選項或通過事務來支持可靠傳送。客戶端使用 MessageProducer 向指定的物理目標（在 API 中表示為目標身份對象）發送消息。生產者可指定一個默認傳送模式（持久性消息與非持久性消息）、優先級和有效期值，以控制生產者向物理目標發送的所有消息。同樣，客戶端使用 MessageConsumer 對象從指定的物理目標（在 API 中表示為目標對象）接收消息。消費者可使用消息選擇器，借助它，消息服務可以只向消費者發送與選擇標準匹配的那些消息。消費者可以支持同步或異步消息接收。異步使用可通過向消費者注冊 MessageList ener 來實現。當會話線程調用 MessageListener 對象的 onMessage 方法時，客戶端將使用消息。