機場信息化建設ESB的設計

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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