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

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

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