引言

本文是“以服務為中心的企業整合”系列文章第二部分。在本文的姊妹篇 "以服務為中心的企業整合"中 ，我們探討了以服務為中心的企業集成的理論知識，本文以一個經過簡化的實際案例為例，介紹了以服務為中心的企業集成的基本步驟，從業務分析，到服務建模，到架構設計，到系統開發的整個生命周期。以服務為中心的企業集成涉及到的主要技術被穿插在各個步驟中進行了詳細的講解。

1. 案例背景

某航空公司的 IT 系統已有好幾十年的歷史。該航空公司的主要的業務系統構建于上世紀七八十年代，以 IBM 的主機系統為主 － 包括運行于 TPF 上的訂票系統，和運行在 IMS 上的航班調度系統等。在這些核心系統周圍也不乏基于 Unix 的非核心作業系統，和基于 .Net 的簡單應用。這些形形色色的應用，有的用匯編或 COBOL 編寫，運行于主機和 IMS 之上，有的以 PRO*C 編寫，運行在 Unix 和 Oracle 上；這些應用雖然以基于主機終端的界面，但是基于 Web 和 GUI 的應用也為數眾多。

近年來，該公司在企業集成方面也是煞費苦心－已經在幾個主要的核心系統之間構建了用于信息集成的信息 HUB(information HUB) ，其他應用間也有不少點到點的集成。盡管這些企業集成技術在一定程度上增進了系統間的信息共享，但是面對如此異構的系統，技術人員依然覺得企業集成困難重重：

• 因為大部分核心應用構建在主機之上，所以 Information Hub 是基于主機技術開發，很難被開放系統使用；
• Information Hub 對 Event 支持不強，被集成的系統間的事件以點到點流轉為主，被集成系統間耦合性強；
• 牽扯到多個系統間的業務協作以硬編碼為主，將業務活動自動化的成本高，周期長，被開發的業務活動模塊重用性差；

為了解決這些企業集成中的問題，該公司決定以 Ramp Control 系統為例探索一條以服務為中心的企業集成道路。本文將以 Ramp Control 系統中的 Ramp Coordination 流程為例說明如何用以服務為中心的企業集成技術一步步解決該公司 IT 技術人員面臨的企業集成問題。

為了便于說明，示例中的業務系統和業務流程都進行了必要的簡化。

2. 業務環境分析

在航空業中， Ramp Coordination 是指飛機從降落到起飛過程中所需要進行的各種業務活動的協調過程。通常每個航班都有一個人負責 Ramp Coordination, 這人通常稱為 Ramp Coordinator 。由 Ramp Coordinator 協調的業務活動有，檢查機位環境是否安全，卸貨，裝貨，補充燃料等。

?

圖 2 是一個 Ramp Coordination 的業務流程圖。由圖可見， Ramp Coordination 流程依次有下列活動

1) 從提取協調過程中所需要的主要信息，通常會以工作單給 Ramp Coordinator;( 自動活動 )

2) 檢查機位環境是否安全； ( 人工活動 )

3) 檢查卸貨； ( 人工活動 )

4) 檢查裝貨； ( 人工活動 )

5) 檢查關門； ( 人工活動 )

?

實際上， Ramp Coordination 的流程因航班類型的不同，機型的不同有很大的差異。圖 2 所示的流程主要針對降落后不久就起飛的航班，這種類型的航班我們稱之為 short turn around 航班。除了 short turn around 航班，我們還有其他兩種類型的航班，如圖 3 所示， Arrival Only 的航班指降落后需要隔夜才起飛的。 Departure Only 的航班是指每天一早第一班飛機。這些航班的 Ramp Coordination 的流程和 Short Turn Around 類型的流程大部分的業務活動是相似的。這三種類型的航班根據長途 / 短途，國內 / 國外等因素還可以進一步細分。每種細分的航班類型的 Ramp Coordination 的流程都是略有不同。

很明顯，如此形形種種的流程之間共享著一個業務活動的集合，如此多種類型的流程都是這些業務活動的不同組裝方式。以服務為中心的企業集成中流程服務就是通過將這些流程間共享的業務活動抽象為可重用的服務，并通過流程服務提供的流程編排的能力將它們組成各種大同小異的流程類型，來降低流程集成成本，加快流程集成開發效率的。以服務為中心的企業集成通過服務建模過程發現這些可重用的服務，并通過流程模型將這些服務組裝在一起。

3. 服務建模

IBM 推薦使用組件業務建模 (Component Business Model) 和面向服務的建模和架構 (Service-Oriented Model and Architecture) 兩種方法學建立業務的組件模型，服務模型和流程模型。關于服務建模方法學已經超出本文范圍，這里就不在累述。

服務模型是服務建模的主要結果。 Ramp Coordination 相關的服務模型如圖 4 所示。和 Ramp Coordination 流程相關的有兩個業務組件：

• Ramp Control ：負責 Ramp Control 相關各種業務活動的組件
• Flight Management ：負責航班相關信息的管理，包括航班日程，乘客信息等

這兩個業務組件分別輸出如下服務：

1) Retrieve Flight BO: 由 Flight Management 輸出，主要用于提取和航班相關的數據信息；

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 輸出，用于檢查關門動作；

在服務建模確定系統相關的服務輸出后，我們還需要確定服務在當前環境下的實現方式。在我們的案例中， Retrieve Flight BO 被實現為信息服務， Ramp Coordination 被實現為流程服務，通過 BPEL4WS 方式實現；其他四個服務都是 Staff Service 。需要注意的是，因為環境的不同，和隨著系統的演化，我們可能會改變服務的實現方式，比如 Check Push Back 現在通過 Staff Service 即人工服務實現。將來隨著自動化程度的增強， Check Push Back 完全可能通過自動化的系統實現。到那時，我們只需重新實現這個服務，而無需改變整個流程。這是服務的可替換性的一個典型實例。

4. IT 環境分析

IT 環境分析是調查現有應用技術特點的重要手段。在我們的示例中， IT 環境分析主要用于調查現有應用，為決定服務模型中服務的實現方式提供技術依據。同時，它也是架構設計的重要依據。

如上所述，在構建 Ramp Control 系統之前，該航空公司已經有大量 IT 系統。作為架構設計的重要步驟的現有 IT 環境調研描繪了和 Ramp Control 相關的 IT 系統的狀況，包括周圍應用和應用提供的接口，這些應用和 Ramp Control 交互的類型和數據格式。圖 5 是簡化的 IT 環境視圖，它描繪了 Ramp Coordination 流程和周圍系統交互狀況。目前， Ramp Coordination 流程需要四種類型的外圍應用交互：

• 從乘務人員管理系統提取航班乘務員的信息；
• 從訂票系統中提取乘客信息；
• 從機務人員管理系統中提取機務人員信息；
• 接收來自航班調度系統的航班到達事件；

如圖所示，象航班調度信息和定票信息都存儲在 IMS 和 TPF 這些相當封閉的主機系統之上。盡管主機系統提供一定的面向開放系統的集成能力，如 MQ 和 Socket 。但是因為主機本身的特殊性，使得這些集成方法的使用都不是那么方便。所以如何方便地集成主機系統的信息成為 Ramp Coordination 中一個重要的技術問題，同時也是整個 IT 系統集成面臨的主要問題。以服務為中心的企業集成為我們提供了更為開放的集成手段。在 Ramp Coordination 中，我們把這些主機上的數據進行了集中，并通過信息服務的形式輸出給開放系統使用。如圖 6 所示，來自 IMS 的航班信息和機務人員信息，來自 Oracle 的乘務人員信息和來自 TPF 的乘客信息都被匯集為一個業務對象 Flight BO 。 Retrieve Flight BO 服務提供訪問這種業務對象的手段。 Retrieve Flight BO 服務隔離了底層實現的復雜性。外面的應用系統看到的是前面開放的接口，而不是后面封閉的主機系統。即使將來后臺主機被開放系統替代，外面的應用依然可以運行依舊。

通過將主機應用中的信息集中為粗粒度的業務對象，并通過信息服務輸出，為該公司的核心系統提供了更加通用的連接能力，同時為 IT 系統的平滑演進提供了必需的條件。

5. 高層架構設計

根據需求和設計階段的業務模型和現有 IT 環境調研結果，再結合傳統的 IT 應用開發方法， Ramp Coordination 系統的高層架構被設計了出來，如圖 7 所示。

如下四點簡要介紹了本案例中的主要架構元素以及它們間的工作關系。

1) 信息服務－ Federation Service: Ramp Coordination 流程中需要從已有系統中提取四類信息，在 Service 建模階段這四類信息被聚合為 Flight BO （ Business Object ）。如上文所述， Retrieve Flight BO 服務用于從已有系統中提取 Flight BO 。它實際上是一個 Federation Service ，將來自乘務人員管理系統、機務人員管理系統和訂票系統中的信息聚合在一起。從這三個已有系統來的 Crew Info, Cockpit Info 和 Passage Info 是在已有系統中已經存在的業務邏輯或業務數據，它們屬于可接入服務 (on-ramp service) ，接入的協議分別為 JDBC, IMS J2C Connector 和 socket 。乘務人員管理系統基于 Oracle 數據庫， Crew Info 可以直接通過 JDBC 獲得。機務人員管理系統基于 S/390 上的 IMS, IBM 已經提供了 IMS 的 J2C Connector ， 所以 Cockpit Info 可以通過 J2C connector 獲得。訂票系統構建在 IBM TPF 之上，由于實時性的要求， socket 是比較好的接入方法。 Retrieve Flight BO 被實現為一個 EJB ，外部訪問通過 RMI/IIOP 綁定訪問這個服務。在 Retrieve Flight BO 內部， Flight BO 以 SDO 來表示。

2) 企業服務總線中的事件服務－ Event Service: 在檢查機務環境安全 (Check Spot) 前， Ramp Coordiator 需要被通知航班已經到達。這個業務事件由航班調度系統激發， Flight Arrival 是典型事件發現服務 (Event Detect Service) ，它通過 MQ 將事件傳遞給 Message Broker, 通過 JMS 的 Pub/Sub ，這個事件被分發給 Check Spot 。這里的 Event Service 是本例中 ESB 的重要組成部分。通過 ESB 上的通用事件服務，現有 Information Hub 的缺陷得到了克服。應用程序間的事件集成不再需要點到點的方式，而是通過 ESB 的事件服務完成訂閱發布，應用程序間的耦合性得到了極大的緩解。

3) 流程服務－ Process Service: Ramp Coordination 被實現為一個 Process Service ，它被 WBI SF 的 BPEL4WS 容器執行， BPEL4WS 容器提供 Choreograph Service, Transaction Service 和 Staff Service 支持。 Ramp Coordination 通過 RMI/IIOP 協議調用，在 BPEL4WS 容器中 WSIF 被用于通過各種協議調用服務 , 它成為 ESB 中 Transport Service 的一部分。 Ramp Coordination 中的人工動作被實現為 Staff Service 而集成到流程中。這里 Staff Service 通過 Portlet 實現，運行在 Websphere Portal Server 上。 Portal Service 實現部分 Delivery Service 支持 PDA 設備， Ramp Coordinator 通過 PDA 設備訪問系統。

4) 企業服務總線中的傳輸服務－ RCMS 是即將新建系統用于提供包括 Ramp Coordination 在內的 Ramp Control 的功能。 RCMS 通過由 WSIF 實現的 Transport Service 以 SOAP/HTTP 調用 Ramp Coordination 服務。

6. 開發過程

盡管以服務為中心的企業集成在開發階段和普通的應用開發并沒有本質的區別，但是它在角色，職責、工具和方法還是有不少自己的特色。下圖匯總了本文示例中開發角色，職責，開發方法和工具，僅供大家參考。

7. 結束語

本文通過一個簡單的案例，講解了以服務為中心的企業集成的主要步驟和涉及的技術。這些集成的技術，無論是方法學，體系結構，還是編程模型都在不斷的發展中。隨著這些技術的不斷完善，以服務為中心的企業集成方案的實施將更加簡單高效。

?