MQ基礎概念和介紹

1、中間件

    MQ是一種中間件產品，至於什麼是中間件，中間件能幹什麼，參見如下連接:

http://baike.baidu.com/view/23710.htm

 

2、WebSphere MQ的原理

    Websphere MQ是IBM的商業通信中間件(Commercial Messaging Middleware)。Websphere MQ提供一個具備工業標準、安全、可靠的消息傳輸系統。它的功能是控制和管理一個集成的商業應用，使得組成這個商業應用的多個分支程序(模塊)之間經過傳遞消息完成整個工做流程。Websphere MQ基本由一個消息傳輸系統和一個應用程序接口組成，其資源是消息和隊列(Messagingand Queuing)。

消息：消息就是一個信息單元，這個信息單元能夠是一個請求（Request message），也能夠是一個應答(Reply message)，或者是一個報告(Report message)或一份報文(Datagram   messge)。一個消息包含兩個因素——消息描述(用於定義諸如消息傳輸目標等)和數據消息(如應用程序數據或數據庫查詢等)。程序之間的通訊經過傳遞消息而非直接調用程序。

隊列:一個安全的存儲消息的地方，消息的存儲通常是順序的，隊列是消息分階段地傳送和接收。由於消息存放在隊列中，因此應用程序能夠相互獨立的運行，以不一樣的速度，在不一樣的時間，在不一樣的地點。

消息傳輸系統：用於確保隊列之間的消息提供，包括網絡中不一樣系統上的遠程隊列之間的消息提供。並保證網絡故障或關閉後的恢復。

應用程序接口：應用程序和消息系統之間經過Websphere MQ API實現的接口Websphere MQ API在全部Websphere MQ平臺上是一致的。API只有14個調用，2個關鍵動詞：發送(PUT)和接收(GET)。

3、WebSphere MQ的重要特色

3.1 統一接口

跨越IBM和非IBM平臺。簡單的PUT和GET動詞在WebSphere MQ支持35種IBM和非IBM平臺上徹底相同。使得WebSphere MQ提供了這樣的特性：目標應用程序位置的透明性(targetapplicationlocationtransparency)。對於一個應用程序的開發者，他須要知道的所有隻是隊列的名字，這個隊列與一個特定的服務有關，而與系統的平臺或系統在什麼地方無關。

使開發人員避開網絡的複雜性。由於WebSphere MQ負責處理全部的通信，開發人員沒必要編寫任何通信方面的程序。而且編程和調試很是簡單和直接，不須要具體的系統和通信方面的知識。尤爲在開發客戶機/服務器模式的應用時，開發人員能夠集中精力在與業務有關的客戶端和服務器端的應用，而沒必要考慮操做系統和通信，特別是底層的網絡通信，節省大約50%到75%of通信編程工做。

 

3.2  處理不依賴時間的限制

意思是說在信息建立和發送時，信息的接收方或到接收方的通道不須要激活.不受時間的限制增長了處理的靈活性，容許事務處理在它們想作或有時間作時。彼此通信程序能夠運行在不一樣的時間。這樣程序的運行是獨立的，若是邏輯容許，它們沒必要等待其它程序的應答而繼續工做,利用這種異步處理功能，能夠更有效的使用資源，更靈活的處理模式，應用處理能夠是獨立的，並行的，重疊的，從而改進用戶服務。

 

3.3 給分佈式處理提供的強健的中間件

包括邏輯工做單元支持(logicalunitofwork),備份和恢復機制，大信息傳遞和高性能等特色。其中最重要的是確保信息傳輸，意思是一旦WebSphere MQ接受一個信息傳輸的任務,會確保信息被傳送到目標平臺。信息的傳輸是一次且僅一次.另外，強健的中間件機制保證業務數據一致性，並可在系統發生故障時，及時恢復，業務不會受到影響。

4、MQ的基本概念

4.1 WebSphere MQ對象(objects)

    WebSphere MQ對象是一種由WebSphere MQ管理的具備可恢復能力的資源。

    隊列管理器（Queue managers）

    隊列（Queues）

    名字列表（Namelists）

    分發列表（Distribution lists）

     進程定義（Process definitions）

    通道（Channels）

    存儲類（Storage classes）

    這些對象在異種平臺上都是統一的。對於系統管理員來講，操縱對象的命令都是可用的。這些命令格式，對於不一樣平臺是有區別的。當你建立隊列管理器時，會自動地建立缺省對象。這些缺省對象能夠幫助您來定義所需的對象。

       每個對象都有一個名字，以便經過命令和MQI調用能夠引用它。一般在這些對象類型中的每一種對象的名字必須惟一。例如，一個隊列和一個進程的名字能夠相同，可是不能夠有兩個相同名字的隊列。這意味着一個本地隊列名不能和模板隊列、遠程隊列或別名隊列相同。可是也會有些特殊狀況。另外在互連的隊列管理器網絡中，隊列管理器名必須惟一。

       WebSphereMQ的對象名是大小寫敏感的，所以在定義對象時，須要仔細選擇好大小寫字母。在 WebSphere MQ 中，除最多有 20 個字符的通道以外，名稱最多能夠有 48 個字符。

 

4.2 消息

    消息是對使用它的應用程序有意義的以字節爲單位的字符串。消息能夠用來實如今相同或不一樣平臺上應用程序間的通訊。

WebSphere MQ 消息由兩個部分：

應用程序數據。 
    應用程序數據的內容和結構由使用它的應用程序定義。

消息描述符。 
    消息描述符標識消息，幷包含其它控制信息，如消息類型和消息的優先級，消息描述符的格式由 WebSphere MQ 定義。

WebSphere MQ定義了四種基本類型的消息。應用程序能夠定義其餘類型的消息。四種基本類型是：

請求消息 Request message

    請求消息須要應答。從客戶端發往服務器的查詢和更新信息每每是一條請求消息。請求消息中應該包含回覆消息的路由信息，即回覆消息發往什麼地方。

回覆消息 Reply message

    回覆消息是對請求消息的迴應。請求消息中的信息決定了迴應消息的目的地。處理請求和迴應的應用程序控制着消息間的關聯，這種關聯和隊列管理器沒有關係。消息自身帶有足夠的信息供應用程序實現這種關聯。

報文消息 Datagram message

    數據報消息是不須要回復的消息，報文消息只是一次單向的信息傳送。

報告消息 Report message。

    報告消息用於對一些系統故障的響應。有些報告消息是由應用程序建立的，有些報告消息是由隊列管理器建立的。後一種狀況是因爲遠程隊列已經滿或者遠程隊列不存在引發消息不能正確發送。最初發送這條消息的應用程序不能檢測到這種錯誤，只有等遠程隊列管理器建立了這樣一條報告消息併發往本地隊列管理器以後，應用程序才能做相應的處理。

    隊列管理器把報告消息也用於其餘目的，好比報告一些事件。消息可能有一個失效時間限制。若是一條消息在失效時間事後尚未被某個應用程序處理，該條消息將被隊列管理器從系統中清除。當隊列管理器清除一條失效消息以後，它將建立一條報告消息，這條報告消息的目的地址由失效消息提供。

    報告消息的另外一個用途是確保消息的到達。應用程序能夠要求它們所發送的消息到達目的地後，他們收到一條報告消息，這叫作接收確認（Confirmation of arrival）。與此相相似，應用程序也能夠要求當另一個程序取走這條消息時它們收到一條報告消息，這被叫作交付確認（Confirmation of delivery）。這兩種狀況，都是由隊列管理器建立報告消息，並把報告消息發送到適當地目的地。

    另外還一類特殊的消息叫觸發消息。觸發消息是由隊列管理器建立的一類特殊消息。WebSphere MQ的隊列管理器提供了一種當知足某一條件時，自動觸發應用程序的機制，而觸發消息是觸發機制的重要組成部分。

    應用程序也能夠定義新的消息類型。隊列管理器不能解釋這些類型，應用程序設置的消息類型由一個範圍。這些類型值可用來區分不一樣類型的應用程序在同一個輸入隊列中放入的消息。

消息長度

最大消息長度爲 100 MB（其中 1 MB 等於 1 048 576 字節），缺省最大消息長度是 4 MB。實際上，消息長度受如下方面的影響：

• 接收隊列定義的最大消息長度
• 隊列管理器定義的最大消息長度
• 傳輸隊列定義的最大消息長度
• 發送或接收應用程序定義的最大消息長度
• 存儲消息的可用空間

因此有時可能須要由多個消息組成的信息才能知足應用程序的要求。

4.3  隊列
隊列是用於存儲消息的數據結構,目前WebSphere MQ 版本 5.3 支持超過 2 GB 大小的隊列。

4.3.1 隊列的類型

按建立方法分類

• 預約義隊列由管理員使用相應的 MQSC 或 PCF 命令建立。 預約義隊列是永久的；它們的存在與應用程序是否使用它們無關，而且 WebSphere MQ 從新啓動後繼續存在。
• 動態隊列在應用程序發出設定模型隊列名的MQOPEN調用時建立的。被建立的隊列是基於一個模板隊列。 您可使用 MQSC 命令 DEFINE QMODEL 建立模板隊列。動態隊列繼承了模板隊列的屬性。模板隊列有一個屬性能夠說明動態隊列是永久的仍是臨時的。永久隊列在應用程序和隊列管理器從新啓動後繼續存在；臨時隊列在從新啓動後消失。

按功能分類

1.        本地隊列（local queue）：

    一個本地隊列是一個物理上位於本地隊列管理器中的隊列。本地隊列實際上存在與本地系統的內存或磁盤存儲終。本地隊列管理器控制隊列的訪問。應用程序能夠「PUT」消息到本地隊列，也能夠從本地隊列「GET」消息，另外程序還能夠查詢或修改這些隊列的某些屬性。對隊列屬性的修改須要相應的權限。

2.        遠程隊列（remote queue）：

     一個遠程隊列屬於一個不與該應用程序直接相連的隊列管理器。對這類隊列的訪問包含有本地隊列管理器和遠程隊列管理器的通訊過程。這種通訊涉及到通道。 應用程序可對遠程隊列進行某些操做，好比程序能夠向一個遠程隊列放一條消息，但程序不能從遠程隊列中去消息。應用程序只能從本地隊列讀取消息。

     應用程序有兩種不一樣的方法可用來訪問遠程隊列。第一種是當程序打開一個遠程隊列時同時提供隊列管理器名和隊列名兩個參數。這要求程序知道目的隊列屬於哪一個隊列管理器。第二種方法是在本地隊列管理器上存在一個遠程隊列的定義，這個定義包含有足夠的信息讓本地隊列管理器肯定該遠程隊列所在的隊列管理器。遠程隊列定義中的目的隊列不必定是遠程隊列管理器的本地隊列，它也能夠是一個遠程隊列定義。(這就話和以後的網關隊列管理器的建立有關係)

    應用程序放一條消息到Q1，Q1是本地隊列管理器QM1上的一個遠程隊列定義：Q2at QM2。QM2是遠程隊列管理器。Q2是QM2上的一個遠程隊列定義Q3 at QM3。Q3是QM3的一個本地隊列，通過兩次傳送，消息最終到達Q3這個QM3的本地隊列。

    有多種緣由使這種多跳（Multihop）傳送變得有意義。在一個TCP/IP網絡內部，全部機器都有IP地址，IP協議自己處理節點間的路由選擇。但假設消息須要穿過不一樣類型的網絡，這就須要中間件參加路由選擇。在圖中，QM2位於一臺鏈接TCP/IP網和SNA網的機器上，只需在QM2上提供一個遠程隊列定義Q2：Q3 at QM3，就能夠實現消息的跨網絡傳輸。

    由於對遠程隊列的訪問老是涉及到隊列管理器之間的通訊，於是咱們須要定義其餘一些資源，好比通道、傳輸隊列（Transmission queue）。

3.        傳輸隊列(Transmission queue)：

    傳輸隊列是臨時存儲目標爲遠程隊列管理器的消息的隊列。隊列管理器利用傳輸隊列把消息分階段地發向遠程隊列。隊列管理器和消息移動程序一塊兒負責把數據傳送到遠程隊列。當隊列管理器收到把一條消息發往遠程隊列的要求後，它把消息發送到一個與目的隊列管理器相關聯的傳輸隊列，傳輸隊列位於本地隊列管理器上。目的隊列管理器的名稱可能由應用程序提供，也能夠從遠程隊列定義中獲得。

     一個傳輸隊列是兩個隊列管理器之間的鏈接的一端。全部直接目的地是同一隊列管理器的消息均可放在同一個傳輸隊列上，這些消息的最終目的可能不同。把消息從一個隊列管理器傳送到另外一個隊列管理器只須要一個傳輸隊列，然而也有可能在兩個隊列管理器之間存在着多個鏈接以提供不一樣的傳輸服務，每一個鏈接都帶有一個不一樣的傳輸隊列。

     傳輸隊列是由MCA處理的，MCA負責在隊列管理器之間可靠地傳送消息。MCA其實是處理傳輸隊列上消息的MQI應用程序。

4.        動態隊列和模板隊列：

    除了有固定定義的隊列以外，WebSphere MQ還爲程序在它們執行時提供了動態地建立隊列的能力。例如,一個應用程序做爲某種服務的客戶，它可能建立一個動態隊列，並通知服務器把對服務要求的響應發送到該動態隊列。固然，這種狀況也可使用具備永久定義的隊列。爲了簡化在建立動態隊列時所必需設置的許多參數，動態隊列老是基於模板隊列被建立的，模板隊列定義了動態隊列的全部屬性。當應用程序試圖打開一個模板隊列時，WebSphere MQ就建立一個動態隊列。WebSphere MQ爲應用提供了系統模板隊列。

    動態隊列也能夠分紅兩種，它們的生存週期和故障恢復特性不一樣。在建立臨時動態隊列（Temorary dynamic queue）的應用程序關閉時，這些隊列將被刪除，隊列上的消息將丟失。這類動態隊列不支持消息的持久性。若是隊列管理器發生故障從新啓動，臨時動態隊列也不會被恢復。另外一種動態隊列是持久動態隊列（Permanent dynamic queue）。只有當一個應用程序關閉持久動態隊列時定義刪除選項，持久動態隊列纔會被刪除。刪除持久動態隊列的程序不必定是建立持久動態隊列的程序，持久動態隊列在隊列管理器重啓後會被恢復，而且支持具備持久性的消息。

5.        啓動隊列

    啓動隊列是在觸發中使用的隊列。若是隊列管理器將使用觸發，則必須至少爲此隊列管理器定義一個啓動隊列。隊列管理器在觸發器事件發生時將觸發器消息放入啓動隊列。觸發器事件是由隊列管理器檢測的條件的邏輯組合。例如，當隊列上的消息數達到預約義深度時，可能會生成觸發器事件。此事件使隊列管理器將觸發器消息放入指定的啓動隊列。此觸發器消息由觸發器監視器（即監視啓動隊列的特殊應用程序）檢索。而後觸發器監視器啓動在觸發器消息中指定的應用程序。

6.        羣集傳輸隊列

    每一個在羣集中的隊列管理器有一個稱爲 SYSTEM.CLUSTER.TRANSMIT.QUEUE 的羣集傳輸隊列。當您定義隊列管理器時，按缺省狀況建立此隊列的定義。做爲羣集一部分的隊列管理器能夠將羣集傳輸隊列上的消息發送到在同一羣集中的任何其它隊列管理器。 在路由解析期間，羣集傳輸隊列優先於缺省傳輸隊列。 當隊列管理器是羣集的一部分時，缺省操做是使用 SYSTEM.CLUSTER.TRANSMIT.QUEUE，除非當目標隊列管理器不是此羣集的一部分。

7.        死信隊列 （Dead letter queue）

    死信（未傳遞的消息）隊列是存儲沒法發送到其正確目的地的消息的隊列。有時候會出現隊列管理器不能把消息發送到目的地的狀況，此時消息將被髮送到某個死信隊列中。死信隊列中的消息經常暗示了系統可能出現的問題。例如當一條消息到達目的隊列管理器以後卻發現目的隊列並不存在。或者目的隊列出現不能接收信消息的狀況，好比目的隊列已經滿了，或者它被設置成不容許再加入新的消息。並非全部的放消息操做的失敗都致使消息被放入死信隊列，例如，因爲本地隊列出現錯誤形成應用程序不能「放」消息，此時MQI調用直接把錯誤碼返回給應用程序。

    有些錯誤只能由死信隊列報告，例如，一條消息穿越網絡以後到達目的隊列管理器，卻發現目的隊列已滿。發現錯誤的機器不一樣於最初「放」消息應用程序所在的機器，甚至可能放消息的應用程序已不在運行狀態。此時目的隊列管理器把這條消息發往它所擁有的死信隊列，而不是簡單地扔掉該條消息。這樣使得此次錯誤是可見的，也給應用程序提供了一個改正錯誤的機會。

     死信隊列是WebSphere MQ面對遠端系統錯誤時的一種解決方案。應用程序能夠利用WebSphere MQ提供的其餘一些工具來監視並確保消息的可靠傳送和接收。

    在隊列管理器建立時，系統會缺省建立一個死信隊列，隊列名是SYSTEM.DEAD.LETTER.QUEUE。建議在生產系統上，須要獨立建立一個死信隊列，而不使用系統缺省的死信隊列。

8.        命令隊列

    命令隊列 SYSTEM.ADMIN.COMMAND.QUEUE 是用來存放由應用管理程序放的具備PCF（programcommand format）的消息的隊列。該隊列主要用於編寫管理程序時使用。具體的使用將在後續章節介紹。在建立隊列管理器時將爲每一個隊列管理器自動建立命令隊列。

9.        回覆隊列

    當應用程序發送請求消息時，接收消息的應用程序能夠將回復消息發送給發送應用程序。此回覆消息放入一個稱爲回覆隊列的隊列中，它一般是發送應用程序的本地隊列。回覆隊列的名稱由做爲消息描述符一部分的發送應用程序指定。

10.        別名隊列

       別名隊列其實是本地隊列、遠程隊列定義或隊列名錶的另一個名字。它是一種簡單的名字到名字的映射，它容許應用程序用另一個名字來訪問隊列。WebSphere MQ已經爲應用程序屏蔽了許多底層系統細節，特別是網絡通訊的細節，而別名隊列容許在不修改應用程序的條件下訪問其餘名字的隊列。

4.4 隊列管理器

    在WebSphere MQ中隊列管理器是基本的軟件系統，隊列管理器可當作是隊列和其餘對象的容器。WebSphere MQ中的每個隊列都屬於一個隊列管理器，隊列管理器是爲應用程序和WebSphere MQ部件（一些管理工具）提供對隊列管理中對象的訪問。

    一個隊列管理器是WebSphere MQ中的一個基本的獨立的執行單元。一臺機器上能夠運行一個或多個隊列管理器。

    任何須要訪問WebSphere MQ提供的服務的應用程序都必須先和隊列管理器相連，和應用程序相連的隊列管理器對該應用程序而言就叫「本地隊列管理器」（Local Queue Manager）,本地隊列管理器爲程序提供MQI調用的支持。應用程序能夠操做、管理本地隊列管理器所擁有的各類資源，也能夠向其餘的隊列管理器發送消息。

    應用程序經過一種叫作MQI的編程接口向隊列管理器申請服務。這些服務包括「放」一條消息到隊列或從隊列「取」一條消息等一些基本操做。隊列管理器還使隊列成爲可靠的存儲消息的地方，它也控制安全性管理，並提供一些特殊的隊列功能，好比觸發隊列。

    爲了減小應用程序對於它所運行環境的依賴性，WebSphere MQ的應用程序能夠和一個它不知道名字的隊列管理器相連，這個隊列管理器就是一臺機器上的缺省隊列管理器。若是程序在調用MQCONN時，把隊列管理器名參數設置爲空，MQCONN將返回與缺省的隊列管理器鏈接的句柄。

    隊列管理器擁有每一個隊列。隊列管理器負責維護它所擁有的隊列，以及將它接收到的全部消息存儲到相應的隊列。能夠由應用程序或隊列管理器將消息放入隊列，這些是它的正常操做的一部分。

4.5 通道

消息通道（Message channels）

    消息通道是一種提供從一個隊列管理器到另外一個隊列管理器的通訊路徑。消息通道用在分佈式的隊列把消息從一個隊列管理器發送到另外一個隊列管理器。它們使應用程序屏蔽了底層的通訊協議。隊列管理器可能存在同種或異種平臺之間。爲了實現隊列管理器之間的通訊，您必需在一個隊列管理器中定義一個發送消息的通道對象，在另外一個隊列管理器中定義一個接收消息的通道對象。消息通道是一個單向連接。它經過消息通道代理（message channel agents）把兩個隊列管理器鏈接起來。

消息通道的定義能夠分爲如下6種類型：

     發送通道（Sender）

     接收通道（Receiver）

     服務器通道（Server）

     請求器通道（Requester）

     羣集發送通道（Cluster sender）

     羣集接收通道（Cluster receiver）

消息通道的組合形式

若是要在隊列管理之間實現消息傳輸，必需要在兩個隊列管理器上都要定義相應的通道。發送方和接收方通道的組合形式以下：

    發送通道-接收通道（Sender-receiver ）

    請求器通道-服務器通道（Requester-server）

    請求器通道-發送通道（Requester-sender (callback) ）

    服務器通道-接收通道（Server-receiver ）

    羣集發送通道-羣集接收通道（Cluster sender –cluster receiver）

消息通道用法

發送通道-接收通道（Sender-receiver）

用法：由一個系統的發送通道來啓動通道，以便它能夠發送消息到另外一個系統。發送通道向接收通道發送啓動請求。發送通道從傳輸隊列發送消息到接收通道。接收通道把消息放到目標隊列。

請求器通道-服務器通道（Requester-server）

用法：

(1)由一個系統中的請求器通道來啓動通道，以便它能從另外一個系統接收到消息。 請求器通道向通道另外一端的服務器通道發送請求來啓動。服務器通道從傳輸隊列把消息發送到請求器通道。

(2) 服務器通道也能啓動通道，併發送消息到請求器, 但這僅應用於徹底意義的服務器通道, 也即服務器通道定義中應含有對方的鏈接名。一個徹底意義的服務器通道能夠由請求器通道啓動, 也能夠發起和服務器通道的通信。

(3) 最好不要手工去中止Server和Request通道，而是依靠Server通道的Discint的屬性來中止通道。

請求器通道-發送通道（Requester-sender (callback)

用法：請求器通道啓動通道，發送通道終止這個會話。發送通道而後依據它的通道定義中的信息(稱爲 callback)來從新啓動會話。它把消息從傳輸隊列發送給請求器通道。最好不要手工去中止Sender和Request通道，而是依靠Sender 通道的Discint屬性來中止通道。

 

服務器通道-接收通道（Server-receiver）

用法：相似於發送通道

羣集發送通道（Cluster sender）

用法：在一個羣集中，每一個隊列管理器都有一個羣集發送通道，經過它能夠把送羣集信息發送到其中一個隊列管理器資源管理器。 隊列管理器經過這個通道也能夠把消息發送到其餘的隊列管理器。

集接收通道（cluster receiver）

功能：在一個羣集中，每個隊列管理器都有一個羣集接收通道。經過這個通道能夠接收數據消息和關於羣集的消息。

MQI通道

       MQI通道是WebSphere MQ 客戶端和服務器上的隊列管理器的通訊的通道。當客戶端應用程序發出MQCONN或MQCONNX調用時，纔開始創建鏈接。它是一個雙向的通道，能夠負責發送和接收，被用做MQI調用的傳送和響應。一個MQI通道能夠把一個客戶端鏈接到單個隊列管理器，MQI通道有兩種類型，它們定義了雙向的MQI通道。