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