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

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

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