| 生 毛新, IBM 中國軟件開(kāi)發(fā)實(shí)驗室 IBM軟件部企業(yè)集成解決方案大中華區首席架構師 2005 年 12 月 23 日 本文是“以服務(wù)為中心的企業(yè)整合”系列文章第二部分。在本文的姊妹篇"以服務(wù)為中心的企業(yè)整合"中，我們探討了以服務(wù)為中心的企業(yè)集成的理論知識，本文以一個(gè)經(jīng)過(guò)簡(jiǎn)化的實(shí)際案例為例，介紹了以服務(wù)為中心的企業(yè)集成的基本步驟，從業(yè)務(wù)分析，到服務(wù)建模，到架構設計，到系統開(kāi)發(fā)的整個(gè)生命周期。以服務(wù)為中心的企業(yè)集成涉及到的主要技術(shù)被穿插在各個(gè)步驟中進(jìn)行了詳細的講解。
某航空公司的IT系統已有好幾十年的歷史。該航空公司的主要的業(yè)務(wù)系統構建于上世紀七八十年代，以IBM的主機系統為主 － 包括運行于TPF上的訂票系統，和運行在IMS上的航班調度系統等。在這些核心系統周?chē)膊环赨nix的非核心作業(yè)系統，和基于.Net的簡(jiǎn)單應用。這些形形色色的應用，有的用匯編或COBOL編寫(xiě)，運行于主機和IMS之上，有的以PRO*C編寫(xiě)，運行在Unix和Oracle上；這些應用雖然以基于主機終端的界面，但是基于Web和GUI的應用也為數眾多。 近年來(lái)，該公司在企業(yè)集成方面也是煞費苦心－已經(jīng)在幾個(gè)主要的核心系統之間構建了用于信息集成的信息HUB(information HUB)，其他應用間也有不少點(diǎn)到點(diǎn)的集成。盡管這些企業(yè)集成技術(shù)在一定程度上增進(jìn)了系統間的信息共享，但是面對如此異構的系統，技術(shù)人員依然覺(jué)得企業(yè)集成困難重重：
為了解決這些企業(yè)集成中的問(wèn)題，該公司決定以Ramp Control系統為例探索一條以服務(wù)為中心的企業(yè)集成道路。本文將以Ramp Control系統中的Ramp Coordination流程為例說(shuō)明如何用以服務(wù)為中心的企業(yè)集成技術(shù)一步步解決該公司IT技術(shù)人員面臨的企業(yè)集成問(wèn)題。 為了便于說(shuō)明，示例中的業(yè)務(wù)系統和業(yè)務(wù)流程都進(jìn)行了必要的簡(jiǎn)化。
在航空業(yè)中，Ramp Coordination是指飛機從降落到起飛過(guò)程中所需要進(jìn)行的各種業(yè)務(wù)活動(dòng)的協(xié)調過(guò)程。通常每個(gè)航班都有一個(gè)人負責Ramp Coordination, 這人通常稱(chēng)為Ramp Coordinator。由Ramp Coordinator協(xié)調的業(yè)務(wù)活動(dòng)有，檢查機位環(huán)境是否安全，卸貨，裝貨，補充燃料等。  圖2是一個(gè)Ramp Coordination的業(yè)務(wù)流程圖。由圖可見(jiàn)，Ramp Coordination流程依次有下列活動(dòng) 1) 從提取協(xié)調過(guò)程中所需要的主要信息，通常會(huì )以工作單給Ramp Coordinator;(自動(dòng)活動(dòng)) 2) 檢查機位環(huán)境是否安全；(人工活動(dòng)) 3) 檢查卸貨；(人工活動(dòng)) 4) 檢查裝貨；(人工活動(dòng)) 5) 檢查關(guān)門(mén)；(人工活動(dòng)) 實(shí)際上，Ramp Coordination的流程因航班類(lèi)型的不同，機型的不同有很大的差異。圖2所示的流程主要針對降落后不久就起飛的航班，這種類(lèi)型的航班我們稱(chēng)之為short turn around航班。除了short turn around航班，我們還有其他兩種類(lèi)型的航班，如圖3 所示，Arrival Only的航班指降落后需要隔夜才起飛的。Departure Only的航班是指每天一早第一班飛機。這些航班的Ramp Coordination的流程和Short Turn Around類(lèi)型的流程大部分的業(yè)務(wù)活動(dòng)是相似的。這三種類(lèi)型的航班根據長(cháng)途/短途，國內/國外等因素還可以進(jìn)一步細分。每種細分的航班類(lèi)型的Ramp Coordination的流程都是略有不同。 很明顯，如此形形種種的流程之間共享著(zhù)一個(gè)業(yè)務(wù)活動(dòng)的集合，如此多種類(lèi)型的流程都是這些業(yè)務(wù)活動(dòng)的不同組裝方式。以服務(wù)為中心的企業(yè)集成中流程服務(wù)就是通過(guò)將這些流程間共享的業(yè)務(wù)活動(dòng)抽象為可重用的服務(wù)，并通過(guò)流程服務(wù)提供的流程編排的能力將它們組成各種大同小異的流程類(lèi)型，來(lái)降低流程集成成本，加快流程集成開(kāi)發(fā)效率的。以服務(wù)為中心的企業(yè)集成通過(guò)服務(wù)建模過(guò)程發(fā)現這些可重用的服務(wù)，并通過(guò)流程模型將這些服務(wù)組裝在一起。
IBM推薦使用組件業(yè)務(wù)建模(Component Business Model)和面向服務(wù)的建模和架構(Service-Oriented Model and Architecture)兩種方法學(xué)建立業(yè)務(wù)的組件模型，服務(wù)模型和流程模型。關(guān)于服務(wù)建模方法學(xué)已經(jīng)超出本文范圍，這里就不在累述。 服務(wù)模型是服務(wù)建模的主要結果。Ramp Coordination相關(guān)的服務(wù)模型如圖4所示。和Ramp Coordination流程相關(guān)的有兩個(gè)業(yè)務(wù)組件：
這兩個(gè)業(yè)務(wù)組件分別輸出如下服務(wù)： 1) Retrieve Flight BO: 由Flight Management輸出，主要用于提取和航班相關(guān)的數據信息； 2) Ramp Coordination: 由Ramp Control輸出，主要用于Ramp Coordination流程的編排； 3) Check Spot：由Ramp Control輸出，用于檢測機位安全信息； 4) Check Unloading：由Ramp Control輸出，用于檢查卸貨狀況； 5) Check Loading：由Ramp Control輸出，用于檢查裝貨狀況； 6) Check Push Back：由Ramp Control輸出，用于檢查關(guān)門(mén)動(dòng)作； 在服務(wù)建模確定系統相關(guān)的服務(wù)輸出后，我們還需要確定服務(wù)在當前環(huán)境下的實(shí)現方式。在我們的案例中，Retrieve Flight BO被實(shí)現為信息服務(wù)，Ramp Coordination被實(shí)現為流程服務(wù)，通過(guò)BPEL4WS方式實(shí)現；其他四個(gè)服務(wù)都是Staff Service。需要注意的是，因為環(huán)境的不同，和隨著(zhù)系統的演化，我們可能會(huì )改變服務(wù)的實(shí)現方式，比如Check Push Back現在通過(guò)Staff Service即人工服務(wù)實(shí)現。將來(lái)隨著(zhù)自動(dòng)化程度的增強，Check Push Back完全可能通過(guò)自動(dòng)化的系統實(shí)現。到那時(shí)，我們只需重新實(shí)現這個(gè)服務(wù)，而無(wú)需改變整個(gè)流程。這是服務(wù)的可替換性的一個(gè)典型實(shí)例。
IT環(huán)境分析是調查現有應用技術(shù)特點(diǎn)的重要手段。在我們的示例中，IT環(huán)境分析主要用于調查現有應用，為決定服務(wù)模型中服務(wù)的實(shí)現方式提供技術(shù)依據。同時(shí)，它也是架構設計的重要依據。 如上所述，在構建Ramp Control系統之前，該航空公司已經(jīng)有大量IT系統。作為架構設計的重要步驟的現有IT環(huán)境調研描繪了和Ramp Control相關(guān)的IT系統的狀況，包括周?chē)鷳煤蛻锰峁┑慕涌?，這些應用和Ramp Control交互的類(lèi)型和數據格式。圖5是簡(jiǎn)化的IT環(huán)境視圖，它描繪了Ramp Coordination流程和周?chē)到y交互狀況。目前，Ramp Coordination流程需要四種類(lèi)型的外圍應用交互：
如圖所示，象航班調度信息和定票信息都存儲在IMS和TPF這些相當封閉的主機系統之上。盡管主機系統提供一定的面向開(kāi)放系統的集成能力，如MQ和Socket。但是因為主機本身的特殊性，使得這些集成方法的使用都不是那么方便。所以如何方便地集成主機系統的信息成為Ramp Coordination中一個(gè)重要的技術(shù)問(wèn)題，同時(shí)也是整個(gè)IT系統集成面臨的主要問(wèn)題。以服務(wù)為中心的企業(yè)集成為我們提供了更為開(kāi)放的集成手段。在Ramp Coordination中，我們把這些主機上的數據進(jìn)行了集中，并通過(guò)信息服務(wù)的形式輸出給開(kāi)放系統使用。如圖6所示，來(lái)自IMS的航班信息和機務(wù)人員信息，來(lái)自Oracle的乘務(wù)人員信息和來(lái)自TPF的乘客信息都被匯集為一個(gè)業(yè)務(wù)對象Flight BO。Retrieve Flight BO服務(wù)提供訪(fǎng)問(wèn)這種業(yè)務(wù)對象的手段。Retrieve Flight BO服務(wù)隔離了底層實(shí)現的復雜性。外面的應用系統看到的是前面開(kāi)放的接口，而不是后面封閉的主機系統。即使將來(lái)后臺主機被開(kāi)放系統替代，外面的應用依然可以運行依舊。 通過(guò)將主機應用中的信息集中為粗粒度的業(yè)務(wù)對象，并通過(guò)信息服務(wù)輸出，為該公司的核心系統提供了更加通用的連接能力，同時(shí)為IT系統的平滑演進(jìn)提供了必需的條件。
根據需求和設計階段的業(yè)務(wù)模型和現有IT環(huán)境調研結果，再結合傳統的IT應用開(kāi)發(fā)方法，Ramp Coordination系統的高層架構被設計了出來(lái)，如圖7所示。 如下四點(diǎn)簡(jiǎn)要介紹了本案例中的主要架構元素以及它們間的工作關(guān)系。 1) 信息服務(wù)－Federation Service: Ramp Coordination流程中需要從已有系統中提取四類(lèi)信息，在Service建模階段這四類(lèi)信息被聚合為Flight BO（Business Object）。如上文所述，Retrieve Flight BO服務(wù)用于從已有系統中提取Flight BO。它實(shí)際上是一個(gè)Federation Service，將來(lái)自乘務(wù)人員管理系統、機務(wù)人員管理系統和訂票系統中的信息聚合在一起。從這三個(gè)已有系統來(lái)的Crew Info, Cockpit Info和Passage Info是在已有系統中已經(jīng)存在的業(yè)務(wù)邏輯或業(yè)務(wù)數據，它們屬于可接入服務(wù)(on-ramp service)，接入的協(xié)議分別為JDBC, IMS J2C Connector和socket。乘務(wù)人員管理系統基于Oracle數據庫，Crew Info可以直接通過(guò)JDBC獲得。機務(wù)人員管理系統基于S/390上的IMS, IBM已經(jīng)提供了IMS的J2C Connector， 所以Cockpit Info可以通過(guò)J2C connector獲得。訂票系統構建在IBM TPF之上，由于實(shí)時(shí)性的要求，socket是比較好的接入方法。Retrieve Flight BO被實(shí)現為一個(gè)EJB，外部訪(fǎng)問(wèn)通過(guò)RMI/IIOP綁定訪(fǎng)問(wèn)這個(gè)服務(wù)。在Retrieve Flight BO內部，Flight BO以SDO來(lái)表示。 2) 企業(yè)服務(wù)總線(xiàn)中的事件服務(wù)－ Event Service: 在檢查機務(wù)環(huán)境安全(Check Spot)前，Ramp Coordiator需要被通知航班已經(jīng)到達。這個(gè)業(yè)務(wù)事件由航班調度系統激發(fā)，Flight Arrival是典型事件發(fā)現服務(wù)(Event Detect Service)，它通過(guò)MQ將事件傳遞給Message Broker, 通過(guò)JMS的Pub/Sub，這個(gè)事件被分發(fā)給Check Spot。這里的Event Service是本例中ESB的重要組成部分。通過(guò)ESB上的通用事件服務(wù)，現有Information Hub的缺陷得到了克服。應用程序間的事件集成不再需要點(diǎn)到點(diǎn)的方式，而是通過(guò)ESB的事件服務(wù)完成訂閱發(fā)布，應用程序間的耦合性得到了極大的緩解。 3) 流程服務(wù)－ Process Service: Ramp Coordination被實(shí)現為一個(gè)Process Service，它被WBI SF的BPEL4WS容器執行，BPEL4WS容器提供Choreograph Service, Transaction Service和Staff Service支持。Ramp Coordination通過(guò)RMI/IIOP協(xié)議調用，在BPEL4WS容器中WSIF被用于通過(guò)各種協(xié)議調用服務(wù), 它成為ESB中Transport Service的一部分。Ramp Coordination中的人工動(dòng)作被實(shí)現為Staff Service而集成到流程中。這里Staff Service通過(guò)Portlet實(shí)現，運行在Websphere Portal Server上。Portal Service實(shí)現部分Delivery Service支持PDA設備，Ramp Coordinator通過(guò)PDA設備訪(fǎng)問(wèn)系統。 4) 企業(yè)服務(wù)總線(xiàn)中的傳輸服務(wù)－RCMS是即將新建系統用于提供包括Ramp Coordination在內的Ramp Control的功能。RCMS通過(guò)由WSIF實(shí)現的Transport Service以SOAP/HTTP調用Ramp Coordination服務(wù)。
盡管以服務(wù)為中心的企業(yè)集成在開(kāi)發(fā)階段和普通的應用開(kāi)發(fā)并沒(méi)有本質(zhì)的區別，但是它在角色，職責、工具和方法還是有不少自己的特色。下圖匯總了本文示例中開(kāi)發(fā)角色，職責，開(kāi)發(fā)方法和工具，僅供大家參考。
本文通過(guò)一個(gè)簡(jiǎn)單的案例，講解了以服務(wù)為中心的企業(yè)集成的主要步驟和涉及的技術(shù)。這些集成的技術(shù)，無(wú)論是方法學(xué)，體系結構，還是編程模型都在不斷的發(fā)展中。隨著(zhù)這些技術(shù)的不斷完善，以服務(wù)為中心的企業(yè)集成方案的實(shí)施將更加簡(jiǎn)單高效。
|
聯(lián)系客服
