ibmMQ--第一部分第二章

第二章Websphere MQ體系結構
目標
4,	瞭解WebSphere MQ的對象。
5,	描述WebSphere MQ的體系結構。
6,	學習WebSphere MQ的客戶機和服務器。
7,	理解WebSphere MQ的觸發機制。
8,	學習使用WebSphere MQ的隊列管理器羣集。
2.1基本概念
2.1.1 WebSphere MQ對象(objects)
	WebSphere MQ對象是一種由WebSphere MQ管理的具有可恢復能力的資源。在本書中描述的許多任務都和下列對象相關:
	隊列管理器(Queue managers)
	隊列(Queues)
	名字列表(Namelists)
	分發列表(Distribution lists)
	進程定義(Process definitions)
	通道(Channels)
	存儲類(Storage classes)

這些對象在異種平臺上都是統一的。對於系統管理員來說,操縱對象的命令都是可用的。這些命令格式,對於不同平臺是有區別的。當你創建隊列管理器時,會自動地創建缺省對象。這些缺省對象可以幫助您來定義所需的對象。
	每一個對象都有一個名字,以便通過命令和MQI調用可以引用它。通常在這些對象類型中的每一種對象的名字必須唯一。例如,一個隊列和一個進程的名字可以相同,但是不可以有兩個相同名字的隊列。這意味着一個本地隊列名不能和模板隊列、遠程隊列或別名隊列相同。但是也會有些特殊情況。另外在互連的隊列管理器網絡中,隊列管理器名必須唯一。
	WebSphere MQ的對象名是大小寫敏感的,因此在定義對象時,需要仔細選擇好大小寫字母。在 WebSphere MQ 中,除最多有 20 個字符的通道之外,名稱最多可以有 48 個字符。

2.1.2 消息
消息是對使用它的應用程序有意義的以字節爲單位的字符串。消息可以用來實現在相同或不同平臺上應用程序間的通信。 
WebSphere MQ 消息由兩個部分: 
應用程序數據。 
應用程序數據的內容和結構由使用它的應用程序定義。 
消息描述符。 
消息描述符標識消息,幷包含其它控制信息,如消息類型和消息的優先級,如圖所示:

 
圖,消息結構

消息描述符的格式由 WebSphere MQ 定義。有關消息描述符的完整描述,參看《WebSphere MQApplication Programming Reference》。
2.1.2.1消息的類型
	WebSphere MQ定義了四種基本類型的消息。應用程序可以定義其他類型的消息。四種基本類型是:
	請求消息 Request message
請求消息需要應答。從客戶端發往服務器的查詢和更新信息往往是一條請求消息。請求消息中應該包含回覆消息的路由信息,即回覆消息發往什麼地方。
	回覆消息 Reply message
回覆消息是對請求消息的迴應。請求消息中的信息決定了迴應消息的目的地。處理請求和迴應的應用程序控制着消息間的關聯,這種關聯和隊列管理器沒有關係。消息自身帶有足夠的信息供應用程序實現這種關聯。
	報文消息 Datagram message
數據報消息是不需要回復的消息,報文消息只是一次單向的信息傳送。
	報告消息 Report message。
報告消息用於對一些系統故障的響應。有些報告消息是由應用程序創建的,有些報告消息是由隊列管理器創建的。後一種情況是由於遠程隊列已經滿或者遠程隊列不存在引起消息不能正確發送。最初發送者條消息的應用程序不能檢測到這種錯誤,只有等遠程隊列管理器創建了這樣一條報告消息併發往本地隊列管理器之後,應用程序才能作相應的處理。
隊列管理器把報告消息也用於其他目的,比如報告一些事件。消息可能有一個失效時間限制。如果一條消息在失效時間過後還沒有被某個應用程序處理,該條消息將被隊列管理器從系統中清除。當隊列管理器清除一條失效消息之後,它將創建一條報告消息,這條報告消息的目的地址由失效消息提供。
報告消息的另一個用途是確保消息的到達。應用程序可以要求它們所發送的消息到達目的地後,他們收到一條報告消息,這叫做接收確認(Confirmation of arrival)。與此相類似,應用程序也可以要求當另外一個程序取走這條消息時它們收到一條報告消息,這被叫做交付確認(Confirmation of delivery)。這兩種情況,都是由隊列管理器創建報告消息,並把報告消息發送到適當地目的地。
另外還一類特殊的消息叫觸發消息。觸發消息是由隊列管理器創建的一類特殊消息。WebSphere MQ的隊列管理器提供了一種當滿足某一條件時,自動觸發應用程序的機制,而觸發消息是觸發機制的重要組成部分。

應用程序也可以定義新的消息類型。隊列管理器不能解釋這些類型,應用程序設置的消息類型由一個範圍。這些類型值可用來區分不同類型的應用程序在同一個輸入隊列中放入的消息。
	
2.1.2.2消息長度
最大消息長度爲 100 MB(其中 1 MB 等於 1 048 576 字節),缺省最大消息長度是 4 MB。實際上,消息長度受以下方面的影響: 
•	接收隊列定義的最大消息長度 
•	隊列管理器定義的最大消息長度 
•	傳輸隊列定義的最大消息長度 
•	發送或接收應用程序定義的最大消息長度 
•	存儲消息的可用空間
所以有時可能需要由多個消息組成的信息才能滿足應用程序的要求。
2.1.2.3應用程序如何發送和接收消息?
應用程序使用 MQI 調用來實現發送和接收消息。 
例如,要將消息放入隊列,應用程序: 
1.	通過發出 MQI  MQOPEN 調用打開所需的隊列 
2.	發出 MQI  MQPUT 調用以將消息放入隊列 
另一個應用程序可以通過發出 MQI MQGET 調用,從同一隊列取出消息
2.1.3 隊列
隊列是用於存儲消息的數據結構,目前WebSphere MQ 版本 5.3 支持超過 2 GB 大小的隊列。
2.1.3.1隊列的類型
按創建方法分類
•	預定義隊列由管理員使用相應的 MQSC 或 PCF 命令創建。 預定義隊列是永久的;它們的存在與應用程序是否實用它們無關,並且 WebSphere MQ 重新啓動後繼續存在。 
•	動態隊列在應用程序發出設定模型隊列名的MQOPEN調用時創建的。被創建的隊列是基於一個模板隊列。 您可以使用 MQSC 命令 DEFINE QMODEL 創建模板隊列。動態隊列繼承了模板隊列的屬性。模板隊列有一個屬性可以說明動態隊列是永久的還是臨時的。永久隊列在應用程序和隊列管理器重新啓動後繼續存在;臨時隊列在重新啓動後消失。
按功能分類
1.	本地隊列(local queue):
一個本地隊列是一個物理上位於本地隊列管理器中的隊列。本地隊列實際上存在與本地系統的內存或磁盤存儲終。本地隊列管理器控制隊列的訪問。
	應用程序可以“PUT”消息到本地隊列,也可以從本地隊列“GET”消息,另外程序還可以查詢或修改這些隊列的某些屬性。對隊列屬性的修改需要相應的權限。
2.	遠程隊列(remote queue):
	一個遠程隊列屬於一個不與該應用程序直接相連的隊列管理器。對這類隊列的訪問包含有本地隊列管理器和遠程隊列管理器的通信過程。這種通信涉及到通道。
	應用程序可對遠程隊列進行某些操作,比如程序可以向一個遠程隊列放一條消息,但程序不能從遠程隊列中去消息。應用程序只能從本地隊列讀取消息。
 	應用程序有兩種不同的方法可用來訪問遠程隊列。第一種是當程序打開一個遠程隊列時同時提供隊列管理器名和隊列名兩個參數。這要求程序知道目的隊列屬於哪個隊列管理器。第二種方法是在本地隊列管理器上存在一個遠程隊列的定義,這個定義包含有足夠的信息讓本地隊列管理器確定該遠程隊列所在的隊列管理器。
	遠程隊列定義中的目的隊列不一定是遠程隊列管理器的本地隊列,它也可以是一個遠程隊列定義,如圖所示。

 

	應用程序放一條消息到Q1,Q1是本地隊列管理器QM1上的一個遠程隊列定義:Q2 at 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(program command format)的消息的隊列。該隊列主要用於編寫管理程序時使用。具體的使用將在後續章節介紹。在創建隊列管理器時將爲每個隊列管理器自動創建命令隊列。 
9.	回覆隊列 
當應用程序發送請求消息時,接收消息的應用程序可以將回復消息發送給發送應用程序。此回覆消息放入一個稱爲回覆隊列的隊列中,它通常是發送應用程序的本地隊列。回覆隊列的名稱由作爲消息描述符一部分的發送應用程序指定。 

10.	別名隊列
	別名隊列實際上是本地隊列、遠程隊列定義或隊列名錶的另外一個名字。它是一種簡單的名字到名字的映射,它允許應用程序用另外一個名字來訪問隊列。WebSphere MQ已經爲應用程序屏蔽了許多底層系統細節,特別是網絡通信的細節,而別名隊列允許在不修改應用程序的條件下訪問其他名字的隊列。
2.1.3.2定義隊列
在WebSphere MQ中可以使用以下方法定義隊列: 
	在MQSC命令行中使用DEFINE
	在程序中使用PCF創建隊列命令

在定義隊列時需要指定隊列的類型和屬性。例如,可以設置隊列可存放的消息最大長度,以及隊列的最大深度等屬性。有關定義隊列對象的進一步詳細信息,請參閱《WebSphere MQ 腳本(MQSC)命令參考》或《WebSphere MQ Programmable Command Formats and Administration Interface》。 
2.1.3.3從隊列檢索消息
適當授權的應用程序可以根據以下檢索算法從隊列檢索消息: 
•	先進先出(FIFO)。 
•	在消息描述符中定義的消息優先級。以 FIFO 爲基礎檢索具有相同優先級的消息。 
•	特定消息的程序請求。 
來自應用程序的 MQGET 請求確定所使用的方法。 

2.1.4隊列管理器
在WebSphere MQ中隊列管理器是基本的軟件系統,隊列管理器可看成是隊列和其他對象的容器。WebSphere MQ中的每一個隊列都屬於一個隊列管理器,隊列管理器是爲應用程序和WebSphere MQ部件(一些管理工具)提供對隊列管理中對象的訪問。
一個隊列管理器是WebSphere MQ中的一個基本的獨立的執行單元。一臺機器上可以運行一個或多個隊列管理器。
任何需要訪問WebSphere MQ提供的服務的應用程序都必須先和隊列管理器相連,和應用程序相連的隊列管理器對該應用程序而言就叫“本地隊列管理器”(Local Queue Manager),本地隊列管理器爲程序提供MQI調用的支持。應用程序可以操作、管理本地隊列管理器所擁有的各種資源,也可以向其他的隊列管理器發送消息。
應用程序通過一種叫做MQI的編程接口向隊列管理器申請服務。這些服務包括“放”一條消息到隊列或從隊列“取”一條消息等一些基本操作。隊列管理器還使隊列成爲可靠的存儲消息的地方,它也控制安全性管理,並提供一些特殊的隊列功能,比如觸發隊列。
爲了減少應用程序對於它所運行環境的依賴性,WebSphere MQ的應用程序可以和一個它不知道名字的隊列管理器相連,這個隊列管理器就是一臺機器上的缺省隊列管理器。如果程序在調用MQCONN時,把隊列管理器名參數設置爲空,MQCONN將返回與缺省的隊列管理器連接的句柄。

隊列管理器擁有每個隊列。隊列管理器負責維護它所擁有的隊列,以及將它接收到的所有消息存儲到相應的隊列。可以由應用程序或隊列管理器將消息放入隊列,這些是它的正常操作的一部分。
2.1.4通道
2.1.4.1消息通道(Message channels)
消息通道是一種提供從一個隊列管理器到另一個隊列管理器的通信路徑。消息通道用在分佈式的隊列把消息從一個隊列管理器發送到另一個隊列管理器。它們使應用程序屏蔽了底層的通信協議。隊列管理器可能存在同種或異種平臺之間。爲了實現隊列管理器之間的通信,您必需在一個隊列管理器中定義一個發送消息的通道對象,在另一個隊列管理器中定義一個接收消息的通道對象。消息通道是一個單向鏈接。它通過消息通道代理(message channel agents)把兩個隊列管理器連接起來。如圖所示:

 

不要和MQI通道(MQI channel)通道混淆。MQI通道有兩種類型,分別是服務器連接(server-connection)和客戶器連接(client-connection)。
消息通道分類
消息通道的定義可以分爲以下6種類型:
	發送通道(Sender) 
	接收通道(Receiver) 
	服務器通道(Server) 
	請求器通道(Requester) 
	羣集發送通道(Cluster sender) 
	羣集接收通道(Cluster receiver)

消息通道的組合形式
如果要在隊列管理之間實現消息傳輸,必須要在兩個隊列管理器上都要定義相應的通道。發送方和接收方通道的組合形式如下:

	發送通道-接收通道(Sender-receiver )
	請求器通道-服務器通道(Requester-server)
	請求器通道-發送通道(Requester-sender (callback) )
	服務器通道-接收通道(Server-receiver )
	羣集發送通道-羣集接收通道(Cluster sender –cluster receiver)

注意:通道的組合形式有5種形式,每種組合方式是固定的,用戶不能隨意組合。每對通道的名稱必需相同例如:在發送通道-接收通道組合中,發送通道名和接收通道名必須一致,否則通道將無法啓動。
消息通道用法
發送通道-接收通道(Sender-receiver)
圖5 發送通道-接收通道
用法:由一個系統的發送通道來啓動通道,以便它可以發送消息到另一個系統。發送通道向接收通道發送啓動請求。發送通道從傳輸隊列發送消息到接收通道。接收通道把消息放到目標隊列。
請求器通道-服務器通道(Requester-server) 

用法:
(1)由一個系統中的請求器通道來啓動通道,以便它能從另一個系統接收到消息。 請求器通道向通道另一端的服務器通道發送請求來啓動。服務器通道從傳輸隊列把消息發送到請求器通道。
(2) 服務器通道也能啓動通道,併發送消息到請求器, 但這僅應用於完全意義的服務器通道, 也即服務器通道定義中應含有對方的連接名。一個完全意義的服務器通道可以由請求器通道啓動, 也可以發起和服務器通道的通訊。
(3) 最好不要手工去停止Server和Request通道,而是依靠Server通道的Discint的屬性來停止通道。

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

服務器通道-接收通道(Server-receiver)
用法:類似於發送通道-接收通道,但僅應用在完全意義的服務器通道。也即服務器通道定義應含有對方的連接名,通道的啓動方是服務器通道。

羣集發送通道(Cluster sender)
用法:在一個羣集中,每個隊列管理器都有一個羣集發送通道,通過它可以把送羣集信息發送到其中一個隊列管理器資源管理器。 隊列管理器通過這個通道也可以把消息發送到其他的隊列管理器。


羣集接收通道(cluster receiver)
功能:在一個羣集中,每一個隊列管理器都有一個羣集接收通道。通過這個通道可以接收數據消息和關於羣集的消息。

2.1.4.2 MQI通道
	MQI通道是WebSphere MQ 客戶端和服務器上的隊列管理器的通信的通道。當客戶端應用程序發出MQCONN或MQCONNX調用時,纔開始建立連接。它是一個雙向的通道,可以負責發送和接收,被用作MQI調用的傳送和響應。如圖所示:
 
圖,MQI通道

一個MQI通道可以把一個客戶端連接到單個隊列管理器,MQI通道有兩種類型,它們定義了雙向的MQI通道。
客戶端連接通道(Client-connection channel)
這種類型爲WebSphere MQ 的客戶端所使用。
服務器連接通道(Server-connection channel)
這種類型爲運行隊列管理器的服務器端所使用,運行在WebSphere MQ 客戶端的應用程序將使用這種通道進行通信。
2.1.4.3比較消息通道和MQI通道
消息通道與MQI通道之間的區別可以從兩方面進行比較:
	MQI通道是雙向的:一個MQI通道可以被用來發送請求,也可用來接收響應。而消息通道則只能單向數據通信。如果要在兩個隊列管理器之間實現雙向通信,那麼需要定義兩個消息通道,一個用來實現數據的發送,另一個用來實現數據的接收。
	MQI通道的通信是同步的:當一個MQI請求從客戶端發送服務器端時,WebSphere MQ的客戶端在發送下一個請求之間必須要等待來自服務器端的響應。而消息通道,在通道中傳輸的消息是與時間無關的。大量的消息可以從一個隊列管理器發送到另一個隊列管理器,發送隊列管理器不必等待來自接收隊列管理器的任何響應。


2.1.5進程
進程定義對象定義響應 WebSphere MQ 隊列管理器上的觸發器事件啓動的應用程序。進程定義屬性包含應用程序標識、應用程序類型和特定於應用程序的數據。 
2.1.6羣集
在使用分佈式排隊的傳統 WebSphere MQ 網絡中,每個隊列管理器是獨立的。如果隊列管理器需要將消息發送到另一個隊列管理器,則它必須定義一個傳輸隊列、一個到遠程隊列管理器的通道,以及它要將消息發送到的每個隊列的遠程隊列定義。 
羣集是一組以隊列管理器可以在不需要傳輸隊列、通道和遠程隊列定義的情況下在單個網絡上彼此直接通信的方法設置的隊列管理器。 
2.1.7名稱列表
名稱列表是包含其它 WebSphere MQ 對象列表的 WebSphere MQ 對象。通常,應用程序(如觸發器監視器)使用名稱列表,它們用於標識一組隊列。使用名稱列表的優點是它獨立於應用程序維護;可以在不停止任何使用它的應用程序的情況下更新它。並且,如果一個應用程序失敗,則名稱列表不受影響,其它應用程序可以繼續使用它。 
名稱列表還與隊列管理器羣集一起使用,以維護多個 WebSphere MQ 對象引用的羣集列表。 
2.1.8認證信息對象
隊列管理器認證信息對象(AUTHINFO)組成安全套接字層(SSL)安全性的 WebSphere MQ 支持的部件。它提供使用 LDAP 服務器檢查證書撤銷列表(CRL)所需的定義。CRL 允許認證中心取消不再可信的證書。 
本書描述對認證信息對象使用 setmqaut、dspmqaut、dmpmqaut、rcrmqobj、rcdmqimg 和 dspmqfls 命令。有關 SSL 概述以及 AUTHINFO 的使用,請參閱 WebSphere MQ Security。 
2.1.9系統缺省對象
系統缺省對象是一組每次創建隊列管理器時自動創建的對象定義。您可以複製和修改這些對象定義中的任何一個,以在安裝時用於應用程序。 
缺省對象名具有項 SYSTEM.DEFAULT;例如,缺省本地隊列是 SYSTEM.DEFAULT.LOCAL.QUEUE,並且缺省接收方通道是 SYSTEM.DEFAULT.RECEIVER。您無法重命名這些對象;這些名稱的缺省對象是必需的。 
當您定義對象時,從相應的缺省對象複製您不明確指定的任何屬性。例如,如果您定義本地隊列,則從缺省隊列 SYSTEM.DEFAULT.LOCAL.QUEUE 獲取您未指定的那些屬性。 
請參閱附錄1, "系統和缺省對象"以獲取有關係統缺省的更多信息。 

2.1.10 MQI(message queue interface)
MQI(消息隊列接口)有下列組成部分:
	函數接口:應用程序通過函數可以訪問隊列管理器和它的部件。
	數據結構:應用程序使用提供的數據接口來是實現把數據傳遞給隊列管理器,或從隊列管理器中獲得數據。
	基本數據類型:也是用來實現從隊列管理器傳遞數據,或從隊列管理器中獲得數據。

2.2體系結構
	WebSphere MQ的體系結構如圖所示,它是由許多對象所組成的,主要包括隊列管理器、隊列、通道、進程定義等對象。隊列管理器和DB2數據庫中的實例相似,它是有一組MQ進程和一些內存空間所組成的。它實現了應用程序通過MQI調用可以訪問MQ的對象。
隊列管理器爲應用程序提供了排隊服務,並管理屬於它的隊列。它確保: 
	根據接收到的命令更改對象屬性。 
	當滿足相應條件時,生成特殊事件(如觸發器事件或檢測事件)。 
	按照發送 MQPUT 調用的應用程序的請求,將消息放入正確的隊列。如果不能完成,則將通知應用程序並給出適當的原因碼。

所以在使用WebSphere MQ時,首先需要創建一個隊列管理器,然後再隊列管理器中在創建隊列和通道等其他對象。

 
圖,WebSphere MQ的結構


2.2.1 WebSphere MQ和消息排隊
2.2.1.1 WebSphere MQ 和消息排隊
WebSphere MQ 使應用程序通過使用消息排隊來實現消息驅動處理,使用對應的消息排隊軟件產品實現在不同平臺之間進行通信。從而使應用程序屏蔽了底層的通訊結構。 
WebSphere MQ 產品提供了消息隊列接口(或 MQI)的公共應用程序編程接口,如果應用程序使用了MQI,將非常容易將應用程序從一個平臺移植至另一個平臺。 
WebSphere MQ 還提供高級別消息句柄 API,它使程序員更容易在企業內或企業間部署商業流程集成的智能網絡。這稱爲應用程序消息傳遞接口(AMI)。AMI 將許多通常由消息傳遞應用程序執行的消息處理功能移動到中間件層,在此將代表應用程序應用企業定義的一組策略。 
如需更詳細地瞭解 MQI 和 AMI,請參看《WebSphere MQApplication Programming Reference 》。 
2.1.2與時間無關的應用程序
程序不在網絡上直接相互通信,而是間接地將消息放入消息隊列。因爲程序沒有直接的聯繫,所以它們不必同時運行。消息放入適當的隊列時目標程序可以是忙的。消息的到達並不影響程序的當前處理,也不意味程序需要立即處理該消息。消息放入隊列時接收程序甚至根本不需要正在運行。接收程序可以在需要的時候開始執行。
2.1.3消息驅動處理
當消息到達隊列時滿足了觸發條件,它們可以使用自動觸發應用程序。 
2.2.2 隊列管理器的進程	
 
圖,隊列管理器進程
啓動了隊列管理器之後,將會啓動一組進程(如上圖所示),現以unix平臺爲例,簡單介紹一些進程的功能:
	以amqc開頭的進程是和通道相關的進程。 
	amqhasmx進程是負責記錄日誌的進程(Logger)。
	amqharmx進程是負責日誌格式化。(僅在線性日誌中使用)。
	amqzllp0進程是檢查點處理器(Checkpoint processor)。
	amazlaa0進程本地隊列管理器的代理(Local queue manager agents)。
	amqzxma0進程是執行控制器( Execution controller)。

2.3客戶機和服務器

WebSphere MQ 支持其應用程序的客戶機-服務器配置。 WebSphere MQ客戶端通過MQI通道與WebSphere MQ服務器進行通訊。
WebSphere MQ 客戶機是允許在系統上運行的應用程序對在另一個系統上運行的隊列管理器發出 MQI 調用的組件。此調用的輸出發送回客戶機,此客戶機將其輸出傳送回應用程序。 
WebSphere MQ 服務器是爲一個或多個客戶機提供排隊服務的隊列管理器。所有 WebSphere MQ 對象,例如,僅存在於隊列管理器機器(WebSphere MQ 服務器機器)而不存在於客戶機的隊列。WebSphere MQ 服務器還可以支持本地 WebSphere MQ 應用程序。 
WebSphere MQ 服務器和普通隊列管理器之間的差異是服務器與每個客戶機有專用通信鏈路。要獲取有關創建客戶機和服務器的通道的更多信息,請參閱《WebSphere MQ Intercommunication》。 
要獲取有關客戶機支持的信息,請參閱 《WebSphere MQ 客戶機》。 
客戶機-服務器環境中的 WebSphere MQ 應用程序
當連接到服務器時,客戶機 WebSphere MQ 應用程序可以與本地應用程序相同的方法發出大多數 MQI 調用。客戶機應用程序發出 MQCONN 調用,以連接到指定的隊列管理器。然後此隊列管理器處理指定從連接請求返回的連接句柄的任何其它 MQI 調用。 您必須將您的應用程序鏈接到相應的客戶機庫。請參閱 《WebSphere MQ 客戶機》 一書,以獲取進一步信息。 

2.4觸發機制
2.4.1觸發的概念
隊列管理器把某種條件叫做觸發事件,如果隊列被設置爲觸發類型並且觸發事件發生了,隊列管理器發送觸發消息到一個叫做啓動隊列的隊列中,觸發消息被放置到啓動隊列過程意味着產生了觸發事件。
由隊列管理器產生的觸發消息不是永久性消息,這將減少日誌工作量(因此提高性能),並最小化系統重啓時間。
處理啓動隊列中的消息叫做觸發監控程序(trigger-monitor application),他的工作是讀取觸發消息並根據觸發消息的信息作出相應的處理。通常將啓動別的應用程序來處理產生觸發消息的隊列。從隊列管理器來看,觸發監控程序沒有什麼特殊的,它只是一個從啓動隊列讀取消息的應用程序。

如果隊列被設置成觸發形式,你可以選擇創建一個進程定義(process-definition)的對象,這個對象包含了一個應用程序名,這個應用程序用來處理引起觸發事件的消息。如果創建了進程對象,隊列管理器將把應用程序名包含在觸發消息中,以便觸發監控程序可以使用。進程對象名需要在本地隊列的ProcessName的屬性中設置。每個隊列可以配置一個進程對象,或幾個隊列可以共享同一個進程對象。

對於所有WebSphere MQ 或WebSphere MQ V5的產品,如果你想觸發啓動通道,可以不必定義進程對象。

有些平臺的WebSphere MQ客戶端也支持觸發機制,例如:UNIX,Windows,OS/2。

運行在客戶端的應用程序和運行在完全WebSphere MQ 環境的應用程序是一樣的,只是應用程序鏈接的庫有區別。同時觸發監控程序和應用程序必需要都在同一系統中運行。

觸發所涉及的對象:
	應用隊列:是一個本地隊列,並設置爲可觸發的。當觸發條件滿足時,將會產生觸發消息。
	進程定義:一個應用隊列可能由一個進程定義對象和它關聯。進程定義中包含應用程序的信息。該應用程序負責從應用隊列中取出消息。
	傳輸隊列:如果用觸發方式來啓動通道,則需一個傳輸隊列。傳輸隊列的TriggerData屬性中設置成將被啓動的通道名。這將可省略進程的定義。
	觸發事件:它是一種引起隊列管理器產生觸發消息的事件。
	觸發消息:當觸發事件發生時,隊列管理器將產生觸發消息。觸發信息來自於應用隊列和與應用隊列關聯的進程定義,它包含了將要被啓動的程序名。
	啓動隊列:也是一個本地隊列,它是被用來存放觸發消息的隊列。一個隊列管理器可以擁有多個啓動隊列。一個啓動隊列可以爲多個應用隊列服務。
	觸發監控器:是一個持續運行的程序,當一個觸發消息到達啓動隊列時,觸發監控器獲取觸發消息,並利用觸發消息中的信息,啓動應用程序來處理應用隊列中的消息,並把觸發消息頭髮送傳遞給應用程序,消息頭中包括應用隊列名。

在所有平臺上,有一個特殊的觸發監控器叫做通道啓動器(channel initator),它的作用是啓動通道。

2.4.2觸發類型
	EVERY:當應用隊列中每接收到一個消息時,都將產生觸發消息。如果應用程序僅處理一個消息就結束時,可採用這種觸發類型。
	FIRST:當應用隊列中的消息從0變爲1纔會發生觸發事件。如果當隊列中的一個消息到達時啓動應用程序,直到處理完所有消息就結束,則採用這種觸發類型。
	DEPTH:當應用隊列中的消息數目和TriggerDepth的屬性值相同時,纔會產生觸發事件。當一系列請求的恢復都收到時,才啓動應用程序,則採用這種觸發類型。
當採用depth觸發時,產生觸發消息後,隊列將被修改成非觸發方式,如果需要再次觸發,將要重新設置成允許觸發。
隊列的TriggerDepth屬性表示引起depth觸發事件發生時,隊列中的消息數目。
2.4.3觸發的工作原理
爲了更好地能理解觸發機制,我們舉一個觸發類型爲FIRST的例子。
1.	只有一個本地或遠程的應用程序A,往應用隊列(Application Queue)中PUT了一條消息。
2.	當隊列原來的深度爲0時,也即隊列爲空,這時PUT一條消息到隊列中,將會形成觸發事件,同時會產生一條觸發消息,觸發消息中將包含進程定義(Process)中的信息。
3.	隊列管理器創建觸發消息,並把它PUT到與應用隊列相關的啓動隊列(Initiation Queue)。
4.	觸發監控器從啓動隊列中GET出觸發消息。
5.	觸發監控器處理觸發消息,發出啓動應用程序B的命令。
6.	應用程序B打開應用隊列,並處理隊列中的消息。

注意:
1.	如果隊列的觸發類型爲FIRST或DEPTH,同時有多個應用程序往應用隊列發送消息,這種情況下將不會形成觸發事件。
2.	如果啓動隊列設置成不允許PUT消息,那麼隊列管理器將不產生任何觸發消息,直到把啓動隊列的屬性修改成允許PUT消息。
3.	如果通道設置成觸發方式,建議觸發類型爲FIRST或DEPTH。


 

圖 2.1觸發消息和應用流程
一般情況下,特別是工作負載不均勻分佈時,人們總希望有消息需要處理時,才啓動相應的應用程序。
這種自動啓動應用程序的機制被稱作“觸發”(Triggering)。基本原理是:當隊列管理器發現有一條消息到達被觸發的隊列之後,他將產生一條


2.5 隊列管理器羣集
2.5.1 羣集的概念
如果您熟悉WebSphere MQ和分佈式隊列,則可以把羣集認爲是一個隊列管理器的網絡,或是一個隊列管理器的集合,羣集中的隊列管理器可以是不同的操作系統平臺。每當您在羣集中創建一個接收通道或定義一個隊列時,則系統將自動在其它隊列管理器中創建相應的發送通道和遠程隊列定義。
在羣集中您不需要創建傳輸隊列定義,因爲WebSphere MQ在每個隊列管理器中已經定義了一個傳輸隊列。這個傳輸隊列可以把消息發送到任何隊列管理器中。
羣集的信息是存放在資源庫中。大多數隊列管理器只保留它們自己所需要的信息,這些信息包括與它們通信的隊列管理器和隊列的信息。一些隊列管理器包含了羣集中所有隊列管理器的所有信息。
下圖顯示了一個叫CLUSTER的羣集:
	在這個羣集中有三個隊列管理器,QM1,QM2和QM3。
	QM1和QM2存放了羣集中隊列管理器的信息。它們被叫作完全資源隊列管理器。
	QM2和QM3中有幾個隊列,這些隊列能被羣集中任何其它隊列管理器。這些隊列被叫作羣集隊列。
	每一個隊列管理器有一個接收通道的定義,它被叫作羣集接收通道。用來接收消息。
	每一個隊列管理器也有一個發送通道的定義,它將和完全資源管理器的羣集接收通道相連。這個通道叫做羣集發送通道。在下圖中,QM1和QM3有羣集發送通道連接到TO.QM2,QM2有羣集發送通道連接到TO.QM1。
一旦羣集接收通道和羣集發送通道已經定義好了,通道將自動啓動。
 
圖,隊列管理器羣集

2.5.2 羣集的優點
使用羣集有兩個優點:
1.	減少系統管理
即使您創建了一個很小的羣集,都將減少系統管理的工作。在羣集中建立隊列管理網絡比在分佈式隊列建立網絡將使用更少的定義。由於使用更少的定義,您將能夠更快和更容易地建立和改變網絡。並且降低了定義錯誤的風險。 
2.	增強可用性和實現負載均衡
簡單的羣集將更容易管理。對於複雜的羣集,將提高了擴展性和可用性。因爲您可以定義在不同的隊列管理器定義相同的隊列,因此工作負載可以在羣集的隊列管理器實現均衡。


2.5.3 羣集的組件
	羣集資源庫(隊列)
資源庫中存放了羣集中隊列管理器的信息,包括隊列管理器名,以及它們的通道和隊列等。這些資源庫信息通過一個叫SYSTEM.CLUSTER.COMMAND.QUEUE的隊列進行交換,並存放到一個叫SYSTEM.CLUSTER.REPOSITORY.QUEUE的固定隊列中。
資源庫可能是完全或部分的。每個隊列管理器至少要連接到一個擁有完全資源庫的隊列管理器。
每一個羣集隊列管理器必須有一個叫SYSTEM.CLUSTER.REPOSITORY.QUEUE的本地隊列,在羣集中至少一個羣集隊列管理器含有完全資源庫。對於每個羣集隊列管理器,必須要預定義一個羣集-發送通道連接到資源庫隊列管理器中。資源庫隊列管理器之間必須要互連,網絡狀況要比較好,和具有高可用性。普通隊列管理器只包含有部分資源庫信息。

	羣集-發送通道
羣集-發送通道的類型爲TYPE(CLUSSDR),羣集隊列管理器使用羣集-發送通道可以把消息發送到完全資源庫隊列管理器中。這個通道被用來通知隊列管理器狀態的改變,例如,隊列的刪除和創建。它僅和第一個完全資源庫隊列管理器聯繫。
	羣集-接收通道
羣集-接收通道的類型爲TYPE(CLUSRCVR),羣集隊列管理器可以使用它接收羣集內的消息。每一個羣集隊列管理器至少需要一個羣集-接收通道。
	羣集傳輸隊列
從一個隊列管理器發送到其它隊列管理器的消息都將被放到SYSTEM.CLUSTER.TRANSMIT.QUEUE隊列中,在每個隊列管理器中必須要存在羣集傳輸隊列。

2.5.4 創建羣集
下表是一個創建羣集的腳本示例,羣集名爲NPC。

ALTER QMGR REPOS(NPC)

DEFINE CHANNEL(TO.QM0000) +
CHLTYPE(CLUSRCVR) CONNAME(‘192.168.10.11(1414)’ ) +
CLUSTER(NPC)

DEFINE CHANNEL(TO.QM1000) +
CHLTYPE(CLUSSDR) CONNAME(‘192.168.10.22(1414)’) +
CLUSTER(NPC) + 
DESCR(‘To Other Repository’)

DEFINE QLOCAL(0000_1) + 
CLUSTER(NPC)
其中羣集傳輸隊列和命令隊列不用顯示定義,隊列管理器QM0000是NPC羣集中一個完全資源庫隊列管理器。一個隊列管理器可以同時屬於多個羣集。

在MQSeries v5.2以後版本,在羣集中能夠支持DHCP:
	在定義羣集-接收通道時,不用說明隊列管理器的網絡地址。
DEFINE CHANNEL(TO.QM0000) +
CHLTYPE(CLUSRCVR) +
TRPTYPE(TCP) +
CLUSTER(NPC) 
	在定義羣集-發送通道時,不用說明資源庫隊列管理器名。
DEFINE CHANNEL(TO.+QMNAME+) +
CHLTYPE(CLUSSDR) +
TRPTYPE(TCP) +
CONNAME(...) +
CLUSTER(NPC)

2.5.5 實現負載均衡
當在羣集中含有同一隊列的多個實例時,WebSphere MQ通過使用負載管理算法把消息發送到最方便的隊列管理器中。負載管理算法儘可能地選擇本地隊列管理器作爲目的地。如果在本地隊列管理器中沒有隊列,這個算法將選擇最合適的目標。合適的原則是取決於通道狀態、隊列管理器和隊列的可用性。在滿足條件的隊列管理器之間,這個算法使用了輪循的方法進行選擇。從而可以實現負載均衡的功能。

使用羣集可以減少系統管理,也可以在羣集中的幾個隊列管理器中創建同名的隊列。只有擁有隊列的隊列管理器才能處理隊列中的消息,但應用程序發送消息時不用顯示說明隊列管理器名。負載管理算法決定了那個隊列管理器應該處理消息。

下圖中顯示了一個羣集中定義了多個Q3隊列的定義。當在QM1的應用程序放一個消息到Q3時,它不必知道是那個Q3隊列將處理消息。
當消息正在傳輸時,羣集中的一個本地隊列變得不可用,那麼消息將被轉發到另一個隊列中(但需要以BIND_NOT_FIXED的選項打開隊列)。如果其它隊列也不可用,這個消息將被放到死信隊列中。
如果目標隊列管理器不能工作,那麼消息將仍然被放在傳輸隊列中,系統將嘗試更換消息的路由。這樣做並不會影響消息的完整性,但如果出現隊列管理器失敗並消息處在可疑(in doubt)狀態,這個消息將不能更換路由。
 
圖,在羣集中一個隊列有多個實例

注意:
2.	在羣集中創建同一隊列的多個實例時,需要確保您的消息互相之間沒有依賴,例如,消息需要按照特定順序處理或被同一隊列管理器處理。
3.	使同一隊列的不同實例的定義相同,否則執行MQINQ調用將產生不同的結果。

在大多數情況下負載管理算法將滿足系統的需求,然而您也可以編寫用戶出口(user-exit)程序來定製負載管理算法,WebSphere MQ中包含用戶出口和羣集負載出口(cluster workload exit),可以使用ALTER QMGR命令來激活羣集負載出口。例如,ALTER QMGR CLWLEXIT(myexit) 欲瞭解更詳細的有關信息,請參考《Queue Manager Clusters》。

2.5.6 羣集管理
您有時需要對羣集中的隊列管理器進行維護,例如,您可能需要備份隊列中的數據,或把補丁應用到系統中。如果隊列管理器包含隊列,則必須暫停隊列管理器。當維護結束後,將繼續隊列管理器的工作。
	爲暫停隊列管理器,可以使用命令SUSPEND QMGR,例如:

SUSPEND QMGR CLUSTER(SALES)

它將臨時從羣集中移走一個隊列管理器,這樣將不會有任何消息發送到這個隊列管理器。暫停的隊列管理器和對象的信息都被保留在資源庫中,但是隊列管理器被標記爲暫停。

	當維護隊列管理器的工作完成後,需要讓隊列管理器繼續工作。通過執行RESUME QMGR則可以實現,例如:
RESUME QMGR CLUSTER(SALES)
RESUME QMGR命令將通知完全資源庫,這個隊列管理器將又重新可用。完全資源隊列管理器散佈這個信息到其它隊列管理器。
	在羣集中的隊列管理器可以執行刷新啓動命令。在正常環境下不需要執行刷新命令,
例如:
        REFRESH CLUSTER(SALES)
    執行刷新命令,將丟棄所有本地的關於羣集的信息。
	如果要從羣集中強制除去一個隊列管理器,則可以通過RESET CLUSTER命令實現。或一個隊列管理器已經被刪除,但是定義到羣集的羣集-接收通道仍然存在,那麼您也可以使用RESET CLUSTER命令來快速地清理這些定義信息。

使用RESET CLUSTER命令是刪除自定義羣集-發送通道的唯一方法。在正常的環境中,您不必運行這個命令。這個命令只能在資源管理器中執行,例如:
RESET CLUSTER(SALES) QMNAME(QM0000) ACTION(FORCEREMOVE) QUEUES(NO) 
	查看羣集中隊列管理器信息,可以使用命令DISPLAY CLUSQMGR,例如:
DISPLAY CLUSQMGR(*) CLUSTER(SALES) 
	您可以定義羣集隊列,例如:
DEFINE QLOCAL(0000_1) CLUSTER(SALES) 

欲瞭解更詳細的有關羣集管理的信息,請參考《Queue Manager Clusters》。

2.6本章小結
	本章主要介紹WebSphere MQ的基本概念和體系結構,WebSphere MQ核心是由隊列管理器、隊列和通道組成。隊列和通道分別有多種類型。在實際應用中,根據系統的實際需要選擇合適的對象類型進行配置。描述了WebSphere MQ隊列管理器的觸發機制和羣集的概念並介紹了它的優點以及實現方法。

2.7本章練習
1,	IBM WebSphere MQ中包含了那些對象?
2,	練習安裝和連接WebSphere MQ客戶端到服務器端的過程。
3,	在系統中創建的第一個隊列管理器是缺省隊列管理器?
(1) 是                 (2) 否
答案:(2)
4,	WebSphere MQ 使用一種什麼接口,實現通過程序可以訪問隊列管理器的資源:
(1)	程序到程序的API(the program to program API)
(2)	消息隊列接口(Message Queue Interface)
(3)	同步模式(the synchronous model)
(4)	觸發機制(triggering)
答案:(2)
5,	WebSphere MQ僅異步環境的消息隊列。
(1)對            (2)錯
答案:(2)
6,	一個消息可以由下列那些部分組成:
(1)	應用數據(application data)
(2)	死信頭 (a dead-letter header)
(3)	安全頭 (security header)
(4)	消息描述塊 (a message descriptor)
(5)	以上所有的 (all the above)
答案:(1)(2)(4)
7,	所有的消息至少有一個頭,它是:
(1)	MQXQH(transmission header)
(2)	MQDLH (dead letter header)
(3)	MQMD (message descriptor)
(4)	MQTH (trigger header)
答案:(3)
8,	在WebSphere MQ觸發機制,隊列管理器啓動被觸發的程序:
(1)對                  (2)錯
答案:(2)
9.臨時動態隊列中可以包含下列那些消息類型:
(1)	僅回覆消息
(2)	僅報告消息
(3)	僅非永久性消息
(4)	永久性和非永久性消息
         答案:(3) 


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章