IBM MQ介紹

【編者按】關於MQ，我之前只是有個大概概念。譬如以前，就是根據前端送過來的消息，format成後端所須要的消息格式，並將format後的消息放入一個Queue文件中，若是消息發送成功（收到該request成功或者失敗的response），該消息將從Queue文件中刪除；若是與後端的鏈路斷掉了，該消息會一直重發，直到鏈路連通，後者重試N次後放棄（N次：配置在文件中，譬如9999）。

如下都是轉載內容，包含的主題以下：

初識 IBM MB與MQ ==> good
消息中間件介紹
IBM WebSphere MQ 編程 ==> good
IBM MQSeries的使用指南 ==> good
IBM WebSphere MQ 簡介和概述 ==> good

 

 

 

 

初識 IBM MB與MQ

 

轉自：http://hi.baidu.com/һҹʮһ��/blog/item/adc02753211c3c2943a75b6c.html

MQ和MB的特性，以及他們的區別與聯繫

首先從概念上來講，MQ是消息中間件（號稱：一旦發出保證送達），MB是ESB產品。

MQ負責在兩個系統之間傳遞消息，這兩個系統能夠是異構的，處於不一樣硬件、不一樣操做系統、用不一樣語言編寫，只須要簡單的調用幾個MQ的API，就能夠互相通信，你沒必要考慮底層系統和網絡的複雜性。MQ做爲IBM的一個拳頭產品，雖然功能看上去很簡單，就是個消息隊列，但他倒是IBM中間件的核心，也是相比其餘廠商（好比BEA）的一個優點。MQ不只有很高的性能，並且對各類平臺的支持很是好，幾乎你能想到的硬件和操做系統平臺以及編程語言，MQ都有專門的API支持。

但MQ的功能僅限於消息隊列，至於應用A發給應用B的消息格式是怎樣的、能不能被應用B解析，MQ管不了，他只是盡力將消息發到目的地（MQ可以應付多種異常狀況，例如網絡阻塞、臨時中斷等等）。此外，若是應用的數目多了，那互相之間都要創建MQ鏈接，網絡拓撲就成了蜘蛛網了（就好像是最初的電話系統）

所以，咱們將網絡的星型拓撲引入系統架構中，把一對一的MQ換成一箇中心節點，即ESB，MB便是IBM的ESB產品。

MB處於系統的中心，起到一個總線的做用，全部應用都直接鏈接到MB（通常是經過MB主動調用），而不是應用之間直接互聯，這樣的好處不言而喻，能夠極大的下降應用之間的耦合性。由此引出MB的兩大核心功能：消息路由和數據轉換。
由於各個應用都插入到MB上，因此應用A只管把消息丟給MB，MB自動根據消息字段、以及業務邏輯，判斷要把消息交給誰，這就像路由器同樣，根據數據包的頭把包路由到相應地址。MB內部的業務邏輯由開發人員設定，固然利用MB的Toolkit，編寫業務邏輯也很是簡單：拖一些節點，用箭頭把它們連起來，就像是畫流程圖同樣，很是形象簡單。再用MB的腳本語言（相似sql的腳本）實現邏輯判斷，通俗地說就是判斷要走哪一個邏輯分支（if...else.....）。

不過各個應用是怎樣與MB鏈接的呢？MB提供了三種方式：MQ、文件和web service（好像不單三種http、tcp/ip）

MQ方式便是利用MQ將MB與應用互聯；文件方式則是指定某個目錄，MB會自動監視那個文件目錄，一旦文件有改變則認爲是新的消息到來，MB自動讀取指定文件的內容；而web service就不用解釋了，直接利用web service進行通信。MB支持這些互聯方式也是爲了最大化兼容性，特別是對於那些遺留系統或是不支持主流通信方式的系統。

最後說說一個比較偏門的ESB產品：websphere ESB。聽過的人可能很少，由於IBM在中國推廣的比較少，這個WESB很像是MB的精簡版，只支持JMS、WS等少數幾種J2EE的通信方式，因此是爲J2EE專門準備的。不像MB，支持數十種平臺和通信方式，例如FTP，甚至不少你根本沒據說過的很古老的通訊協議。這二者的性能相差很多，價格也有三四倍的差距。更要命的是，原先在WESB上開發的東西，是不能遷移到MB使用的，IBM彷佛鐵了心要狠狠宰咱們，惟一的方法是再買一個MB，而後用MQ把WESB和MB鏈接起來，各跑各的。

漏了一個DataPower，這東西我只是略有了解，它的賣點在於硬件支持XML，因此性能比較好，此外還支持一下web service安全方面的東東。所以，WESB是最小功能集，而MB與datapower功能上有必定重疊，如XML，可對數據進行格式轉換（貌似還能夠提供JAVA接口作更復雜的個性化的格式轉換）。

消息中間件介紹

轉自：http://hi.baidu.com/��Ű���/blog/item/6519d04febba3b3fafc3abb7.html

消息中間件概述

消息隊列技術是分佈式應用間交換信息的一種技術。消息隊列可駐留在內存或磁盤上,隊列存儲消息直到它們被應用程序讀走。經過消息隊列，應用程序可獨立地執行--它們不須要知道彼此的位置、或在繼續執行前不須要等待接收程序接收此消息。

在分佈式計算環境中，爲了集成分佈式應用，開發者須要對異構網絡環境下的分佈式應用提供有效的通訊手段。爲了管理須要共享的信息，對應用提供公共的信息交換機制是重要的。

設計分佈式應用的方法主要有：遠程過程調用(PRC)--分佈式計算環境(DCE)的基礎標準成分之一；對象事務監控(OTM)--基於CORBA的面向對象工業標準與事務處理(TP)監控技術的組合；消息隊列(MessageQueue)--構造分佈式應用的鬆耦合方法。

(a) 分佈計算環境/遠程過程調用 (DCE/RPC)

RPC是DCE的成分，是一個由開放軟件基金會(OSF)發佈的應用集成的軟件標準。RPC模仿一個程序用函數引用來引用另外一程序的傳統程序設計方法，此引用是過程調用的形式，一旦被調用，程序的控制則轉向被調用程序。

在RPC實現時，被調用過程可在本地或遠地的另外一系統中駐留並在執行。當被調用程序完成處理輸入數據，結果放在過程調用的返回變量中返回到調用程序。RPC完成後程序控制則當即返回到調用程序。所以RPC模仿子程序的調用/返回結構，它僅提供了Client(調用程序)和Server(被調用過程)間的同步數據交換。

(b) 對象事務監控 (OTM)

基於CORBA的面向對象工業標準與事務處理(TP)監控技術的組合，在CORBA規範中定義了：使用面向對象技術和方法的體系結構；公共的Client/Server程序設計接口；多平臺間傳輸和翻譯數據的指導方針；開發分佈式應用接口的語言(IDL)等，併爲構造分佈的Client/Server應用提供了普遍及一致的模式。

(c) 消息隊列 (Message Queue)

消息隊列爲構造以同步或異步方式實現的分佈式應用提供了鬆耦合方法。消息隊列的API調用被嵌入到新的或現存的應用中，經過消息發送到內存或基於磁盤的隊列或從它讀出而提供信息交換。消息隊列可用在應用中以執行多種功能，好比要求服務、交換信息或異步處理等。

中間件是一種獨立的系統軟件或服務程序，分佈式應用系統藉助這種軟件在不一樣的技術之間共享資源，管理計算資源和網絡通信。它在計算機系統中是一個關鍵軟件，它能實現應用的互連和互操做性，能保證系統的安全、可靠、高效的運行。中間件位於用戶應用和操做系統及網絡軟件之間，它爲應用提供了公用的通訊手段，而且獨立於網絡和操做系統。中間件爲開發者提供了公用於全部環境的應用程序接口，當應用程序中嵌入其函數調用，它即可利用其運行的特定操做系統和網絡環境的功能，爲應用執行通訊功能。

若是沒有消息中間件完成信息交換，應用開發者爲了傳輸數據，必需要學會如何用網絡和操做系統軟件的功能，編寫相應的應用程序來發送和接收信息，且交換信息沒有標準方法，每一個應用必須進行特定的編程從而和多平臺、不一樣環境下的一個或多個應用通訊。例如，爲了實現網絡上不一樣主機系統間的通訊，將要求具有在網絡上如何交換信息的知識（好比用TCP/IP的socket程序設計）；爲了實現同一主機內不一樣進程之間的通信，將要求具有操做系統的消息隊列或命名管道(Pipes)等知識。

目前中間件的種類不少，如交易管理中間件(如IBM的CICS)、面向Java應用的Web應用服務器中間件(如IBM的WebSphere Application Server)等，而消息傳輸中間件(MOM)是其中的一種。它簡化了應用之間數據的傳輸，屏蔽底層異構操做系統和網絡平臺，提供一致的通信標準和應用開發，確保分佈式計算網絡環境下可靠的、跨平臺的信息傳輸和數據交換。它基於消息隊列的存儲-轉發機制，並提供特有的異步傳輸機制，可以基於消息傳輸和異步事務處理實現應用整合與數據交換。

IBM 消息中間件MQ以其獨特的安全機制、簡便快速的編程風格、卓越不凡的穩定性、可擴展性和跨平臺性，以及強大的事務處理能力和消息通信能力，成爲業界市場佔有率最高的消息中間件產品。

MQ具備強大的跨平臺性，它支持的平臺數多達35種。它支持各類主流Unix操做系統平臺,如：HP-UX、AIX、SUN Solaris、Digital UNIX、Open VMX、SUNOS、NCR UNIX；支持各類主機平臺，如：OS/390、MVS/ESA、VSE/ESA；一樣支持Windows NT服務器。在PC平臺上支持Windows9X/Windows NT/Windows 2000和UNIX (UnixWare、Solaris)以及主要的Linux版本(Redhat、TurboLinux等)。此外，MQ還支持其餘各類操做系統平臺，如：OS/二、AS/400、Sequent DYNIX、SCO OpenServer、SCO UnixWare、Tandem等。

 

IBM WebSphere MQ 編程

轉自http://hi.baidu.com/injava/blog/item/7e2fb6ec15cf493c269791b3.html

消息隊列（MQ）是一種應用程序對應用程序的通訊方法。應用程序經過寫和檢索出入列隊的針對應用程序的數據（消息）來通訊，而無需專用鏈接來連接它們。消息傳遞指的是程序之間經過在消息中發送數據進行通訊，而不是經過直接調用彼此來通訊，直接調用一般是用於諸如遠程過程調用的技術。排隊指的是應用程序經過隊列來通訊。隊列的使用除去了接收和發送應用程序同時執行的要求。

IBM WebSphere MQ 產品支持應用程序經過不一樣組件如處理器、子系統、操做系統以及通訊協議的網絡彼此進行通訊。例如，IBM WebSphere MQ 支持 35 種以上的不一樣操做系統。

IBM WebSphere MQ 支持兩種不一樣的應用程序編程接口：Java 消息服務（JMS）和消息隊列接口（MQI）。在 IBM WebSphere MQ 服務器上，JMS 綁定方式被映射到 MQI。如圖 3 所示，應用程序直接與其本地隊列管理器經過使用 MQI 進行對話，MQI 是一組要求隊列管理器提供服務的調用。MQI 的引人之處是它只提供 13 次調用。這意味着對於應用程序編程員它是一種很是易於使用的接口，由於大部分艱苦工做都將透明完成的。

圖形 2. IBM WebSphere MQ 編程

 

 

圖 2 顯示了 IBM WebSphere MQ 編程的原理。第一步是讓應用程序與隊列管理器鏈接。它經過 MQConnect 調用來進行此鏈接。下一步使用 MQOpen 調用爲輸出打開一個隊列。而後應用程序使用 MQPut 調用將其數據放到隊列上。要接收數據，應用程序調用 MQOpen 調用打開輸入隊列。應用程序使用 MQGet 調用從隊列上接收數據。

圖中還顯示了消息通道代理（MCA）、通道出口和對象權限管理器（OAM）。MCA 是 IBM WebSphere MQ 程序，它使用現有傳輸服務諸如 TCP/IP 與 SNA 將消息從本地傳輸隊列移到目標隊列管理器。這些傳輸服務即通道。通道出口是用戶寫入庫，能夠在通道運做期間，從已定義位置號之一進入這些庫。OAM 是命令和對象管理的缺省受權服務（針對操做系統）。這三個組件對 IBM WebSphere MQ 的現有安全性解決方案很是重要。

 

 

 

 

 

 

介紹關於IBM MQSeries的使用指南

文章轉載自網管之家：http://www.bitscn.com/pdb/java/200605/21739.html

　　隨着計算機網絡和分佈式應用的不斷髮展，遠程消息傳遞愈來愈成爲應用系統中不可缺乏的組成部分。商業消息中間件的出現保證了消息傳輸的可靠性，高效率和安全性，同時也減小了系統的開發週期。目前應用最多的消息中間件產品爲IBM MQSeries。本文就針對MQ的基本操做與配置進行詳細的闡述，但願對讀者有所幫助。
　　
　　一．MQ基本操做
　　
　　MQ中有幾個很重要的組件：隊列管理器（QueueManager）、隊列（Queue）和通道（Channel）。其基本的操做方法以下：
　　
　　建立隊列管理器
　　crtmqm ?q QMgrName
　　-q是指建立缺省的隊列管理器
　　
　　刪除隊列管理器
　　dltmqm QmgrName
　　
　　啓動隊列管理器
　　strmqm QmgrName
　　若是是啓動默認的隊列管理器，能夠不帶其名字
　　
　　中止隊列管理器
　　endmqm QmgrName 受控中止
　　
　　endmqm ?i QmgrName 當即中止
　　
　　endmqm ?p QmgrName 強制中止
　　
　　顯示隊列管理器
　　dspmq ?m QmgrName
　　
　　運行MQSeries命令
　　runmqsc QmgrName
　　若是是默認隊列管理器，能夠不帶其名字
　　
　　往隊列中放消息
　　amqsput QName QmgrName
　　若是隊列是默認隊列管理器中的隊列，能夠不帶其隊列管理器的名字
　　
　　從隊列中取出消息
　　amqsget QName QmgrName
　　若是隊列是默認隊列管理器中的隊列，能夠不帶其隊列管理器的名字
　　
　　啓動通道
　　runmqchl ?c ChlName ?m QmgrName
　　
　　啓動偵聽
　　runmqlsr ?t TYPE ?p PORT ?m QMgrName
　　
　　中止偵聽
　　endmqlsr -m QmgrName
　　
　　MQSeries命令
　　
　　定義死信隊列
　　DEFINE QLOCAL（QNAME） DEFPSIST（YES） REPLACE
　　
　　設定隊列管理器的死信隊列
　　ALTER QMGR DEADQ（QNAME）
　　
　　定義本地隊列
　　DEFINE QL（QNAME） REPLACE
　　
　　定義別名隊列
　　DEFINE QALIAS(QALIASNAME) TARGQ(QNAME)
　　
　　遠程隊列定義
　　DEFINE QREMOTE（QRNAME） +
　　RNAME（AAA） RQMNAME（QMGRNAME） +
　　XMITQ（QTNAME）
　　
　　定義模型隊列
　　DEFINE QMODEL（QNAME） DEFTYPE（TEMPDYN）
　　
　　定義本地傳輸隊列
　　DEFINE QLOCAL(QTNAME) USAGE(XMITQ) DEFPSIST(YES) +
　　INITQ（SYSTEM.CHANNEL.INITQ）+
　　PROCESS(PROCESSNAME) REPLACE
　　
　　建立進程定義
　　DEFINE PROCESS（PRONAME） +
　　DESCR（‘STRING’）+
　　APPLTYPE（WINDOWSNT）+
　　APPLICID（’ runmqchl -c SDR_TEST -m QM_ TEST’）
　　其中APPLTYPE的值能夠是：CICS、UNIX、WINDOWS、WINDOWSNT等
　　
　　建立發送方通道
　　DEFINE CHANNEL（SDRNAME） CHLTYPE（SDR）+
　　CONNAME（‘100.100.100.215(1418)’） XMITQ（QTNAME） REPLACE
　　其中CHLTYPE能夠是：SDR、SVR、RCVR、RQSTR、CLNTCONN、SVRCONN、CLUSSDR和CLUSRCVR。
　　
　　建立接收方通道
　　DEFINE CHANNEL（SDR_ TEST） CHLTYPE（RCVR） REPLACE
　　
　　建立服務器鏈接通道
　　DEFINE CHANNEL（SVRCONNNAME） CHLTYPE（SVRCONN） REPLACE
　　
　　顯示隊列的全部屬性
　　DISPLAY QUEUE（QNAME） [ALL]
　　
　　顯示隊列的所選屬性
　　DISPLAY QUEUE（QNAME） DESCR GET PUT
　　DISPLAY QUEUE（QNAME）MAXDEPTH CURDEPTH
　　
　　顯示隊列管理器的全部屬性
　　DISPLAY QMGR [ALL]
　　
　　顯示進程定義
　　DISPLAY PROCESS（PRONAME）
　　
　　更改屬性
　　ALTER QMGR DESCR（‘NEW DESCRIPTION’）
　　ALTER QLOCAL（QNAME） PUT（DISABLED）
　　ALTER QALIAS（QNAME） TARGQ（TARGQNAME）
　　
　　刪除隊列
　　DELETE QLOCAL（QNAME）
　　DELETE QREMOTE（QRNAME）
　　
　　清除隊列中的全部消息
　　CLEAR QLOCAL（QNAME）
　　
　　二．配置一個可以通訊的遠程鏈接
　　
　　以上講述了MQ的基本命令操做，但只知道這些是沒有實際意義的。MQ的最終目的是實現遠程通訊，因此下面就以一個具體的例子來講明如何實現遠程鏈接。這個例子的目的是創建能夠實現消息傳遞的一對MQ服務器，它們分別基於NT和UNIX平臺。
　　
　　首先在NT端建一隊列管理器
　　crtmqm ?q QM_NT
　　
　　啓動隊列管理器
　　strmqm QM_NT
　　
　　運行MQ控制檯命令
　　runmqsc QM_NT
　　
　　建立死信隊列
　　DEFINE QL(NT.DEADQ) DEFPSIST(YES) REPLACE
　　
　　更改隊列管理器屬性，設置其死信隊列
　　ALTER QMGR DEADQ（NT.DEADQ）
　　
　　建立進程定義
　　DEFINE PROCESS（P_NT）+
　　APPLTYPE（WINDOWSNT）+
　　APPLICID（’ runmqchl -c SDR_NT -m QM_NT’）
　　
　　建立本地傳輸隊列
　　DEFINE QL(QT_NT) USAGE(XMITQ) DEFPSIST(YES) +
　　INITQ（SYSTEM.CHANNEL.INITQ）+
　　PROCESS(P_NT) REPLACE
　　
　　建立遠程隊列定義，對應於UNIX機器上的本地隊列Q_UNIX，傳輸隊列爲QT_NT
　　DEFINE QREMOTE（QR_NT）+
　　RNAME（Q_UNIX） RQMNAME（QM_UNIX）+
　　XMITQ（QT_NT）
　　
　　建立發送方通道，其傳輸隊列爲QT_NT，遠程主機地址爲10.10.10.2，偵聽端口爲1414
　　DEFINE CHANNEL（SDR_NT） CHLTYPE（SDR）+
　　CONNAME（‘10.10.10.2(1414)’） XMITQ（QT_NT） REPLACE
　　
　　建立服務器鏈接通道
　　DEFINE CHANNEL（S_NT） CHLTYPE（SVRCONN） REPLACE
　　
　　在UNIX端建立隊列管理器
　　crtmqm ?q QM_UNIX
　　
　　啓動隊列管理器
　　strmqm QM_UNIX
　　
　　添加偵聽程序
　　
　　修改/etc/services文件，加入一行：
　　MQSeries 1414/tcp #MQSeries channel listener
　　
　　修改/etc/inetd.conf文件，加入一行（啓動偵聽程序）
　　MQSeries stream tcp nowait mqm /usr/lpp/mqm/bin/amqcrsta amqcrsta ?m QM_UNIX
　　
　　運行如下命令，以使修改起做用
　　refresh ?s inetd
　　
　　運行MQ控制檯命令
　　runmqsc QM_UNIX
　　
　　建立死信隊列
　　DEFINE QL(UNIX.DEADQ) DEFPSIST(YES) REPLACE
　　
　　更改隊列管理器屬性，設置其死信隊列
　　ALTER QMGR DEADQ（UNIX.DEADQ）
　　
　　建立接收方通道，其名字必須與遠程發送方相同
　　DEFINE CHANNEL（SDR_NT） CHLTYPE（RCVR） REPLACE
　　
　　建立本地隊列
　　DEFINE QL（Q_UNIX） DEFPSIST(YES) REPLACE
　　
　　建立服務器鏈接通道
　　DEFINE CHANNEL（S_UNIX） CHLTYPE（SVRCONN） REPLACE
　　
　　通過以上操做以後，遠程鏈接的配置工做完成。接下來須要驗證配置是否正確。
　　
　　在NT端啓動發送方通道
　　runmqchl ?c SDR_NT ?m QM_NT 或 start chl(SDR_NT)
　　
　　從NT端發送消息到UNIX端
　　amqsput QR_NT QM_NT
　　
　　在UNIX端接收消息
　　/usr/mqm/samp/bin/amqsget Q_UNIX QM_UNIX
　　
　　若能收到消息，說明配置成功。
　　
　　另，在NT下通常狀況下在創建隊列管理器時會自動創建偵聽器，啓動隊列管理器時則會自動啓動偵聽程序。固然也能夠手動配置偵聽程序。
　　
　　修改\winnt\system32\drivers\etc\services文件，在文件中加入一行：
　　
　　MQSeries 1414/tcp #MQSeries channel listener
　　
　　啓動偵聽程序
　　runmqlsr ?t tcp ?p 1414 ?m QM_NT
　　
　　以上說明了怎樣創建簡單的單向傳輸網絡。消息從NT端傳送到UNIX端。創建從UNIX端到NT端的遠程鏈接和以上相仿，要創建雙向的傳輸網絡也是一樣的道理。
　　
　　三．配置JNDI
　　
　　用JMS實現消息的發送和接收時，常常會用到JNDI。由於JNDI這種方式比較靈活，對於編程也比較簡單。
　　在安裝了MQSeries Client for Java以後，在\java\bin目錄下找到JMSAdmin.config文件。該文件主要用來講明Context的存儲方式及存儲地址，對應於文件中的兩個參數INITIAL_CONTEXT_FACTORY和PROVIDER_URL。典型的JMSAdmin.config文件內容以下：
　　
　　#INITIAL_CONTEXT_FACTORY=com.sun.jndi.ldap.LdapCtxFactory
　　INITIAL_CONTEXT_FACTORY=com.sun.jndi.fscontext.RefFSContextFactory
　　#INITIAL_CONTEXT_FACTORY=com.ibm.ejs.ns.jndi.CNInitialContextFactory
　　#
　　#PROVIDER_URL=ldap://polaris/o=ibm,c=us
　　PROVIDER_URL=file:/d:/temp
　　#PROVIDER_URL=iiop://localhost/
　　#
　　SECURITY_AUTHENTICATION=none
　　
　　INITIAL_CONTEXT_FACTORY表示JMSAdmin Tool使用的服務提供商。當前有三種受支持的值。com.sun.jndi.ldap.LdapCtxFactory用於LDAP，若是使用它就必須安裝一個LDAP服務器。com.sun.jndi.fscontext.RefFSContextFactory用於文件系統上下文，它只須要使用者提供存放上下文的文件路徑。com.ibm.ejs.ns.jndi.CNInitialContextFactory是專門爲websphere提供的，它須要和websphere的CosNaming資源庫一塊兒使用。
　　PROVIDER_URL表示會話初始上下文的URL，由JMSAdmin tool實現的全部JNDI操做的根。它和INITIAL_CONTEXT_FACTORY一一對應。
　　
　　ldap://hostname/contextname 用於LDAP
　　file:[drive:]/path

轉自：http://dev.yesky.com/185/7728685.shtm

IBM WebSphere MQ 簡介和概述

　　在開始以前，讓咱們先來肯定使用 WebSphere MQ 解決的業務問題的種類，並瞭解 WebSphere MQ 如何可以幫助您知足業務要求。

　　問題：自動化孤島

　　在大多數業務中，業務的信息技術 (IT) 基礎結構中存在許多不一樣的技術。系統由這些來自許多供應商的不一樣的技術組成，而且具備不一樣的硬件平臺、編程語言、操做系統和通訊鏈路。一般，鏈接不一樣的系統很是複雜而且可能代價高昂，因此許多系統之間都相互隔離。

　　目前，愈來愈多的業務還須要以電子的方式與其客戶和供應商進行通訊，而這些客戶和供應商可能比該業務自己使用了更多不一樣的技術。所以，須要某種簡便的、廉價的和可靠的機制用來鏈接這些異類的系統(「自動化孤島」)，以便在內部和外部對業務的 IT 基礎結構進行集成。

　　解決方案：WebSphere MQ

　　經過提供一種程序到程序的通訊方式，WebSphere MQ 很是適合於上面所描述的環境。圖 1 顯示了這種通訊方式的基本機制。

　　圖 1. 程序到程序的通訊

　　

　　程序 A 準備好一條消息，並將其放入隊列。而後，程序 B 從該隊列中獲取消息，並對其進行處理。這兩個程序都使用一種應用程序編程接口 (API) 與該隊列進行交互。WebSphere MQ API 稱爲消息隊列接口 (MQI)。任何一個程序都無需瞭解對方的存在，而且這兩個程序無需同時執行。若是程序 A 在程序 B 還沒有執行的時候將一條消息放入隊列，那麼該隊列將存儲這條消息，直到程序 B 開始執行並準備處理這條消息。相似地，當程序 B 從隊列中檢索消息時，程序 A 可能已經再也不處於執行狀態。

　　應用程序設計

　　使用 WebSphere MQ 提供的基本通訊機制，能夠進行同步和異步的應用程序設計。

　　在同步的應用程序設計中，如圖 2 所示，假定同時執行這兩個應用程序。程序 A 向隊列 1 發送一條消息並等待應答。程序 B 檢索獲得該消息，並對它進行處理，而後將應答消息發送到隊列 2 中，以便程序 A 進行檢索。在使用 WebSphere MQ 設計應用程序時，一般每一個程序使用不一樣的隊列向其餘程序發送消息。雖然這不是必需的，但這樣能夠提供更簡單的應用程序設計和編程邏輯。另外請記住，這裏假定兩個程序同時執行。若是當程序 A 發送消息時，程序 B 沒有執行，那麼程序 A 將阻塞，直到程序 B 啓動並對消息進行處理。這是同步應用程序通訊中的設計問題。

　　圖 2. 同步應用程序設計

　　

　　在異步應用程序設計中，如圖 3 所示，程序 A 再次將消息放到隊列 1，以便程序 B 對其進行處理，但如今，程序 C 與程序 A 進行異步地操做，它檢索消息並對其進行處理。一般，程序 A 和程序 C 是相同應用程序中的不一樣部分。

　　圖 3. 異步應用程序設計

　　

　　對於 WebSphere MQ 來講，異步設計是一種很是合適的模型。程序 A 將消息放到隊列中，並繼續執行，即便程序 B 並不對這些消息進行處理，也是如此。在這種狀況下，隊列將存儲這些消息，直到程序 B 從新啓動。這種模型有一種變種，即程序 A 將一條或多條消息放到隊列中，並繼續進行其餘的處理，而後返回來檢索和處理應答消息。

　　程序之間的這種通訊方式稱爲消息傳遞。它與其餘通訊方式(如對話式的通訊或調用和返回通訊)的不一樣之處在於，進行通訊的程序之間具備時間獨立性。程序接收消息做爲輸入，並輸出其結果做爲消息，而不須要同時運行發送或接收程序。

　　隊列管理器和 MQI

　　WebSphere MQ 中的隊列由隊列管理器所擁有並進行管理。隊列管理器還爲應用程序提供了MQI API，容許它們訪問隊列以及其中包含的消息。MQI 在 WebSphere MQ 支持的全部平臺中保持一致，並對應用程序隱藏了隊列管理器的實現細節。

　　MQI 中有 8 種主要的調用：

　　MQCONN——鏈接到隊列管理器

　　MQCONNX——使用鏈接選項鍊接到隊列管理器

　　MQDISC——斷開與隊列管理器的鏈接

　　MQOPEN——打開隊列以便進行訪問

　　MQCLOSE——關閉訪問的隊列

　　MQPUT——將一條消息放入隊列

　　MQGET——從隊列中獲取一條消息

　　MQPUT1——打開隊列，放入一條消息，而後關閉該隊列

　　MQI 中有 5 種次要的調用：

　　MQBEGIN——開始一個工做單元

　　MQCMIT——提交一個工做單元

　　MQBACK——回滾一個工做單元

　　MQINQ——查詢 WebSphere MQ 對象(隊列是一種 WebSphere MQ 對象，隊列管理器是另外一種對象)的屬性

　　MQSET——設置 WebSphere MQ 對象的屬性

　　消息

　　WebSphere MQ 中的消息包含兩個部分：WebSphere MQ 使用的 Header 和應用程序數據。圖 4 顯示了一條 WebSphere MQ 消息。

　　圖 4. WebSphere MQ 消息

　　

　　應用程序數據能夠包含任何字節序列。它是使用 WebSphere MQ 與其餘應用程序進行通訊的應用程序所私有的，而且對 WebSphere MQ 沒有什麼意義。對於應用程序數據的內容沒有任何限制，但不一樣的平臺所容許的消息的最大長度有所不一樣。在大多數系統中，最大長度爲 100MB，但有些系統的最大長度爲 4MB。

　　消息中可能包含各類各樣的 Header，但全部的消息都包含一個稱爲消息描述符 (MQMD) 的 Header。其中包含了關於該消息的控制信息，隊列管理器和接收應用程序將使用到這些控制信息。稍後將提供關於 MQMD 和其餘 Header 的更詳細的信息。

　本地和遠程隊列

　　隊列管理器能夠位於相同或不一樣的計算機上，它們能夠彼此通訊，並在不一樣隊列管理器的隊列之間傳遞消息。隊列管理器爲消息提供了可靠的傳遞。例如，當應用程序將消息放入到隊列中時，隊列管理器將確保消息的存儲是安全的、可恢復的，並向接收應用程序傳遞一次且僅傳遞一次，即便必須將消息傳遞到另外一個隊列管理器所擁有的隊列，也是如此。

　　當應用程序打開隊列時，應用程序所鏈接的隊列管理器將肯定該隊列是隊列管理器所擁有的本地隊列，仍是由另外一個隊列管理器所擁有的遠程隊列。對於本地隊列，直接將消息放入到該隊列。若是隊列是遠程的，那麼隊列管理器將消息放到一個稱爲傳輸隊列的特殊隊列。

　　而後，消息通道代理 (MCA) 從傳輸隊列中獲取消息，並將其經過網絡發送到接收端的 MCA。接收 MCA 將該消息放到目標隊列。在將消息放到目標隊列中以後，便將其從傳輸隊列中刪除。消息流在隊列管理器之間能夠是雙向的，如圖 5 中所示。

　　圖 5. 發送消息

　　

　　若是接收MCA 不能將該消息放到目標隊列中，那麼將根據消息描述符中的選項對其進行處理。可能將其放到死信隊列，也可能將其返回給發送者，甚至將其丟棄。

　　經過這種在隊列管理器之間傳遞消息的能力，WebSphere MQ 提供了兩種重要的優勢：

　　應用程序開發人員不須要了解網絡的詳細信息。

　　MCA 可使用各類網絡和通訊協議與其餘的 MCA 相互通訊，而且甚至能夠在一段時間以後更改所使用的協議。可是，應用程序開發人員僅須要瞭解與隊列管理器通訊所需的 MQI 調用。

　　僅須要創建更少的通訊鏈路。

　　許多應用程序使用一個隊列管理器，它們能夠與使用另外一個隊列管理器的應用程序通訊，可是在一對 MCA 之間只須要一條通訊鏈路。

　　設計可能性

　　如今您已經比較清楚地瞭解了 WebSphere MQ 的工做方式，即便僅僅是在概略的層次上，下面讓咱們來看看在使用 WebSphere MQ 設計系統時，應用程序設計的可能性。

　　並行處理

　　要完成整體的業務事務，應用程序可能須要執行多項任務。例如，旅行社可能須要預約航班、預訂酒店房間和預訂出租車。使用 WebSphere MQ，能夠將請求消息放到爲航班預約系統、酒店預訂系統和轎車出租應用程序提供服務的 3 個隊列中。每一個應用程序均可以與其餘兩個應用程序並行地執行本身的任務，而後將應答消息放到旅行社應用程序提供的隊列中。在收到這 3 個應答以後，旅行社應用程序能夠生成綜合的旅行路線。這種並行處理的方式能夠極大地提升總體性能。

　　客戶端/服務器處理

　　另外一種應用程序設計方案是客戶端/服務器處理。在這種狀況下，一臺服務器僅使用一個隊列接收來自多個客戶端應用程序的消息。每一個請求消息的消息描述符能夠指定一個應答隊列。在服務器完成對消息的處理以後，它將應答消息發送到消息描述符中指定的應答隊列，這樣可使得每一個客戶端應用程序相對於其餘客戶端應用程序獨立地接收到其應答消息。

　　消息描述符中還有一個包含消息標識符的字段。應答消息的消息描述符能夠包含對應的請求消息的標識符。這樣作使得客戶端應用程序能夠在應答消息和之前發送的請求消息之間進行關聯。

　　要使用客戶端/服務器處理來提升應用程序的性能和可靠性，可使用多個服務器應用程序實例爲同一個請求隊列服務。

　　觸發

　　WebSphere MQ 能夠在消息放入到隊列中以及某些條件知足時，啓動一個應用程序。這稱爲觸發。下面是觸發的工做方式：

　　程序將消息放入到支持觸發的隊列中。

　　若是觸發的條件知足，則發生觸發事件。

　　隊列管理器檢查應用程序隊列所引用的進程對象。該進程對象指定了須要啓動的應用程序。

　　隊列管理器建立包含關於進程對象和隊列的信息的觸發消息。

　　將該觸發消息放到啓動隊列。

　　由一個稱爲觸發監視器的程序負責檢索消息，並啓動合適的應用程序，將觸發消息的信息傳遞給這個應用程序。

　　當第一次將消息放到隊列中時、當隊列中包含的消息達到某個數目時、或者每次將消息放到隊列中時，均可能發生觸發事件，儘管最後這種狀況一般不推薦使用。

　　數據完整性

　　有些應用程序使用會話式的程序到程序的通訊方式，以使用兩段式提交協議來支持分佈式工做單元的實現，如圖 6 中所示。

　　圖 6. 同步分佈式工做單元

　　

　　這種功能僅在下面的狀況下須要使用，業務要求在任什麼時候刻都必須很是精確地維護兩個分佈式數據庫之間的一致性。在實際中，這種類型的需求不多出現。當這種需求的確存在時，單個分佈工做單元可能使用許多資源，而且變得很是複雜，尤爲是當涉及到許多處理時。

　　WebSphere MQ 提供了一種更簡單的解決方案，使得多個工做單元能夠異步執行，如圖 7 中所示。

　　圖 7. 異步分佈式工做單元

　　

　　第一個應用程序寫入數據庫，將包含對其餘系統中的第二個數據庫進行更新所需數據的消息放到隊列中，而後提交對這兩種資源的更改。由於該隊列是遠程的，因此消息僅進入第一個工做單元的傳輸隊列。

　　第二個工做單元包含發送 MCA 從傳輸隊列中獲取該消息，並將其發送給接收MCA，然後者負責將該消息放到目標隊列。

　　在第三個工做單元中，第二個應用程序從目標隊列中獲取該消息，並使用該消息中包含的數據對數據庫進行更新。

　　工做單元 1 和 3 的事務完整性，加上工做單元 2 中由 WebSphere MQ 提供的消息的一次且僅一次的可靠傳遞，從而確保了整個業務事務的完整性。

　　安全性

　　WebSphere MQ 中的安全特性包括：

　　隊列管理器可檢查某個用戶是否通過受權能夠提交管理隊列管理器的命令。

　　隊列管理器可檢查某個用戶或應用程序是否通過受權能夠在指定的操做中訪問 WebSphere MQ 資源，如隊列。

　　在容許 MCA 之間進行消息通訊以前，MCA 能夠對合做夥伴 MCA 進行身份驗證。

　　能夠在 MCA 發送消息以前對其進行加密，而後在接收到該消息以後再對其進行解密。

　　消息描述符能夠包含用戶 ID 和關於消息發出者的其餘信息。這種信息稱爲消息上下文，它能夠用來對消息進行身份驗證，並檢查該消息的發送者是否通過受權能夠訪問接收系統中的 WebSphere MQ 資源。

　　WebSphere MQ 客戶端

　　WebSphere MQ 客戶端能夠安裝在沒有運行隊列管理器的系統中。客戶端能夠將在同一系統中運行的應用程序做爲WebSphere MQ 客戶端，以鏈接到運行於另外一個系統中的隊列管理器，並向該隊列管理器發出MQI 調用。這種應用程序稱爲 WebSphere MQ 客戶端應用程序，而這種隊列管理器稱爲服務器隊列管理器。圖 8 顯示了這種配置。

　　圖 8. 客戶端和服務器之間的連接

　　

　　WebSphere MQ 客戶端應用程序和服務器隊列管理器使用MQI 通道實現彼此之間的通訊。當客戶端應用程序發出 MQCONN 或 MQCONNX 調用時啓動 MQI 通道，當客戶端應用程序發出 MQDISC 調用時結束該通道。

　　要使 WebSphere MQ 客戶端進行有效地處理，須要快速的和可靠的同步通訊鏈接。

　　WebSphere MQ Framework

　　用戶和軟件供應商可使用已定義的接口來擴展或替換隊列管理器功能。WebSphere MQ Framework 提供了這樣的接口。

　　WebSphere 容許對各類功能進行修改，以便：

　　提供選擇是否使用 WebSphere MQ 所提供的組件、或對其進行替換、或使用其餘的組件對其進行擴充的靈活性。

　　容許獨立的軟件供應商經過提供其餘新技術所使用的組件，從而參與其中，無需對 WebSphere MQ 內部的內容進行更改。

　　容許 WebSphere MQ 更快地利用各類新技術，從而更迅速地提供相關產品。

　　WebSphere MQ Framework 中的組件包括：

　　觸發監視器接口 (TMI)

　　消息通道接口 (MCI)

　　名稱服務接口 (NSI)

　　安全支持接口 (SEI)

　　數據轉換接口 (DCI)