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