MQ的基本概念

本篇內容介紹了“MQ的基本概念”的有關(guān)知識，在實(shí)際案例的操作過(guò)程中，不少人都會(huì )遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學(xué)有所成！

對象(objects)

       WebSphereMQ對象是一種由WebSphereMQ管理的具有可恢復能力的資源。

 隊列管理器（Queue managers）

隊列（Queues）

名字列表（Namelists）

分發(fā)列表（Distribution lists）

進(jìn)程定義（Process definitions）

通道（Channels）

存儲類(lèi)（Storage classes）

 這些對象在異種平臺上都是統一的。對于系統管理員來(lái)說(shuō)，操縱對象的命令都是可用的。這些命令格式，對于不同平臺是有區別的。當你創(chuàng )建隊列管理器時(shí)，會(huì )自動(dòng)地創(chuàng )建缺省對象。這些缺省對象可以幫助您來(lái)定義所需的對象。

       每一個(gè)對象都有一個(gè)名字，以便通過(guò)命令和MQI調用可以引用它。通常在這些對象類(lèi)型中的每一種對象的名字必須唯一。例如，一個(gè)隊列和一個(gè)進(jìn)程的名字可以相同，但是不可以有兩個(gè)相同名字的隊列。這意味著(zhù)一個(gè)本地隊列名不能和模板隊列、遠程隊列或別名隊列相同。但是也會(huì )有些特殊情況。另外在互連的隊列管理器網(wǎng)絡(luò )中，隊列管理器名必須唯一。

       WebSphereMQ的對象名是大小寫(xiě)敏感的，因此在定義對象時(shí)，需要仔細選擇好大小寫(xiě)字母。在 WebSphere MQ 中，除最多有 20 個(gè)字符的通道之外，名稱(chēng)最多可以有 48 個(gè)字符。

消息

消息的類(lèi)型

       WebSphereMQ定義了四種基本類(lèi)型的消息。應用程序可以定義其他類(lèi)型的消息。四種基本類(lèi)型是：

1.請求消息 Request message

請求消息需要應答。從客戶(hù)端發(fā)往的查詢(xún)和更新信息往往是一條請求消息。請求消息中應該包含回復消息的路由信息，即回復消息發(fā)往什么地方。

2. 回復消息 Reply message

回復消息是對請求消息的回應。請求消息中的信息決定了回應消息的目的地。處理請求和回應的應用程序控制著(zhù)消息間的關(guān)聯(lián)，這種關(guān)聯(lián)和隊列管理器沒(méi)有關(guān)系。消息自身帶有足夠的信息供應用程序實(shí)現這種關(guān)聯(lián)。

3.報文消息 Datagram message

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

4.報告消息 Report message。

報告消息用于對一些系統故障的響應。有些報告消息是由應用程序創(chuàng )建的，有些報告消息是由隊列管理器創(chuàng )建的。后一種情況是由于遠程隊列已經(jīng)滿(mǎn)或者遠程隊列不存在引起消息不能正確發(fā)送。最初發(fā)送者條消息的應用程序不能檢測到這種錯誤，只有等遠程隊列管理器創(chuàng )建了這樣一條報告消息并發(fā)往本地隊列管理器之后，應用程序才能作相應的處理。

隊列管理器把報告消息也用于其他目的，比如報告一些事件。消息可能有一個(gè)失效時(shí)間限制。如果一條消息在失效時(shí)間過(guò)后還沒(méi)有被某個(gè)應用程序處理，該條消息將被隊列管理器從系統中清除。當隊列管理器清除一條失效消息之后，它將創(chuàng )建一條報告消息，這條報告消息的目的地址由失效消息提供。

報告消息的另一個(gè)用途是確保消息的到達。應用程序可以要求它們所發(fā)送的消息到達目的地后，他們收到一條報告消息，這叫做接收確認（Confirmation of arrival）。與此相類(lèi)似，應用程序也可以要求當另外一個(gè)程序取走這條消息時(shí)它們收到一條報告消息，這被叫做交付確認（Confirmation of delivery）。這兩種情況，都是由隊列管理器創(chuàng )建報告消息，并把報告消息發(fā)送到適當地目的地。

另外還一類(lèi)特殊的消息叫觸發(fā)消息。觸發(fā)消息是由隊列管理器創(chuàng )建的一類(lèi)特殊消息。WebSphere MQ的隊列管理器提供了一種當滿(mǎn)足某一條件時(shí)，自動(dòng)觸發(fā)應用程序的機制，而觸發(fā)消息是觸發(fā)機制的重要組成部分。

應用程序也可以定義新的消息類(lèi)型。隊列管理器不能解釋這些類(lèi)型，應用程序設置的消息類(lèi)型由一個(gè)范圍。這些類(lèi)型值可用來(lái)區分不同類(lèi)型的應用程序在同一個(gè)輸入隊列中放入的消息。

消息長(cháng)度

最大消息長(cháng)度為 100 MB（其中 1 MB 等于 1 048 576 字節），缺省最大消息長(cháng)度是 4 MB。實(shí)際上，消息長(cháng)度受以下方面的影響：

• 接收隊列定義的最大消息長(cháng)度

• 隊列管理器定義的最大消息長(cháng)度

• 傳輸隊列定義的最大消息長(cháng)度

• 發(fā)送或接收應用程序定義的最大消息長(cháng)度

• 存儲消息的可用空間

所以有時(shí)可能需要由多個(gè)消息組成的信息才能滿(mǎn)足應用程序的要求。

應用程序如何發(fā)送和接收消息？

應用程序使用 MQI 調用來(lái)實(shí)現發(fā)送和接收消息。

例如，要將消息放入隊列，應用程序：

1. 通過(guò)發(fā)出 MQI  MQOPEN 調用打開(kāi)所需的隊列

2. 發(fā)出 MQI  MQPUT 調用以將消息放入隊列

另一個(gè)應用程序可以通過(guò)發(fā)出MQI MQGET 調用，從同一隊列取出消息

隊列

隊列的類(lèi)型

按創(chuàng )建方法分類(lèi)

• 預定義隊列由管理員使用相應的 MQSC 或 PCF 命令創(chuàng )建。 預定義隊列是永久的；它們的存在與應用程序是否實(shí)用它們無(wú)關(guān)，并且 WebSphere MQ 重新啟動(dòng)后繼續存在。

• 動(dòng)態(tài)隊列在應用程序發(fā)出設定模型隊列名的MQOPEN調用時(shí)創(chuàng )建的。被創(chuàng )建的隊列是基于一個(gè)模板隊列。 您可以使用 MQSC 命令 DEFINE QMODEL 創(chuàng )建模板隊列。動(dòng)態(tài)隊列繼承了模板隊列的屬性。模板隊列有一個(gè)屬性可以說(shuō)明動(dòng)態(tài)隊列是永久的還是臨時(shí)的。永久隊列在應用程序和隊列管理器重新啟動(dòng)后繼續存在；臨時(shí)隊列在重新啟動(dòng)后消失。

按功能分類(lèi)

1.        本地隊列（local queue）：

一個(gè)本地隊列是一個(gè)物理上位于本地隊列管理器中的隊列。本地隊列實(shí)際上存在與本地系統的內存或磁盤(pán)存儲終。本地隊列管理器控制隊列的訪(fǎng)問(wèn)。

       應用程序可以“PUT”消息到本地隊列，也可以從本地隊列“GET”消息，另外程序還可以查詢(xún)或修改這些隊列的某些屬性。對隊列屬性的修改需要相應的權限。

2.        遠程隊列（remote queue）：

       一個(gè)遠程隊列屬于一個(gè)不與該應用程序直接相連的隊列管理器。對這類(lèi)隊列的訪(fǎng)問(wèn)包含有本地隊列管理器和遠程隊列管理器的通信過(guò)程。這種通信涉及到通道。

       應用程序可對遠程隊列進(jìn)行某些操作，比如程序可以向一個(gè)遠程隊列放一條消息，但程序不能從遠程隊列中去消息。應用程序只能從本地隊列讀取消息。

      應用程序有兩種不同的方法可用來(lái)訪(fǎng)問(wèn)遠程隊列。第一種是當程序打開(kāi)一個(gè)遠程隊列時(shí)同時(shí)提供隊列管理器名和隊列名兩個(gè)參數。這要求程序知道目的隊列屬于哪個(gè)隊列管理器。第二種方法是在本地隊列管理器上存在一個(gè)遠程隊列的定義，這個(gè)定義包含有足夠的信息讓本地隊列管理器確定該遠程隊列所在的隊列管理器。

       遠程隊列定義中的目的隊列不一定是遠程隊列管理器的本地隊列，它也可以是一個(gè)遠程隊列定義

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

       有多種原因使這種多跳（Multihop）傳送變得有意義。在一個(gè)TCP/IP網(wǎng)絡(luò )內部，所有機器都有IP地址，IP協(xié)議本身處理節點(diǎn)間的路由選擇。但假設消息需要穿過(guò)不同類(lèi)型的網(wǎng)絡(luò )，這就需要中間件參加路由選擇。在圖中，QM2位于一臺連接TCP/IP網(wǎng)和SNA網(wǎng)的機器上，只需在QM2上提供一個(gè)遠程隊列定義Q2：Q3 at QM3，就可以實(shí)現消息的跨網(wǎng)絡(luò )傳輸。

       因為對遠程隊列的訪(fǎng)問(wèn)總是涉及到隊列管理器之間的通信，因而我們需要定義其他一些資源，比如通道、傳輸隊列（Transmission queue）。

3.        傳輸隊列(Transmission queue)：

       傳輸隊列是臨時(shí)存儲目標為遠程隊列管理器的消息的隊列。隊列管理器利用傳輸隊列把消息分階段地發(fā)向遠程隊列。隊列管理器和消息移動(dòng)程序一起負責把數據傳送到遠程隊列。當隊列管理器收到把一條消息發(fā)往遠程隊列的要求后，它把消息發(fā)送到一個(gè)與目的隊列管理器相關(guān)聯(lián)的傳輸隊列，傳輸隊列位于本地隊列管理器上。目的隊列管理器的名稱(chēng)可能由應用程序提供，也可以從遠程隊列定義中得到。

       一個(gè)傳輸隊列是兩個(gè)隊列管理器之間的連接的一端。所有直接目的地是同一隊列管理器的消息都可放在同一個(gè)傳輸隊列上，這些消息的最終目的可能不一樣。把消息從一個(gè)隊列管理器傳送到另一個(gè)隊列管理器只需要一個(gè)傳輸隊列，然而也有可能在兩個(gè)隊列管理器之間存在著(zhù)多個(gè)連接以提供不同的傳輸服務(wù)，每個(gè)連接都帶有一個(gè)不同的傳輸隊列。

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

4.        動(dòng)態(tài)隊列和模板隊列：

除了有固定定義的隊列之外，WebSphere MQ還為程序在它們執行時(shí)提供了動(dòng)態(tài)地創(chuàng )建隊列的能力。例如,一個(gè)應用程序作為某種服務(wù)的客戶(hù)，它可能創(chuàng )建一個(gè)動(dòng)態(tài)隊列，并通知服務(wù)器把對服務(wù)要求的響應發(fā)送到該動(dòng)態(tài)隊列。當然，這種情況也可以使用具有永久定義的隊列。為了簡(jiǎn)化在創(chuàng )建動(dòng)態(tài)隊列時(shí)所必需設置的許多參數，動(dòng)態(tài)隊列總是基于模板隊列被創(chuàng )建的，模板隊列定義了動(dòng)態(tài)隊列的所有屬性。當應用程序試圖打開(kāi)一個(gè)模板隊列時(shí)，WebSphere MQ就創(chuàng )建一個(gè)動(dòng)態(tài)隊列。WebSphere MQ為應用提供了系統模板隊列。

動(dòng)態(tài)隊列也可以分成兩種，它們的生存周期和故障恢復特性不同。在創(chuàng )建臨時(shí)動(dòng)態(tài)隊列（Temorary dynamic queue）的應用程序關(guān)閉時(shí)，這些隊列將被刪除，隊列上的消息將丟失。這類(lèi)動(dòng)態(tài)隊列不支持消息的持久性。如果隊列管理器發(fā)生故障重新啟動(dòng)，臨時(shí)動(dòng)態(tài)隊列也不會(huì )被恢復。另一種動(dòng)態(tài)隊列是持久動(dòng)態(tài)隊列（Permanent dynamic queue）。只有當一個(gè)應用程序關(guān)閉持久動(dòng)態(tài)隊列時(shí)定義刪除選項，持久動(dòng)態(tài)隊列才會(huì )被刪除。刪除持久動(dòng)態(tài)隊列的程序不一定是創(chuàng )建持久動(dòng)態(tài)隊列的程序，持久動(dòng)態(tài)隊列在隊列管理器重啟后會(huì )被恢復，并且支持具有持久性的消息。

5.        啟動(dòng)隊列

啟動(dòng)隊列是在觸發(fā)中使用的隊列。如果隊列管理器將使用觸發(fā)，則必須至少為此隊列管理器定義一個(gè)啟動(dòng)隊列。隊列管理器在觸發(fā)器事件發(fā)生時(shí)將觸發(fā)器消息放入啟動(dòng)隊列。觸發(fā)器事件是由隊列管理器檢測的條件的邏輯組合。例如，當隊列上的消息數達到預定義深度時(shí)，可能會(huì )生成觸發(fā)器事件。此事件使隊列管理器將觸發(fā)器消息放入指定的啟動(dòng)隊列。此觸發(fā)器消息由觸發(fā)器監視器（即監視啟動(dòng)隊列的特殊應用程序）檢索。然后觸發(fā)器監視器啟動(dòng)在觸發(fā)器消息中指定的應用程序。

6.        群集傳輸隊列

每個(gè)在群集中的隊列管理器有一個(gè)稱(chēng)為 SYSTEM.CLUSTER.TRANSMIT.QUEUE 的群集傳輸隊列。當您定義隊列管理器時(shí)，按缺省情況創(chuàng )建此隊列的定義。作為群集一部分的隊列管理器可以將群集傳輸隊列上的消息發(fā)送到在同一群集中的任何其它隊列管理器。 在路由解析期間，群集傳輸隊列優(yōu)先于缺省傳輸隊列。 當隊列管理器是群集的一部分時(shí)，缺省操作是使用 SYSTEM.CLUSTER.TRANSMIT.QUEUE，除非當目標隊列管理器不是此群集的一部分。

7.        死信隊列 （Dead letter queue）

死信（未傳遞的消息）隊列是存儲無(wú)法發(fā)送到其正確目的地的消息的隊列。有時(shí)候會(huì )出現隊列管理器不能把消息發(fā)送到目的地的情況，此時(shí)消息將被發(fā)送到某個(gè)死信隊列中。死信隊列中的消息常常暗示了系統可能出現的問(wèn)題。例如當一條消息到達目的隊列管理器之后卻發(fā)現目的隊列并不存在?；蛘吣康年犃谐霈F不能接收信消息的情況，比如目的隊列已經(jīng)滿(mǎn)了，或者它被設置成不允許再加入新的消息。并不是所有的放消息操作的失敗都導致消息被放入死信隊列，例如，由于本地隊列出現錯誤造成應用程序不能“放”消息，此時(shí)MQI調用直接把錯誤碼返回給應用程序。

  有些錯誤只能由死信隊列報告，例如，一條消息穿越網(wǎng)絡(luò )之后到達目的隊列管理器，卻發(fā)現目的隊列已滿(mǎn)。發(fā)現錯誤的機器不同于最初“放”消息應用程序所在的機器，甚至可能放消息的應用程序已不在運行狀態(tài)。此時(shí)目的隊列管理器把這條消息發(fā)往它所擁有的死信隊列，而不是簡(jiǎn)單地扔掉該條消息。這樣使得這次錯誤是可見(jiàn)的，也給應用程序提供了一個(gè)改正錯誤的機會(huì )。

         死信隊列是WebSphere MQ面對遠端系統錯誤時(shí)的一種解決方案。應用程序可以利用WebSphere MQ提供的其他一些工具來(lái)監視并確保消息的可靠傳送和接收。

         在隊列管理器創(chuàng )建時(shí)，系統會(huì )缺省創(chuàng )建一個(gè)死信隊列，隊列名是SYSTEM.DEAD.LETTER.QUEUE。建議在生產(chǎn)系統上，需要獨立創(chuàng )建一個(gè)死信隊列，而不使用系統缺省的死信隊列。

8.        命令隊列

命令隊列 SYSTEM.ADMIN.COMMAND.QUEUE 是用來(lái)存放由應用管理程序放的具有PCF（programcommand format）的消息的隊列。該隊列主要用于編寫(xiě)管理程序時(shí)使用。具體的使用將在后續章節介紹。在創(chuàng )建隊列管理器時(shí)將為每個(gè)隊列管理器自動(dòng)創(chuàng )建命令隊列。

9.        回復隊列

當應用程序發(fā)送請求消息時(shí)，接收消息的應用程序可以將回復消息發(fā)送給發(fā)送應用程序。此回復消息放入一個(gè)稱(chēng)為回復隊列的隊列中，它通常是發(fā)送應用程序的本地隊列?；貜完犃械拿Q(chēng)由作為消息描述符一部分的發(fā)送應用程序指定。

10.    別名隊列

       別名隊列實(shí)際上是本地隊列、遠程隊列定義或隊列名表的另外一個(gè)名字。它是一種簡(jiǎn)單的名字到名字的映射，它允許應用程序用另外一個(gè)名字來(lái)訪(fǎng)問(wèn)隊列。WebSphere MQ已經(jīng)為應用程序屏蔽了許多底層系統細節，特別是網(wǎng)絡(luò )通信的細節，而別名隊列允許在不修改應用程序的條件下訪(fǎng)問(wèn)其他名字的隊列。

隊列管理器

在WebSphere MQ中隊列管理器是基本的軟件系統，隊列管理器可看成是隊列和其他對象的容器。WebSphere MQ中的每一個(gè)隊列都屬于一個(gè)隊列管理器，隊列管理器是為應用程序和WebSphere MQ部件（一些管理工具）提供對隊列管理中對象的訪(fǎng)問(wèn)。

一個(gè)隊列管理器是WebSphere MQ中的一個(gè)基本的獨立的執行單元。一臺機器上可以運行一個(gè)或多個(gè)隊列管理器。

任何需要訪(fǎng)問(wèn)WebSphere MQ提供的服務(wù)的應用程序都必須先和隊列管理器相連，和應用程序相連的隊列管理器對該應用程序而言就叫“本地隊列管理器”（Local Queue Manager）,本地隊列管理器為程序提供MQI調用的支持。應用程序可以操作、管理本地隊列管理器所擁有的各種資源，也可以向其他的隊列管理器發(fā)送消息。

應用程序通過(guò)一種叫做MQI的編程接口向隊列管理器申請服務(wù)。這些服務(wù)包括“放”一條消息到隊列或從隊列“取”一條消息等一些基本操作。隊列管理器還使隊列成為可靠的存儲消息的地方，它也控制安全性管理，并提供一些特殊的隊列功能，比如觸發(fā)隊列。

為了減少應用程序對于它所運行環(huán)境的依賴(lài)性，WebSphere MQ的應用程序可以和一個(gè)它不知道名字的隊列管理器相連，這個(gè)隊列管理器就是一臺機器上的缺省隊列管理器。如果程序在調用MQCONN時(shí)，把隊列管理器名參數設置為空，MQCONN將返回與缺省的隊列管理器連接的句柄。

隊列管理器擁有每個(gè)隊列。隊列管理器負責維護它所擁有的隊列，以及將它接收到的所有消息存儲到相應的隊列?？梢杂蓱贸绦蚧蜿犃泄芾砥鲗⑾⒎湃腙犃?，這些是它的正常操作的一部分。

通道

消息通道（Messagechannels）

消息通道是一種提供從一個(gè)隊列管理器到另一個(gè)隊列管理器的通信路徑。消息通道用在分布式的隊列把消息從一個(gè)隊列管理器發(fā)送到另一個(gè)隊列管理器。它們使應用程序屏蔽了底層的通信協(xié)議。隊列管理器可能存在同種或異種平臺之間。為了實(shí)現隊列管理器之間的通信，您必需在一個(gè)隊列管理器中定義一個(gè)發(fā)送消息的通道對象，在另一個(gè)隊列管理器中定義一個(gè)接收消息的通道對象。消息通道是一個(gè)單向鏈接。它通過(guò)消息通道代理（message channel agents）把兩個(gè)隊列管理器連接起來(lái)。 

不要和MQI通道（MQI channel）通道混淆。MQI通道有兩種類(lèi)型，分別是服務(wù)器連接（server-connection）和客戶(hù)器連接（client-connection）。

消息通道分類(lèi)

消息通道的定義可以分為以下6種類(lèi)型：

l  發(fā)送通道（Sender）

l  接收通道（Receiver）

l  服務(wù)器通道（Server）

l  請求器通道（Requester）

l  群集發(fā)送通道（Cluster sender）

l  群集接收通道（Cluster receiver）

消息通道的組合形式

如果要在隊列管理之間實(shí)現消息傳輸，必須要在兩個(gè)隊列管理器上都要定義相應的通道。發(fā)送方和接收方通道的組合形式如下：

l  發(fā)送通道-接收通道（Sender-receiver ）

l  請求器通道-服務(wù)器通道（Requester-server）

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

l  服務(wù)器通道-接收通道（Server-receiver ）

l  群集發(fā)送通道-群集接收通道（Cluster sender –cluster receiver）

注意：通道的組合形式有5種形式，每種組合方式是固定的，用戶(hù)不能隨意組合。每對通道的名稱(chēng)必需相同例如：在發(fā)送通道-接收通道組合中，發(fā)送通道名和接收通道名必須一致，否則通道將無(wú)法啟動(dòng)。

消息通道用法 發(fā)送通道-接收通道（Sender-receiver）

用法：由一個(gè)系統的發(fā)送通道來(lái)啟動(dòng)通道，以便它可以發(fā)送消息到另一個(gè)系統。發(fā)送通道向接收通道發(fā)送啟動(dòng)請求。發(fā)送通道從傳輸隊列發(fā)送消息到接收通道。接收通道把消息放到目標隊列。

請求器通道-服務(wù)器通道（Requester-server）

用法：

(1)由一個(gè)系統中的請求器通道來(lái)啟動(dòng)通道，以便它能從另一個(gè)系統接收到消息。 請求器通道向通道另一端的服務(wù)器通道發(fā)送請求來(lái)啟動(dòng)。服務(wù)器通道從傳輸隊列把消息發(fā)送到請求器通道。

(2) 服務(wù)器通道也能啟動(dòng)通道，并發(fā)送消息到請求器, 但這僅應用于完全意義的服務(wù)器通道, 也即服務(wù)器通道定義中應含有對方的連接名。一個(gè)完全意義的服務(wù)器通道可以由請求器通道啟動(dòng), 也可以發(fā)起和服務(wù)器通道的通訊。

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

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

用法：請求器通道啟動(dòng)通道，發(fā)送通道終止這個(gè)會(huì )話(huà)。發(fā)送通道然后依據它的通道定義中的信息(稱(chēng)為 callback)來(lái)重新啟動(dòng)會(huì )話(huà)。它把消息從傳輸隊列發(fā)送給請求器通道。最好不要手工去停止Sender和Request通道，而是依靠Sender 通道的Discint屬性來(lái)停止通道。

服務(wù)器通道-接收通道（Server-receiver）

用法：類(lèi)似于發(fā)送通道-接收通道，但僅應用在完全意義的服務(wù)器通道。也即服務(wù)器通道定義應含有對方的連接名，通道的啟動(dòng)方是服務(wù)器通道。

群集發(fā)送通道（Cluster sender）

用法：在一個(gè)群集中，每個(gè)隊列管理器都有一個(gè)群集發(fā)送通道，通過(guò)它可以把送群集信息發(fā)送到其中一個(gè)隊列管理器資源管理器。隊列管理器通過(guò)這個(gè)通道也可以把消息發(fā)送到其他的隊列管理器。

群集接收通道（cluster receiver）

功能：在一個(gè)群集中，每一個(gè)隊列管理器都有一個(gè)群集接收通道。通過(guò)這個(gè)通道可以接收數據消息和關(guān)于群集的消息。

MQI通道

       MQI通道是WebSphere MQ 客戶(hù)端和服務(wù)器上的隊列管理器的通信的通道。當客戶(hù)端應用程序發(fā)出MQCONN或MQCONNX調用時(shí)，才開(kāi)始建立連接。它是一個(gè)雙向的通道，可以負責發(fā)送和接收，被用作MQI調用的傳送和響應。

一個(gè)MQI通道可以把一個(gè)客戶(hù)端連接到單個(gè)隊列管理器，MQI通道有兩種類(lèi)型，它們定義了雙向的MQI通道。

客戶(hù)端連接通道（Client-connectionchannel）

這種類(lèi)型為WebSphereMQ 的客戶(hù)端所使用。

服務(wù)器連接通道（Server-connectionchannel）

這種類(lèi)型為運行隊列管理器的服務(wù)器端所使用，運行在WebSphere MQ 客戶(hù)端的應用程序將使用這種通道進(jìn)行通信。

比較消息通道和MQI通道

消息通道與MQI通道之間的區別可以從兩方面進(jìn)行比較：

l  MQI通道是雙向的：一個(gè)MQI通道可以被用來(lái)發(fā)送請求，也可用來(lái)接收響應。而消息通道則只能單向數據通信。如果要在兩個(gè)隊列管理器之間實(shí)現雙向通信，那么需要定義兩個(gè)消息通道，一個(gè)用來(lái)實(shí)現數據的發(fā)送，另一個(gè)用來(lái)實(shí)現數據的接收。

l  MQI通道的通信是同步的：當一個(gè)MQI請求從客戶(hù)端發(fā)送服務(wù)器端時(shí)，WebSphere MQ的客戶(hù)端在發(fā)送下一個(gè)請求之間必須要等待來(lái)自服務(wù)器端的響應。而消息通道，在通道中傳輸的消息是與時(shí)間無(wú)關(guān)的。大量的消息可以從一個(gè)隊列管理器發(fā)送到另一個(gè)隊列管理器，發(fā)送隊列管理器不必等待來(lái)自接收隊列管理器的任何響應。

進(jìn)程

進(jìn)程定義對象定義響應 WebSphere MQ 隊列管理器上的觸發(fā)器事件啟動(dòng)的應用程序。進(jìn)程定義屬性包含應用程序標識、應用程序類(lèi)型和特定于應用程序的數據。

群集

在使用分布式排隊的傳統 WebSphere MQ 網(wǎng)絡(luò )中，每個(gè)隊列管理器是獨立的。如果隊列管理器需要將消息發(fā)送到另一個(gè)隊列管理器，則它必須定義一個(gè)傳輸隊列、一個(gè)到遠程隊列管理器的通道，以及它要將消息發(fā)送到的每個(gè)隊列的遠程隊列定義。

群集是一組以隊列管理器可以在不需要傳輸隊列、通道和遠程隊列定義的情況下在單個(gè)網(wǎng)絡(luò )上彼此直接通信的方法設置的隊列管理器。

名稱(chēng)列表

名稱(chēng)列表是包含其它 WebSphere MQ 對象列表的 WebSphere MQ 對象。通常，應用程序（如觸發(fā)器監視器）使用名稱(chēng)列表，它們用于標識一組隊列。使用名稱(chēng)列表的優(yōu)點(diǎn)是它獨立于應用程序維護；可以在不停止任何使用它的應用程序的情況下更新它。并且，如果一個(gè)應用程序失敗，則名稱(chēng)列表不受影響，其它應用程序可以繼續使用它。

名稱(chēng)列表還與隊列管理器群集一起使用，以維護多個(gè) WebSphere MQ 對象引用的群集列表。

認證信息對象

隊列管理器認證信息對象（AUTHINFO）組成安全套接字層（SSL）安全性的WebSphere MQ 支持的部件。它提供使用LDAP 服務(wù)器檢查ssl/' target='_blank'>證書(shū)撤銷(xiāo)列表（CRL）所需的定義。CRL 允許認證中心取消不再可信的證書(shū)。

本書(shū)描述對認證信息對象使用setmqaut、dspmqaut、dmpmqaut、rcrmqobj、rcdmqimg 和 dspmqfls 命令。有關(guān) SSL 概述以及 AUTHINFO 的使用，請參閱 WebSphere MQ Security。

系統缺省對象

系統缺省對象是一組每次創(chuàng )建隊列管理器時(shí)自動(dòng)創(chuàng )建的對象定義。您可以復制和修改這些對象定義中的任何一個(gè)，以在安裝時(shí)用于應用程序。

缺省對象名具有項 SYSTEM.DEFAULT；例如，缺省本地隊列是 SYSTEM.DEFAULT.LOCAL.QUEUE，并且缺省接收方通道是 SYSTEM.DEFAULT.RECEIVER。您無(wú)法重命名這些對象；這些名稱(chēng)的缺省對象是必需的。

當您定義對象時(shí)，從相應的缺省對象復制您不明確指定的任何屬性。例如，如果您定義本地隊列，則從缺省隊列 SYSTEM.DEFAULT.LOCAL.QUEUE 獲取您未指定的那些屬性。

請參閱附錄1, "系統和缺省對象"以獲取有關(guān)系統缺省的更多信息。


MQI（message queue interface）

MQI(消息隊列接口)有下列組成部分：

l  函數接口：應用程序通過(guò)函數可以訪(fǎng)問(wèn)隊列管理器和它的部件。

l  數據結構：應用程序使用提供的數據接口來(lái)是實(shí)現把數據傳遞給隊列管理器，或從隊列管理器中獲得數據。

l  基本數據類(lèi)型：也是用來(lái)實(shí)現從隊列管理器傳遞數據，或從隊列管理器中獲得數據。

控制命令

       以下是每個(gè) WebSphere MQ 控制命令的參考信息：

舉例
1.  此命令創(chuàng )建一個(gè)稱(chēng)為 Paint.queue.manager 的缺省隊列管理器，創(chuàng )建系統和缺省對象，并請求兩個(gè)主日志文件和三個(gè)次日志文件：

crtmqm -c"Paint shop" -ll -lp 2 -ls 3 -q Paint.queue.manager

2. 下列命令刪除隊列管理器 travel 并且也抑制任何由該命令發(fā)出的消息。

dltmqm -z travel

3. 此命令立即結束名為 saturn.queue.manager 的隊列管理器。完成所有當前 MQI 調用，但不允許新的調用。

endmqm -isaturn.queue.manager