一、中間件
MQ是一種中間件產品，至於什么是中間件，中間件能干什么，參見以下鏈接:
http://baike.baidu.com/view/23710.htm
二、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)。三、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接受一個信息傳輸的任務,會確保信息被傳送到目標平台。信息的傳輸是一次且僅一次.另外，強健的中間件機制保證業務數據一致性，並可在系統發生故障時，及時恢復，業務不會受到影響。
四、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）
功能：在一個群集中，每一個隊列管理器都有一個群集接收通道。通過這個通道可以接收數據消息和關於群集的消息。