【轉】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/%D2%BB%D2%B9%CA%AE%D2%BB%C0%C7/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換成一個中心節點,即ESBMB即是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/%CC%EC%B2%C5%B0%AE%CC%EC/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/2、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. 程序到程序的通信

  p1

  程序 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. 同步應用程序設計

  p2

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

  圖 3. 異步應用程序設計

  p3

  對於 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 消息

  p4

  應用程序數據可以包含任何字節序列。它是使用 WebSphere MQ 與其他應用程序進行通信的應用程序所私有的,並且對 WebSphere MQ 沒有什么意義。對於應用程序數據的內容沒有任何限制,但不同的平台所允許的消息的最大長度有所不同。在大多數系統中,最大長度為 100MB,但有些系統的最大長度為 4MB。

  消息中可能包含各種各樣的 Header,但所有的消息都包含一個稱為消息描述符 (MQMD) 的 Header其中包含了關於該消息的控制信息,隊列管理器和接收應用程序將使用到這些控制信息。稍后將提供關於 MQMD 和其他 Header 的更詳細的信息。

 本地和遠程隊列

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

  當應用程序打開隊列時,應用程序所連接的隊列管理器將確定該隊列是隊列管理器所擁有的本地隊列,還是由另一個隊列管理器所擁有的遠程 隊列。對於本地隊列,直接將消息放入到該隊列。如果隊列是遠程的,那么隊列管理器將消息放到一個稱為傳輸隊列的特殊隊列。

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

  圖 5. 發送消息

  p5

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

  通過這種在隊列管理器之間傳遞消息的能力,WebSphere MQ 提供了兩種重要的優點:

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

  MCA 可以使用各種網絡和通信協議與其他的 MCA 相互通信,並且甚至可以在一段時間之后更改所使用的協議。但是,應用程序開發人員僅需要了解與隊列管理器通信所需的 MQI 調用。

  僅需要建立更少的通信鏈路。

  許多應用程序使用一個隊列管理器,它們可以與使用另一個隊列管理器的應用程序通信,但是在一對 MCA 之間只需要一條通信鏈路。

  設計可能性

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

  並行處理

  要完成總體的業務事務,應用程序可能需要執行多項任務。例如,旅行社可能需要預定航班、預訂酒店房間和預訂出租車。使用 WebSphere MQ,可以將請求消息放到為航班預定系統、酒店預訂系統和轎車出租應用程序提供服務的 3 個隊列中。每個應用程序都可以與其他兩個應用程序並行地執行自己的任務,然后將應答消息放到旅行社應用程序提供的隊列中。在收到這 3 個應答之后,旅行社應用程序可以生成綜合的旅行路線。這種並行處理的方式可以極大地提高整體性能。

  客戶端/服務器處理

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

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

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

  觸發

  WebSphere MQ 可以在消息放入到隊列中以及某些條件滿足時,啟動一個應用程序。這稱為觸發。下面是觸發的工作方式:

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

  如果觸發的條件滿足,則發生觸發事件

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

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

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

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

  當第一次將消息放到隊列中時、當隊列中包含的消息達到某個數目時、或者每次將消息放到隊列中時,都可能發生觸發事件,盡管最后這種情況通常不推薦使用。

  數據完整性

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

  圖 6. 同步分布式工作單元

  p6

  這種功能僅在下面的情況下需要使用,業務要求在任何時刻都必須非常精確地維護兩個分布式數據庫之間的一致性。在實際中,這種類型的需求很少出現。當這種需求的確存在時,單個分布工作單元可能使用許多資源,並且變得非常復雜,尤其是當涉及到許多處理時。

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

  圖 7. 異步分布式工作單元

  p7

  第一個應用程序寫入數據庫,將包含對其他系統中的第二個數據庫進行更新所需數據的消息放到隊列中,然后提交對這兩種資源的更改。因為該隊列是遠程的,所以消息僅進入第一個工作單元的傳輸隊列。

  第二個工作單元包含發送 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. 客戶端和服務器之間的鏈接

  p8

  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)


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM