利用JMS建立消息傳遞系統
在開始之前需要說明，為了理解本文，我們希望讀者擁有Java編程的相當堅實的基礎。我們將試圖盡可能簡單地解釋什么是JMS，但是在你能夠建立自己的程序并正確地理解它們之前，你需要有一些使用JNDI開發實際應用程序的經驗。
JMS（Java消息服務）是一個消息交換標準，它允許使用J2EE應用程序組件建立、發送、接收和讀取消息。它假設分布式通訊擁有自由（free）的連接、是可靠的（reliable）和異步的（asynchronous）。
Exchange（交換）系統
消息交換反映了程序組件或應用程序之間的一種交互作用。消息交換系統是一種類似于下的系統：一個相似系統的客戶端可以發送和接收任何其它客戶端的消息。每個客戶端都并入系統的代理中，它提供了建立、發送、接收和讀取消息的可能。
交換系統使得分布式的交互操作成為可能。組件在目的地（Destination）發送消息，收件人也可以在相同的目的地中得到這個消息。發送者和收件人不一定是互相熟悉的。換句話說，它并沒有強迫發送者知道一些收件人的信息，也沒有強迫收件人知道某些發送者的信息。發送者和收件人只需要知道消息的格式以及要到達的目的地。在這種情形下，上述的系統不同于與它緊密相連的一些技術，例如遠程方法調用（RMI），它只要求開發人員了解RMI中的一些方法。
消息傳遞系統
消息傳遞系統是一種分布式的系統，是基于系統組件之間的異步消息交換。面向消息的中間件（Message-Oriented Middleware，MOM）就是這種產品，消息傳遞系統是在它的原理上建立的。
消息傳遞系統應用軟件不會直接地通訊（這與傳統的系統（基于RMI的）形成鮮明的對照），而需要依賴MOM的幫助。如果系統的某個組件希望給另一個組件發送消息，它將把給定的消息發送給MOM，接著MOM把該消息發送給收件人。
與傳統的基于RMI構建的系統相比，它有以下優點：
· 發送消息的應用程序不需要期待回應，可以繼續執行。
· 沒有強迫發送消息的應用程序和特定消息的收件人在某個特定的時刻是激活的。如果消息的收件人不是激活的，MOM保證收件人一旦激活就立即收到該消息。
· 系統組件沒有直接地彼此相連。它們被分離開了，這就是在運行時刻能把組件從一個主機傳輸到另一個、卻不會中斷系統可用性的原因。
消息交換模型：點對點模型和發表－預訂模型
目前有兩種“基本的”消息交換模型：點對點模型和發表－預訂（pub-sub）模型。點對點模型應用于一個或多個組件（發送者）僅僅給一個組件收件人（接收者）發送消息的情形。這種模型是基于消息隊列概念的：發送者把消息發送到隊列中，接收者從該隊列中讀取消息。在點對點模型中，相同的隊列上可能存在多個接收者，但是MOM只給其中一個傳遞消息。給哪一個傳遞消息依賴于MOM的實現（implementation）。
發表－預訂模型應用于一個或多個組件（發表者）給一個或多個組件收件人（預訂者）發送消息的情形。這種特定的模型是基于消息主題（message topic）概念的：發表者把消息發送到某個主題中，而該特定主題的預訂者接收這些消息。
發表－預訂模型看起來更加“優雅”，但是很多發表－預訂模型不能保證消息按照發送的次序傳遞（它與點對點模型相反，點對點隊列實現了FIFO（先進先出）原理）。因此，消息的次序很重要（或者為了同步需要使用消息的頭和屬性部分）的時候，就應該避免采用發表－預訂模型。
Java消息服務（JMS）是使用面向消息中間件的一套Java API，它允許你的應用程序建立、發送、接收和讀取消息。這組程序集位于J2EE程序包結構樹上的javax.jms程序包中。JMS在很多MOM產品中得到了實現，其中iPlanet Message Queue、 IBM MQSeries、Progress Software SonicMQ、BEA WebLogic Server、Prism Technologies OpenFusion等最有名氣，也存在一些免費的實現。
JMS同時支持消息交換的兩種“基本的”模型。但是，其說明（specification）并沒有要求廠商同時實現兩種模型，盡管大多數JMS產品實現了點對點和發表－預訂模型。
JMS應用程序
JMS應用程序的主要部分是：
· 產生連接的部分和目的地
· 連接
· 對話
· 產生消息的部分
· 使用消息的部分
· 消息
產生連接的部分（ConnectionFactory）是負責建立JMS連接的對象。每個ConnectionFactory都是QueueConnectionFactory或TopicConnectionFactory的一個副本（copy）。MOM管理器建立特定的對象，并把它與JNDI樹關聯起來，這樣JMS客戶端就能夠使用標準的JNDI查找表得到ConnectionFactory的入口。在點對點的模型中，它使用了javax.jms.QueueConnectionFactory；在發表－預訂模型中，它使用的是javax.jms.TopicConnectionFactory。
目的地（Destination）——它是隊列或主題，這依賴于我們使用了下面哪種模型：javax.jms.Queue或javax.jms.Topic。
連接（Connection）——它可能是客戶端和服務應用之間的開放的TCP/IP。它可以被用于建立一個或少量的對話。在你的應用程序能夠接收消息前，你必須調用start()方法。為了暫停發送消息，你需要調用stop()。
對話（Session）——在JMS連接的幫助下建立的對象，被客戶端用作發送和接收消息。
產生消息的部分（MessageProducer）——對話建立的對象，被用于在目的地中發送消息。
使用消息的部分（MessageConsumer）——對話建立的對象，用于接收消息。為了同步接收消息，需要使用receive()方法。對于異步的情形，使用MessageListener和唯一的方法——onMessage()。在該方法中，在定義的消息到達后應該執行一定的操作。
消息（Message）——消息本身。JMS消息由三個部分組成：
· 消息頭
· 屬性（不是必要的）
· 消息體（不是必要的）
本文沒有解釋更多的細節信息，你可以在官方文檔中找到具體的細節。
什么時候使用EJB 2.0
請注意下述各項內容：
在新的EJB 2.0規范中，與JMS的集成是通過建立新的EJB類型——消息驅動Bean（MDB）來實現的。MDB的特性是客戶端不會使用遠程接口（remote interface）與它通訊。其交互操作的唯一途徑是通過消息發送。MDB僅僅是消息監聽程序，是一個實現了javax.ejb.MessageDrivenBean和javax.jms.MessageListener接口的類，沒有任何其它的功能。其中的第一個接口只有兩個方法：setMessageDrivenContext() 和ejbRemove()。第二個接口只有一個方法：onMessage()。這個規范還需要一個不帶參數的ejbCreate()建立方法。客戶端不會直接與MDB通訊；它不會建立MDB。容器（container）自身決定什么時候和需要多少個MDB來處理來自特定目的地的消息。MDB的主要缺陷是它只能從一個目的地接收到消息。
JMS（Java消息服務）是一個消息交換標準，它允許使用J2EE應用程序組件建立、發送、接收和讀取消息。它假設分布式通訊擁有自由（free）的連接、是可靠的（reliable）和異步的（asynchronous）。
Exchange（交換）系統
消息交換反映了程序組件或應用程序之間的一種交互作用。消息交換系統是一種類似于下的系統：一個相似系統的客戶端可以發送和接收任何其它客戶端的消息。每個客戶端都并入系統的代理中，它提供了建立、發送、接收和讀取消息的可能。
交換系統使得分布式的交互操作成為可能。組件在目的地（Destination）發送消息，收件人也可以在相同的目的地中得到這個消息。發送者和收件人不一定是互相熟悉的。換句話說，它并沒有強迫發送者知道一些收件人的信息，也沒有強迫收件人知道某些發送者的信息。發送者和收件人只需要知道消息的格式以及要到達的目的地。在這種情形下，上述的系統不同于與它緊密相連的一些技術，例如遠程方法調用（RMI），它只要求開發人員了解RMI中的一些方法。
消息傳遞系統
消息傳遞系統是一種分布式的系統，是基于系統組件之間的異步消息交換。面向消息的中間件（Message-Oriented Middleware，MOM）就是這種產品，消息傳遞系統是在它的原理上建立的。
消息傳遞系統應用軟件不會直接地通訊（這與傳統的系統（基于RMI的）形成鮮明的對照），而需要依賴MOM的幫助。如果系統的某個組件希望給另一個組件發送消息，它將把給定的消息發送給MOM，接著MOM把該消息發送給收件人。
 |
與傳統的基于RMI構建的系統相比，它有以下優點：
· 發送消息的應用程序不需要期待回應，可以繼續執行。
· 沒有強迫發送消息的應用程序和特定消息的收件人在某個特定的時刻是激活的。如果消息的收件人不是激活的，MOM保證收件人一旦激活就立即收到該消息。
· 系統組件沒有直接地彼此相連。它們被分離開了，這就是在運行時刻能把組件從一個主機傳輸到另一個、卻不會中斷系統可用性的原因。
消息交換模型：點對點模型和發表－預訂模型
目前有兩種“基本的”消息交換模型：點對點模型和發表－預訂（pub-sub）模型。點對點模型應用于一個或多個組件（發送者）僅僅給一個組件收件人（接收者）發送消息的情形。這種模型是基于消息隊列概念的：發送者把消息發送到隊列中，接收者從該隊列中讀取消息。在點對點模型中，相同的隊列上可能存在多個接收者，但是MOM只給其中一個傳遞消息。給哪一個傳遞消息依賴于MOM的實現（implementation）。
發表－預訂模型應用于一個或多個組件（發表者）給一個或多個組件收件人（預訂者）發送消息的情形。這種特定的模型是基于消息主題（message topic）概念的：發表者把消息發送到某個主題中，而該特定主題的預訂者接收這些消息。
發表－預訂模型看起來更加“優雅”，但是很多發表－預訂模型不能保證消息按照發送的次序傳遞（它與點對點模型相反，點對點隊列實現了FIFO（先進先出）原理）。因此，消息的次序很重要（或者為了同步需要使用消息的頭和屬性部分）的時候，就應該避免采用發表－預訂模型。
Java消息服務（JMS）是使用面向消息中間件的一套Java API，它允許你的應用程序建立、發送、接收和讀取消息。這組程序集位于J2EE程序包結構樹上的javax.jms程序包中。JMS在很多MOM產品中得到了實現，其中iPlanet Message Queue、 IBM MQSeries、Progress Software SonicMQ、BEA WebLogic Server、Prism Technologies OpenFusion等最有名氣，也存在一些免費的實現。
JMS同時支持消息交換的兩種“基本的”模型。但是，其說明（specification）并沒有要求廠商同時實現兩種模型，盡管大多數JMS產品實現了點對點和發表－預訂模型。
JMS應用程序
JMS應用程序的主要部分是：
· 產生連接的部分和目的地
· 連接
· 對話
· 產生消息的部分
· 使用消息的部分
· 消息
產生連接的部分（ConnectionFactory）是負責建立JMS連接的對象。每個ConnectionFactory都是QueueConnectionFactory或TopicConnectionFactory的一個副本（copy）。MOM管理器建立特定的對象，并把它與JNDI樹關聯起來，這樣JMS客戶端就能夠使用標準的JNDI查找表得到ConnectionFactory的入口。在點對點的模型中，它使用了javax.jms.QueueConnectionFactory；在發表－預訂模型中，它使用的是javax.jms.TopicConnectionFactory。
目的地（Destination）——它是隊列或主題，這依賴于我們使用了下面哪種模型：javax.jms.Queue或javax.jms.Topic。
連接（Connection）——它可能是客戶端和服務應用之間的開放的TCP/IP。它可以被用于建立一個或少量的對話。在你的應用程序能夠接收消息前，你必須調用start()方法。為了暫停發送消息，你需要調用stop()。
對話（Session）——在JMS連接的幫助下建立的對象，被客戶端用作發送和接收消息。
產生消息的部分（MessageProducer）——對話建立的對象，被用于在目的地中發送消息。
使用消息的部分（MessageConsumer）——對話建立的對象，用于接收消息。為了同步接收消息，需要使用receive()方法。對于異步的情形，使用MessageListener和唯一的方法——onMessage()。在該方法中，在定義的消息到達后應該執行一定的操作。
消息（Message）——消息本身。JMS消息由三個部分組成：
· 消息頭
· 屬性（不是必要的）
· 消息體（不是必要的）
本文沒有解釋更多的細節信息，你可以在官方文檔中找到具體的細節。
什么時候使用EJB 2.0
請注意下述各項內容：
在新的EJB 2.0規范中，與JMS的集成是通過建立新的EJB類型——消息驅動Bean（MDB）來實現的。MDB的特性是客戶端不會使用遠程接口（remote interface）與它通訊。其交互操作的唯一途徑是通過消息發送。MDB僅僅是消息監聽程序，是一個實現了javax.ejb.MessageDrivenBean和javax.jms.MessageListener接口的類，沒有任何其它的功能。其中的第一個接口只有兩個方法：setMessageDrivenContext() 和ejbRemove()。第二個接口只有一個方法：onMessage()。這個規范還需要一個不帶參數的ejbCreate()建立方法。客戶端不會直接與MDB通訊；它不會建立MDB。容器（container）自身決定什么時候和需要多少個MDB來處理來自特定目的地的消息。MDB的主要缺陷是它只能從一個目的地接收到消息。