JMS 入門

        

JMS（Java Messaging Service）是Java平臺上有關面向消息中間件(MOM)的技術規范，它便于消息系統中的Java應用程序進行消息交換,并且通過提供標準的產生、發送、接收消息的接口簡化企業應用的開發，翻譯為Java消息服務。

        JMS是一種與廠商無關的 API，用來訪問消息收發系統。它類似于 JDBC(Java Database Connectivity)：這里，JDBC 是可以用來訪問許多不同關系數據庫的 API，而 JMS 則提供同樣與廠商無關的訪問方法，以訪問消息收發服務。許多廠商目前都支持 JMS，包括 IBM 的 MQSeries、BEA的 Weblogic JMS service和 Progress 的 SonicMQ，這只是幾個例子。 JMS 使您能夠通過消息收發服務（有時稱為消息中介程序或路由器）從一個 JMS 客戶機向另一個 JMS客戶機發送消息。消息是 JMS 中的一種類型對象，由兩部分組成：報頭和消息主體。報頭由路由信息以及有關該消息的元數據組成。消息主體則攜帶著應用程序的數據或有效負載。根據有效負載 的類型來劃分，可以將消息分為幾種類型，它們分別攜帶：簡單文本 (TextMessage)、可序列化的對象 (ObjectMessage)、屬性集合 (MapMessage)、字節流 (BytesMessage)、原始值流 (StreamMessage)，還有無有效負載的消息 (Message)。

        Java消息服務是一個在 Java標準化組織（JCP）內開發的標準（代號JSR 914）。2001年6月25日，Java消息服務發布JMS 1.0.2b，2002年3月18日Java消息服務發布 1.1，統一了消息域。

        JMS有以下元素組成。

        JMS提供者

        連接面向消息中間件的，JMS接口的一個實現。提供者可以是Java平臺的JMS實現，也可以是非Java平臺的面向消息中間件的適配器。

        JMS客戶

        生產或消費基于消息的Java的應用程序或對象。

        JMS生產者

        創建并發送消息的JMS客戶。

        JMS消費者

        接收消息的JMS客戶。

        JMS消息

        包括可以在JMS客戶之間傳遞的數據的對象

        JMS隊列

        一個容納那些被發送的等待閱讀的消息的區域。隊列暗示，這些消息將按照順序發送。一旦一個消息被閱讀，該消息將被從隊列中移走。

        JMS主題

        一種支持發送消息給多個訂閱者的機制。

        Java消息服務應用程序結構支持兩種模型：

        點對點或隊列模型

        發布者/訂閱者模型

        在點對點或隊列模型下，一個生產者向一個特定的隊列發布消息，一個消費者從該隊列中讀取消息。這里，生產者知道消費者的隊列，并直接將消息發送到消費者的隊列。這種模式被概括為：

        只有一個消費者將獲得消息

        生產者不需要在接收者消費該消息期間處于運行狀態，接收者也同樣不需要在消息發送時處于運行狀態。

        每一個成功處理的消息都由接收者簽收

        發布者/訂閱者模型支持向一個特定的消息主題發布消息。0或多個訂閱者可能對接收來自特定消息主題的消息感興趣。在這種模型下，發布者和訂閱者彼此不知道對方。這種模式好比是匿名公告板。這種模式被概括為：

        多個消費者可以獲得消息

        在發布者和訂閱者之間存在時間依賴性。發布者需要建立一個訂閱（subscription），以便客戶能夠購訂閱。訂閱者必須保持持續的活動狀態以接收消息，除非訂閱者建立了持久的訂閱。在那種情況下，在訂閱者未連接時發布的消息將在訂閱者重新連接時重新發布。

        使用Java語言，JMS提供了將應用與提供數據的傳輸層相分離的方式。同一組Java類可以通過JNDI中關于提供者的信息，連接不同的JMS提供者。這一組類首先使用一個連接工廠以連接到隊列或主題，然后發送或發布消息。在接收端，客戶接收或訂閱這些消息。

        JMS現在有兩種傳遞消息的方式。標記為NON_PERSISTENT的消息最多 投遞一次，而標記為PERSISTENT的消息將使用暫存后再轉送的機理投遞。如果一個JMS服務離線，那么持久性消息不會丟失但是得等到這個服務恢復聯 機時才會被傳遞。所以默認的消息傳遞方式是非持久性的。即使使用非持久性消息可能降低內務和需要的存儲器，并且這種傳遞方式只有當你不需要接收所有的消息 時才使用。

        雖然JMS規范并不需要JMS供應商實現消息的優先級路線，但是它需要遞送加快的 消息優先于普通級別的消息。JMS定義了從0到9的優先級路線級別，0是最低的優先級而9則是最高的。更特殊的是0到4是正常優先級的變化幅度，而5到9 是加快的優先級的變化幅度。舉例來說： topicPublisher.publish (message, DeliveryMode.PERSISTENT, 8, 10000); //Pub-Sub 或 queueSender.send(message,DeliveryMode.PERSISTENT, 8, 10000);//P2P 這個代碼片斷，有兩種消息模型，映射遞送方式是持久的，優先級為加快型，生存周期是10000 (以毫秒度量 )。如果生存周期設置為零，這則消息將永遠不會過期。當消息需要時間限制否則將使其無效時，設置生存周期是有用的。

        JMS定義了五種不同的消息正文格式，以及調用的消息類型，允許你發送并接收以一些不同形式的數據，提供現有消息格式的一些級別的兼容性。

        · StreamMessage -- Java原始值的數據流

        · MapMessage--一套名稱-值對

        · TextMessage--一個字符串對象

        · ObjectMessage--一個序列化的 Java對象

        · BytesMessage--一個未解釋字節的數據流

        用戶用來創建到JMS提供者的連接的被管對象。JMS客戶通過可移植的接口訪問連 接，這樣當下層的實現改變時，代碼不需要進行修改。 管理員在JNDI名字空間中配置連接工廠，這樣，JMS客戶才能夠查找到它們。根據消息類型的不同，用戶將使用隊列連接工廠，或者主題連接工廠。

        連接代表了應用程序和消息服務器之間的通信鏈路。在獲得了連接工廠后，就可以創建一個與JMS提供者的連接。根據不同的連接類型，連接允許用戶創建會話，以發送和接收隊列和主題到目標。

        目標是一個包裝了消息目標標識符的被管對象，消息目標是指消息發布和接收的地點，或者是隊列，或者是主題。JMS管理員創建這些對象，然后用戶通過JNDI發現它們。和連接工廠一樣，管理員可以創建兩種類型的目標，點對點模型的隊列，以及發布者/訂閱者模型的主題。

        由會話創建的對象，用于接收發送到目標的消息。消費者可以同步地（阻塞模式），或異步（非阻塞）接收隊列和主題類型的消息。

        由會話創建的對象，用于發送消息到目標。用戶可以創建某個目標的發送者，也可以創建一個通用的發送者，在發送消息時指定目標。

        是在消費者和生產者之間傳送的對象，也就是說從一個應用程序傳送到另一個應用程序。一個消息有三個主要部分：

        消息頭（必須）：包含用于識別和為消息尋找路由的操作設置。

        一組消息屬性（可選）：包含額外的屬性，支持其他提供者和用戶的兼容。可以創建定制的字段和過濾器（消息選擇器）。

        一個消息體（可選）：允許用戶創建五種類型的消息（文本消息，映射消息，字節消息，流消息和對象消息）。

        消息接口非常靈活，并提供了許多方式來定制消息的內容。

        表示一個單線程的上下文，用于發送和接收消息。由于會話是單線程的，所以消息是連 續的，就是說消息是按照發送的順序一個一個接收的。會話的好處是它支持事務。如果用戶選擇了事務支持，會話上下文將保存一組消息，直到事務被提交才發送這 些消息。在提交事務之前，用戶可以使用回滾操作取消這些消息。一個會話允許用戶創建消息生產者來發送消息，創建消息消費者來接收消息。

        要使用Java消息服務，你必須要有一個JMS提供者，管理會話和隊列。現在既有開源的提供者也有專有的提供者。

        開源的提供者包括：

        Apache ActiveMQ

        JBoss 社區所研發的 HornetQ

        Joram

        Coridan的MantaRay

        The OpenJMS Group的OpenJMS

        專有的提供者包括：

        BEA的BEA WebLogic Server JMS

        TIBCO Software的EMS

        GigaSpaces Technologies的GigaSpaces

        Softwired 2006的iBus

        IONA Technologies的IONA JMS

        SeeBeyond的IQManager（2005年8月被Sun Microsystems并購）

        webMethods的JMS+ -

        my-channels的Nirvana

        Sonic Software的SonicMQ

        SwiftMQ的SwiftMQ

        IBM的WebSphere MQ

-------------------------------------------------------------------------------------------------------------------------------------------------------

MQ的基本概念：

1) 隊列管理器

隊列管理器是MQ系統中最上層的一個概念，由它為我們提供基于隊列的消息服務。

2) 消息

在MQ中，我們把應用程序交由MQ傳輸的數據定義為消息，我們可以定義消息的內容并對消息進行廣義的理解，比如：用戶的各種類型的數據文件，某個應用向其它應用發出的處理請求等都可以作為消息。消息有兩部分組成：

消息描述符(Message Discription或Message Header)，描述消息的特征，如：消息的優先級、生命周期、消息Id等；

消息體(Message Body)，即用戶數據部分。在MQ中，消息分為兩種類型，非永久性(non-persistent)消息和永久性(persistent)消息，非永久 性消息是存儲在內存中的，它是為了提高性能而設計的，當系統掉電或MQ隊列管理器重新啟動時，將不可恢復。當用戶對消息的可靠性要求不高，而側重系統的性 能表現時，可以采用該種類型的消息，如：當發布股票信息時，由于股票信息是不斷更新的，我們可能每若干秒就會發布一次，新的消息會不斷覆蓋舊的消息。永久 性消息是存儲在硬盤上，并且紀錄數據日志的，它具有高可靠性，在網絡和系統發生故障等情況下都能確保消息不丟、不重。

此外，在MQ中，還有邏輯消息和物理消息的概念。利用邏輯消息和物理消息，我們可以將大消息進行分段處理，也可以將若干個本身完整的消息在應用邏輯上歸為一組進行處理。

3) 隊列

隊列是消息的安全存放地，隊列存儲消息直到它被應用程序處理。

消息隊列以下述方式工作：

a) 程序A形成對消息隊列系統的調用，此調用告知消息隊列系統，消息準備好了投向程序B；

b) 消息隊列系統發送此消息到程序B駐留處的系統，并將它放到程序B的隊列中；

c) 適當時間后，程序B從它的隊列中讀此消息，并處理此信息。

由于采用了先進的程序設計思想以及內部工作機制，MQ能夠在各種網絡條件下保證消息的可靠傳遞，可以克服網絡線路質量差或不穩定的現狀，在傳輸過程 中，如果通信線路出現故障或遠端的主機發生故障，本地的應用程序都不會受到影響，可以繼續發送數據，而無需等待網絡故障恢復或遠端主機正常后再重新運行。

在MQ中，隊列分為很多種類型，其中包括：本地隊列、遠程隊列、模板隊列、動態隊列、別名隊列等。

本地隊列又分為普通本地隊列和傳輸隊列，普通本地隊列是應用程序通過API對其進行讀寫操作的隊列；傳輸隊列可以理解為存儲-轉發隊列，比如：我們 將某個消息交給MQ系統發送到遠程主機，而此時網絡發生故障，MQ將把消息放在傳輸隊列中暫存，當網絡恢復時，再發往遠端目的地。

遠程隊列是目的隊列在本地的定義，它類似一個地址指針，指向遠程主機上的某個目的隊列，它僅僅是個定義，不真正占用磁盤存儲空間。

模板隊列和動態隊列是MQ的一個特色，它的一個典型用途是用作系統的可擴展性考慮。我們可以創建一個模板隊列，當今后需要新增隊列時，每打開一個模 板隊列，MQ便會自動生成一個動態隊列，我們還可以指定該動態隊列為臨時隊列或者是永久隊列，若為臨時隊列我們可以在關閉它的同時將它刪除，相反，若為永 久隊列，我們可以將它永久保留，為我所用。

4) 通道

通道是MQ系統中隊列管理器之間傳遞消息的管道，它是建立在物理的網絡連接之上的一個邏輯概念，也是MQ產品的精華。

在MQ中，主要有三大類通道類型，即消息通道，MQI通道和Cluster通道。消息通道是用于在MQ的服務器和服務器之間傳輸消息的，需要強調指 出的是，該通道是單向的，它又有發送(sender), 接收(receive), 請求者(requestor), 服務者(server)等不同類型，供用戶在不同情況下使用。MQI通道是MQ Client和MQ Server之間通訊和傳輸消息用的，與消息通道不同，它的傳輸是雙向的。群集(Cluster)通道是位于同一個MQ 群集內部的隊列管理器之間通訊使用的。