機(jī)場信息化建設(shè)ESB的設(shè)計(jì)

1、 機(jī)場信息化建設(shè)ESB的設(shè)計(jì)概述現(xiàn)代機(jī)場信息化建設(shè)中存在多則幾十個不同的業(yè)務(wù)系統(tǒng)，不同的業(yè)務(wù)系統(tǒng)往往由不同的公司采用不同的標(biāo)準(zhǔn)、不同的接口開發(fā)而成，這些業(yè)務(wù)系統(tǒng)之間存在大量的數(shù)據(jù)交換，在涉及不同業(yè)務(wù)系統(tǒng)之間數(shù)據(jù)交換時，就必須用到EAI技術(shù)，在當(dāng)前SOA架構(gòu)下的EAI與傳統(tǒng)的EAI又有所不同，SOA下的EAI技術(shù)是采用企業(yè)服務(wù)總線ESB的方式，并采用統(tǒng)一的標(biāo)準(zhǔn)接口連接不同的業(yè)務(wù)系統(tǒng)。在機(jī)場信息化建設(shè)中有兩個主要的業(yè)務(wù)模型，一類是發(fā)布/訂閱，另一類是請求回復(fù)，針對這類業(yè)務(wù)模型，我們選用IBM公司的ESB產(chǎn)品WebSphereMessageBroker和WebSphereMQ來構(gòu)建機(jī)場信息化建設(shè)的企

2、業(yè)服務(wù)總線（ESB）平臺，并介紹設(shè)計(jì)過程。企業(yè)服務(wù)總線ESB的演變企業(yè)服務(wù)總線ESB來源于EAI技術(shù)，EAI發(fā)展到ESB經(jīng)歷過三個階段：定制連接，兩兩互連最早期的EAI解決方案就是將企業(yè)中需要互通信息，共享數(shù)據(jù)的系統(tǒng)兩兩橋接起來。橋接的技術(shù)也是為兩個特定系統(tǒng)專門定制通訊鏈路來轉(zhuǎn)換這兩個系統(tǒng)的接口，協(xié)議以及數(shù)據(jù)格式等差異。應(yīng)用應(yīng)用應(yīng)用應(yīng)甬應(yīng)用應(yīng)弔應(yīng)用圖1傳統(tǒng)點(diǎn)對點(diǎn)模式缺點(diǎn)：全部使用專門為兩個特定系統(tǒng)定制的連接，在企業(yè)系統(tǒng)眾多的情況下連接急劇增加，難以開發(fā)，后期維護(hù)更加困難。劇GartnerGroup在2003年4月發(fā)布的調(diào)查結(jié)果顯示，大約有35%的企業(yè)軟件預(yù)算用于維護(hù)大量已經(jīng)存在的點(diǎn)對點(diǎn)應(yīng)用連接

3、上。CIOInsight在2003年2月也提出了類似觀點(diǎn)，他們發(fā)現(xiàn)維護(hù)和管理這些點(diǎn)對點(diǎn)連接平均用去企業(yè)IT預(yù)算的29%。由于這些專用連接完全互相獨(dú)立，其只能滿足系統(tǒng)兩兩互連通訊的需求，無法實(shí)現(xiàn)涉及多個應(yīng)用系統(tǒng)的復(fù)雜業(yè)務(wù)流程。星型(Hub/Spoke)架構(gòu)適配器a適配器芒數(shù)據(jù)應(yīng)程序+J應(yīng)弔程序屮集成中心心適配器屮適配器4資源中心d應(yīng)壬程序4圖2由于兩兩互連方式具有上述明顯缺陷，星型架構(gòu)的解決方案應(yīng)運(yùn)而生。該方式提供一個應(yīng)用集成中心(hub)，這個中心具有自己的連接協(xié)議，所有需要集成的系統(tǒng)(spoke)都和該中心相連,同時，該集成中心往往通常也作為某個核心業(yè)務(wù)系統(tǒng)。原來用戶每集成一個系統(tǒng)，都要考慮

4、改系統(tǒng)和其他所有系統(tǒng)的點(diǎn)對點(diǎn)連接的協(xié)議數(shù)據(jù)結(jié)構(gòu)的轉(zhuǎn)換，而在星型架構(gòu)下，用戶只需要考慮系統(tǒng)和集成中心的點(diǎn)對點(diǎn)連接上轉(zhuǎn)換。這樣，原來n個系統(tǒng)之間的n*(n-l)/2個點(diǎn)對點(diǎn)連接減少為n個連接。缺點(diǎn)：集中式的結(jié)構(gòu)容易造成效率瓶頸，同時存在單點(diǎn)失效的問題。一旦Server崩潰后，整個系統(tǒng)就都不能運(yùn)行了。在這種模式下，要達(dá)到系統(tǒng)的可擴(kuò)展性只有通過加入多集成Server，這樣就造成了附加的結(jié)構(gòu)和管理上的復(fù)雜度。同時，對Hub、適配器、工作流的編程與管理較為昂貴，且重用性較低?？偩€型架構(gòu)隨著IT技術(shù)的發(fā)展，企業(yè)應(yīng)用集成的需求急劇增加，上述樸素的星型結(jié)構(gòu)已不能很好的滿足這些需求，總線型企業(yè)服務(wù)總線(Enter

5、priseServiceBus)的體系結(jié)構(gòu)逐漸浮出水面。這種體系結(jié)構(gòu)繼承了星型(hub-spoke)式體系結(jié)構(gòu)將各個系統(tǒng)點(diǎn)對點(diǎn)連接轉(zhuǎn)化為多個系統(tǒng)對中心的連接的理念。但在這種體系結(jié)構(gòu)中，集成中心被擴(kuò)展成可以分布在多個物理節(jié)點(diǎn)上的總線，從而有效解決了中心輻條模式的單點(diǎn)失效和效率問題。圖3總線型架構(gòu)ESB/EAI解決方案ESB技術(shù)并不僅僅是簡單的將集成中心被擴(kuò)展成總線。企業(yè)服務(wù)總線本身提供各種消息路由，數(shù)據(jù)轉(zhuǎn)換等各種EAI模式的支持。這種總線一般以成熟的應(yīng)用集成中間件作為其物理消息傳遞背板，保證消息在分布式環(huán)境下可靠高效的傳輸。同時，企業(yè)服務(wù)總線作為應(yīng)用集成系統(tǒng)的基礎(chǔ)框架，大多數(shù)采用面向組件的技術(shù)，

6、這實(shí)際上是SOA的雛形。與Hub-and-Spoke結(jié)構(gòu)相比，總線結(jié)構(gòu)的可擴(kuò)展性更好，并且能提供更好的性能表現(xiàn)。由于采用總線形結(jié)構(gòu)，當(dāng)要集成進(jìn)一個新的應(yīng)用時，只要加上一個Adapte插入總線即可，可以做到類似即插即用的功能。對于消息的傳送來說，集成Server只是起到一個控制的作用，真正的傳輸是在信息總線上，這樣集成Server的負(fù)荷就輕了許多。另外，ESB體系機(jī)構(gòu)中往往包含商業(yè)流程管理（BPM）和商業(yè)活動監(jiān)控（BAM）模塊的實(shí)現(xiàn)。BPM作為ESB的消費(fèi)者，可以將總線上的各個服務(wù)（或組件，適配器等）按照用戶需要的商業(yè)邏輯組裝起來，使這些服務(wù)按照業(yè)務(wù)邏輯順序執(zhí)行，從而實(shí)現(xiàn)用戶完整的業(yè)務(wù)功能。而B

7、AM提供對整個ESB,ESB上的服務(wù)和BPM的運(yùn)行狀態(tài)進(jìn)行監(jiān)控和管理。SOA（面向服務(wù)的體系架構(gòu)）業(yè)務(wù)服務(wù)流程服務(wù)4信息服務(wù)屮JL1訪問服知合作伙伴服務(wù)=應(yīng)用程序服務(wù)管理服務(wù)開發(fā)服務(wù)H基礎(chǔ)結(jié)構(gòu)服務(wù)圖4面向服務(wù)的體系架構(gòu)面向服務(wù)的體系架構(gòu)（ServiceOrientedArchitecture）是目前EAI領(lǐng)域最先進(jìn)的體系結(jié)構(gòu)。實(shí)際上，SOA的提出在很大程度上就是為了更好的滿足企業(yè)應(yīng)用集成的需求。SOA強(qiáng)調(diào)復(fù)用和松偶合，注重接口及其標(biāo)準(zhǔn)化描述，這些都為企業(yè)應(yīng)用集成規(guī)劃了非常好的框架體系結(jié)構(gòu)。除了具有前面ESB結(jié)構(gòu)的優(yōu)點(diǎn)之外，基于SOA的應(yīng)用集成系統(tǒng)具有更好的可擴(kuò)展性和靈活性，用戶可以在對已有系統(tǒng)

8、影響最小的情況下開發(fā)應(yīng)用新的業(yè)務(wù)模塊（服務(wù)）或修改已有模塊，從而快速滿足業(yè)務(wù)需求的變化。本質(zhì)上說，SOA架構(gòu)對應(yīng)用集成的基本要求有以下幾點(diǎn)：SOA在相對較粗的粒度上對應(yīng)用服務(wù)或業(yè)務(wù)模塊進(jìn)行封裝與重用。這是對服務(wù)提供者本身的要求。服務(wù)間保持松散耦合，基于開放的標(biāo)準(zhǔn)，服務(wù)的接口描述與具體實(shí)現(xiàn)無關(guān)。這是從服務(wù)消費(fèi)者的角度應(yīng)該看到（了解）的服務(wù)提供者的樣子。靈活的架構(gòu)-服務(wù)的實(shí)現(xiàn)細(xì)節(jié)，服務(wù)的位置乃至服務(wù)請求的底層協(xié)議都應(yīng)該透明。這是對服務(wù)消費(fèi)者消費(fèi)服務(wù)提供者提供的服務(wù)的方式的要求。基于SOA架構(gòu)的EAI產(chǎn)品一般使用企業(yè)服務(wù)總線（ESB）來滿足（實(shí)現(xiàn)）這一要求?？梢钥吹?，SOA的體系結(jié)構(gòu)一般來說也需要企

9、業(yè)服務(wù)總線的支撐，只是它對總線上的服務(wù)和總線本身的作用和位置有著更加明確的要求。好的符合SOA的EAI系統(tǒng)也同樣整合了對BPM和BAM的支持。這里特別要指出的是，在符合SOA的EAI系統(tǒng)中對BPM的支持具有更多優(yōu)點(diǎn)。在傳統(tǒng)ESB系統(tǒng)中，BPM往往是廠家相關(guān)的專門模塊,這一模塊存在于ESB之上并且是不可替換的。而在符合SOA的EAI系統(tǒng)中，BPM模塊也作為一種服務(wù)（編排服務(wù)）其本質(zhì)上和其他服務(wù)沒有差別，這使得用戶選擇多種服務(wù)編排方式（即不同的BPM實(shí)現(xiàn)）成為可能?，F(xiàn)代機(jī)場信息化建設(shè)需求現(xiàn)代民航機(jī)場信息化建設(shè)的需求越來越緊迫，縱觀國內(nèi)整個民航業(yè)的各個主要環(huán)節(jié)，機(jī)場的信息化程度相對較差。從2006年

10、起，機(jī)場對于信息化建設(shè)的水準(zhǔn)更加重視，開始重視市場營銷，通過整合電子商務(wù)、離港、旅客、氣象等系統(tǒng)的數(shù)據(jù)，提升調(diào)配資源和管理水平。2006年呈現(xiàn)的趨勢表明，機(jī)場信息化的建設(shè)正在從運(yùn)營信息化向管理信息化發(fā)展，其中一個標(biāo)志就是機(jī)場的數(shù)據(jù)整合正在逐漸展開，即通過企業(yè)服務(wù)總線把機(jī)場各系統(tǒng)中的分散的數(shù)據(jù)整合起來，從而為提升管理信息化的水平打下基礎(chǔ)。機(jī)場ESB信息建設(shè)需要整合的系統(tǒng)有生產(chǎn)系統(tǒng)、航顯系統(tǒng)、離港系統(tǒng)、安檢系統(tǒng)、廣播系統(tǒng)、閉路電視系統(tǒng)、內(nèi)通系統(tǒng)、樓控系統(tǒng)、停車場系統(tǒng)、Internet系統(tǒng)、時鐘系統(tǒng)、行李系統(tǒng)、機(jī)場GIS系統(tǒng)、氣象系統(tǒng)、電子商務(wù)系統(tǒng)。這些系統(tǒng)的建設(shè)年代、所用的技術(shù)標(biāo)準(zhǔn)、應(yīng)用程序接口方

11、式和數(shù)據(jù)格式都存在不統(tǒng)一的問題，各信息系統(tǒng)成為一個個的信息孤島，為提高機(jī)場運(yùn)行效率，這些IT系統(tǒng)需要進(jìn)行信息整合，利用IBMWebSphereMessageBrokerV6.x可以很好地滿足這種需求，實(shí)現(xiàn)如下幾個功能：協(xié)議轉(zhuǎn)換數(shù)據(jù)格式轉(zhuǎn)換數(shù)據(jù)路由事件與事務(wù)的支持機(jī)場信息ESB的設(shè)計(jì)4.1概述根據(jù)機(jī)場信息化應(yīng)用的具體需求，我們設(shè)計(jì)了兩種ESB功能應(yīng)用，分別是PUB/SUB和請求/回復(fù)，根據(jù)這種應(yīng)用，ESB架構(gòu)設(shè)計(jì)如圖5所示內(nèi):圖5-eSb乙臺總臺總ESB應(yīng)用服務(wù)總線平臺USIRSEEDERCUNPKjMAJsHjERrxtrUTftiRin.r應(yīng)用整合層WebSphereMB悟息交互層整個ESB

12、的功能架構(gòu)在邏輯上分為兩層，即信息交互層，應(yīng)用整合層。其中：信息交互層：采用ESB適配器針對企業(yè)現(xiàn)有的大量應(yīng)用和數(shù)據(jù)，提供接入服務(wù)，簡單的說就是為各應(yīng)用系統(tǒng)、弱電子系統(tǒng)、外部系統(tǒng)提供與ESB的接口。具體實(shí)現(xiàn)擬采用消息中間件WebsphereMQ6.0作為ESB平臺的基礎(chǔ)平臺。應(yīng)用整合層：在信息交互層能夠滿足機(jī)場內(nèi)各類交互的基礎(chǔ)之上，進(jìn)一步對機(jī)場各應(yīng)用系統(tǒng)、弱電子系統(tǒng)、外部系統(tǒng)在信息、應(yīng)用上進(jìn)行整合，完成各類信息在交互過程中涉及的格式轉(zhuǎn)換、內(nèi)容路由等問題，在提高信息交互層性能的同時，基于面向服務(wù)的思想構(gòu)建信息流程，為機(jī)場實(shí)施業(yè)務(wù)流程整合以及門戶整合預(yù)留接口。其實(shí)現(xiàn)主要通過IBM中間件IBMWeb

13、SphereMessageBroker，其應(yīng)用模式主要采用發(fā)布/訂閱(PUB/SUB)模式，請求/應(yīng)答模式(REQ/RESP)以及可定制的服務(wù)單元模式。4.2實(shí)現(xiàn)模式發(fā)布/訂閱模式發(fā)布/訂閱模式是消息應(yīng)用程序的一種，在這種模式下消息的發(fā)布者與消息的訂閱者之間的關(guān)系是松耦合的。在發(fā)布/訂閱系統(tǒng)中，發(fā)布者不需要知道誰會來使用它所提供的信息，而且訂閱者也不需要知道誰來提供它需要的信息源。而對比其它應(yīng)用模式，發(fā)送消息的應(yīng)用程序需要知道消息所發(fā)往的目的地。所以說，在發(fā)布/訂閱模式下，可以使系統(tǒng)動態(tài)地增長或縮減。通過WEBSPHERMESSAGEBROKER實(shí)現(xiàn)PUB/SUB主要涉及到以下幾個概念：發(fā)布者

14、(Publisher)：信息的提供者被叫做發(fā)布者。發(fā)布者為每個消息都賦予一個主題，但他并不知道目的應(yīng)用對哪種主題的消息感興趣。訂閱者(Subscriber)：訂閱者決定它對哪種主題的信息感興趣，然后接收該主題的消息。每個訂閱者可以從多個消息發(fā)布者得到消息，他們收到消息也可以發(fā)布給其他的訂閱者。主題(Topic)：發(fā)布者和訂閱者之間通過主題來建立聯(lián)系。用于PUB/SUB目的的消息都要求有一個主題。代理(Broker)：代理負(fù)責(zé)發(fā)布者和訂閱者之間的交互工作。它從發(fā)布者那里接收消息，從訂閱者那里得到訂閱消息的請求，然后負(fù)責(zé)把消息從前者到后者的路由。在一個大的系統(tǒng)中的某些子系統(tǒng)，在不確定從何處接收消息

15、或發(fā)送消息的時候，在復(fù)雜的應(yīng)用場合中，通訊程序之間不僅是一對一的關(guān)系，還可以是一對多或多對一，甚至是多對多的關(guān)系，那么在這樣復(fù)雜的情況下，通訊的連接增加了程序復(fù)雜性，所以可以在系統(tǒng)中使用發(fā)布/訂閱模式，來對用戶屏蔽掉多變的連接的情況，使應(yīng)用程序更為簡單，屏蔽掉了網(wǎng)絡(luò)的變化，并且提供了更大的網(wǎng)絡(luò)獨(dú)立性。而且由于減少了通訊連接，那么也使系統(tǒng)更加容易來管理。PUB/SUB的原理是：一個發(fā)布會被發(fā)布者發(fā)送到代理上，一個訂閱會從訂閱者發(fā)送到代理上，并且發(fā)布也會從代理上發(fā)送到訂閱者上。而且在一個典型的發(fā)布/訂閱系統(tǒng)是包含有多個發(fā)布者和多個訂閱者的，甚至有多個代理(這是考慮到連接性能的時候需要的)，還有可能

16、一個應(yīng)用既是發(fā)布者又是訂閱者，那么在這種情況下，發(fā)布/訂閱的系統(tǒng)架構(gòu)一般是下面圖所示：訂閱君加X1SG2主題-X1SGL發(fā)布者1發(fā)布者加發(fā)布者卻XlSGlMSG3*訂閱者2代理+訂閱若畀圖6發(fā)布/訂閱模式該應(yīng)用模式是機(jī)場內(nèi)各類應(yīng)用系統(tǒng)信息交互的主要應(yīng)用模式，以航班動態(tài)發(fā)布為例：生產(chǎn)系統(tǒng)應(yīng)用程序通過適配器將航班動態(tài)消息發(fā)送至信息交互層，而無需指定消息的使用者航顯、行李等其它應(yīng)用系統(tǒng)可通過信息交互層向應(yīng)用整合層訂閱航班計(jì)劃，一旦訂閱成功，則每當(dāng)生產(chǎn)系統(tǒng)發(fā)布了航班動態(tài)，航顯、行李等系統(tǒng)將會自動接收到該航班動態(tài)信息的副本，而對于這些系統(tǒng)也無需知道該消息的源頭。請求/回復(fù)模式請求/回復(fù)模式包括兩個過程：

17、一是發(fā)送消息并期待回復(fù)（換言之，就是發(fā)送請求消息，也可通過發(fā)布過程發(fā)送請求），另一則是在收到請求消息后發(fā)送回復(fù)消息。系統(tǒng)或應(yīng)用程序發(fā)出請求消息并等待回復(fù)消息。響應(yīng)方使用請求消息，生成一個回復(fù)消息，再將其送回發(fā)起方。發(fā)起方收到回復(fù)消息時就標(biāo)志著消息流的完成。請求/回復(fù)模式在本架構(gòu)的應(yīng)用，MQSeries提供了利用關(guān)聯(lián)性ID識別請求消息及其回復(fù)消息的便利。關(guān)聯(lián)性ID由發(fā)出請求消息的應(yīng)用程序進(jìn)行設(shè)置。生成回復(fù)消息的應(yīng)用程序?qū)㈥P(guān)聯(lián)性ID從請求消息中拷貝到回復(fù)消息中，并將其送回原先發(fā)出請求消息的應(yīng)用程序。發(fā)送請求消息的應(yīng)用程序可以利用關(guān)聯(lián)性ID將回復(fù)消息映射到請求早先發(fā)出的消息上。在這個模式中，請求和響

18、應(yīng)是單個請求答復(fù)操作內(nèi)定義的兩條消息，并作為兩個獨(dú)立無關(guān)的傳輸層傳送發(fā)送。REPLY!艾題應(yīng)用KEQL+-1應(yīng)用加KEQ2REPLYIp應(yīng)用3代理*應(yīng)用加圖7請求/回復(fù)模式該應(yīng)用模式作為發(fā)布/訂閱模式的補(bǔ)充，將有效解決特定情況下可能產(chǎn)生的消息丟失或信息不同步而給應(yīng)用系統(tǒng)帶來的影響。以航班狀態(tài)為例，生產(chǎn)系統(tǒng)針對當(dāng)天的某一航班會根據(jù)航班狀態(tài)發(fā)布多條狀態(tài)信息，此時，對于當(dāng)前的應(yīng)用系統(tǒng)（如航顯）即可逐條接收航班狀態(tài)信息，也可通過請求的方式向信息交互層發(fā)送請求信息，生產(chǎn)系統(tǒng)收到該請求信息后，將會把該航班的最新的航班動態(tài)發(fā)送至該應(yīng)用系統(tǒng)。該模式可有效解決機(jī)場內(nèi)各應(yīng)用系統(tǒng)數(shù)據(jù)不同步等問題?？啥ㄖ频姆?wù)單元模

19、式為了使機(jī)場業(yè)務(wù)環(huán)境具有靈活的基礎(chǔ)架構(gòu)和處理環(huán)境，EAI平臺還需要支持面向SOA擴(kuò)展的能力，為此，自需求分析、信息交互平臺的設(shè)計(jì)、消息格式的定義都必須考慮到未來的擴(kuò)展，達(dá)到機(jī)場各應(yīng)用系統(tǒng)之間最大程度的松耦合，我們可運(yùn)用WebSphereMB高效的消息格式轉(zhuǎn)化、消息路由等功能，采用面向服務(wù)的設(shè)計(jì)思想，將現(xiàn)有業(yè)務(wù)定義為一個個獨(dú)立的“原子服務(wù)”（最小功能集），通過對“原子服務(wù)”進(jìn)行組合構(gòu)造“組合服務(wù)”，通過“服務(wù)字典”查詢相關(guān)服務(wù)的定義，隨著業(yè)務(wù)的更改或者客戶對服務(wù)需求的變更，原先定義的原子服務(wù)并不需要變更，只需將變化后的服務(wù)重新組裝、或在現(xiàn)有組合服務(wù)的基礎(chǔ)之上修改成為新的“組合服務(wù)”既可。如：將生

20、產(chǎn)系統(tǒng)的進(jìn)港航班和出港航班動態(tài)發(fā)布分別定義為一個獨(dú)立的原子服務(wù)，航班動態(tài)發(fā)布定義為一個包含進(jìn)港航班和出港航班的組合服務(wù)。對于只關(guān)心出港航班的應(yīng)用系統(tǒng)（如行李系統(tǒng)）只需請求一個原子服務(wù)，即出港航班動態(tài)發(fā)布，而對于即關(guān)心出港，又關(guān)心進(jìn)港航班的應(yīng)用系統(tǒng)(如航顯系統(tǒng))在請求時，指定請求的是“航班動態(tài)”，請求發(fā)送后，EAI應(yīng)用集成平臺會通過查詢服務(wù)字典獲得這項(xiàng)組合服務(wù)的定義，然后并行的通過兩條數(shù)據(jù)傳輸消息流將其所需要的進(jìn)港及出港航班動態(tài)信息獲得并傳輸給航顯系統(tǒng)。圖8可訂制的服務(wù)單元應(yīng)用架構(gòu)功能組件信息交互層信息交互層采用IBMWebsphereMQ開發(fā)，MQ是IBM功能強(qiáng)大的消息傳送中間件產(chǎn)品，它以其成

21、熟的技術(shù)和世界領(lǐng)先的產(chǎn)品向我們提供了在今天異構(gòu)網(wǎng)絡(luò)環(huán)境中實(shí)現(xiàn)消息傳送的經(jīng)濟(jì)、可靠且易于使用的解決方案。它是目前唯一能保證您的數(shù)據(jù)穩(wěn)定可靠而且無丟失或重發(fā)的產(chǎn)品，曾被PCMAGAZINE譽(yù)為：MQ是世界上最成功的軟件之一。目前市場占有率為消息類中間件的87%，已經(jīng)成為事實(shí)上的行業(yè)標(biāo)準(zhǔn)。在企業(yè)的各類應(yīng)用中承擔(dān)了可靠的信息數(shù)據(jù)傳輸?shù)幕A(chǔ)支撐。MQ基本由一個信息傳輸系統(tǒng)和一個應(yīng)用程序接口組成，其資源是信息和隊(duì)列(MessagingandQueuing)。信息:一個信息包含兩個因素：信息描述(用于定義諸如信息傳輸目標(biāo)等)和數(shù)據(jù)信息(如應(yīng)用程序數(shù)據(jù)或數(shù)據(jù)庫查詢等)。程序之間的通訊通過傳遞信息而非直接調(diào)用程

22、序。隊(duì)列:一個安全的信息存儲區(qū)。因?yàn)樾畔⒋娣旁陉?duì)列中，所以應(yīng)用程序可以相互獨(dú)立的運(yùn)行，以不同的速度，在不同的時間，在不同的地點(diǎn)。信息傳輸系統(tǒng)：用于確保隊(duì)列之間的信息提供，包括網(wǎng)絡(luò)中不同系統(tǒng)上的遠(yuǎn)程隊(duì)列之間的信息提供。并保證網(wǎng)絡(luò)故障或關(guān)閉后的恢復(fù)。應(yīng)用程序接口：應(yīng)用程序和信息系統(tǒng)之間通過MQSeriesAPI實(shí)現(xiàn)的接口MQSeriesAPI在所有MQSeries平臺上是一致的。API只有11個調(diào)用，2個關(guān)鍵動詞：發(fā)送(PUT)和接收(GET)。在信息交互層各應(yīng)用系統(tǒng)采用客戶端/服務(wù)器的模式與WebsphereMQ服務(wù)器相連，客戶端使用MQ動態(tài)鏈接庫開發(fā)或采用相應(yīng)的適配器，通過MQI，或JMS接口

23、訪問WebsphereMQServer上的消息隊(duì)列。如下圖所示。圖9MQ客戶端/服務(wù)器應(yīng)用應(yīng)用整合層應(yīng)用整合層主要通過IBMWebSphereMessageBroker實(shí)現(xiàn)，MESSAGEBROKER采用WebSphereMQ提供的可靠消息服務(wù)(不丟失，不復(fù)傳)在應(yīng)用系統(tǒng)之間通過基于消息的異步方式集成各應(yīng)用系統(tǒng)。針對不同系統(tǒng)所處理的消息格式各不相同的特點(diǎn)，MESSAGEBROKER提供了專門的格式代碼轉(zhuǎn)換器(Formatter)在不同的消息格式之間按照預(yù)先定義好的轉(zhuǎn)換規(guī)則進(jìn)行自動的格式轉(zhuǎn)換，然后將結(jié)果自動路由到目標(biāo)應(yīng)用系統(tǒng)。在消息轉(zhuǎn)換的過程中MESSAGEBROKER能夠識別XML,C結(jié)構(gòu),JMS,SOAP等多種消息格式；對消息的各種操作包括消息的來源、消息的目標(biāo)應(yīng)用、所期望的消息格式等通過定義各種操作規(guī)則(Rules)進(jìn)行。其功能組件如下圖所示：I宮FHKl!II應(yīng)用整合層枸戒組丹MESSMiEMO&ERTOOIKITBROKERDCVAJNBWITl圖10應(yīng)用整合層功能組件MESSAGEBROKERTOOLKIT工具集:MESSAGEBROKERTOOLKIT是開發(fā)與部署消息流、消息集應(yīng)用程序的工具集，它與配置管理器進(jìn)