ESB案例解析和項目實施經(jīng)驗分享

1、ESB案例解析和項目實施經(jīng)驗分享導讀：本文從業(yè)務角度列舉了航空公司商務體系建設中對ESB的典型需求舉例，并介紹了航空公司ESB的總體方案、組件模型、接口設計、物理部署以及涉及到的IBM軟件產(chǎn)品。關鍵詞：ESB 企業(yè)服務總線 ESB案例 物理部署 本文是一個由3部分內(nèi)容組成的系列文章，在前2部分，介紹了兩個企業(yè)ESB解決方案的設計案例，這兩個案例分別來自于交通運輸行業(yè)和制造行業(yè)，我們針對不同行業(yè)的業(yè)務和應用特點設計了不同的ESB解決方案。第3部分內(nèi)容我們將向您介紹ESB項目實施的一些方法論和經(jīng)驗。前言一個實際ESB項目實施的成敗，不僅要求我們把產(chǎn)品用熟用好，即熟悉ESB產(chǎn)品的配置、開發(fā)及優(yōu)化操作

2、，還需要制定正確的、量體裁衣式的解決方案，并且需要借助科學的項目實施方法論，從需求分析、方案設計、產(chǎn)品開發(fā)、測試、上線運行等各個方面進行全面的考慮。本系列文章將分為三部分，第1部分和第2部分將結合兩個不同行業(yè)的案例來介紹兩個具有鮮明行業(yè)特點的ESB解決方案，第3部分則將針對ESB項目的實施過程給出一些建議。航空公司ESB案例解析通過企業(yè)服務總線、接口適配器、服務注冊管理等整合技術，實現(xiàn)將企業(yè)內(nèi)部現(xiàn)有的各應用系統(tǒng)之間的信息共享，提高企業(yè)內(nèi)部應用系統(tǒng)的數(shù)據(jù)共享和交換效率，提升企業(yè)在市場上的綜合競爭力和客戶服務質(zhì)量，是所有企業(yè)的一個典型需求。本文將以航空公司的案例為基礎，說明采用IBM ESB相關產(chǎn)

3、品整合航空公司電子商務、常旅客、航班動態(tài)、呼叫中心等系統(tǒng)的解決方案。航空公司ESB的需求舉例與其他行業(yè)一樣，在民航業(yè)，國際和國內(nèi)的主要航空公司內(nèi)部也分布著眾多已建和在建的用以支撐業(yè)務運行的IT系統(tǒng)，這些系統(tǒng)之間缺乏對信息共享性、系統(tǒng)兼容性和接口標準規(guī)范的統(tǒng)一考慮，造成系統(tǒng)之間的連接比較困難，應用和數(shù)據(jù)無法得到全面共享，系統(tǒng)間“蜘蛛網(wǎng)狀”的連接普遍存在。隨著新系統(tǒng)的不斷建設，在業(yè)務與流程方面的整合將會因系統(tǒng)和業(yè)務領域間的信息溝通障礙而面臨越來越多的困難，對航空公司的整體發(fā)展戰(zhàn)略帶來制約。下面我們就來列舉幾個民航業(yè)的現(xiàn)狀，以此說明對企業(yè)進行業(yè)務整合的必要性?，F(xiàn)狀一：業(yè)務系統(tǒng)間數(shù)據(jù)共享需求強烈總體來

4、看，航空公司的IT分為商務、航務、機務和管控四大體系，其中商務體系中包括定座系統(tǒng)、電子客票銷售系統(tǒng)、離港系統(tǒng)、電子商務系統(tǒng)、常旅客系統(tǒng)、大客戶系統(tǒng)、呼叫中心系統(tǒng)、運價收益管理系統(tǒng)、地面服務系統(tǒng)等。在這個龐大的體系結構中，存在著巨大的系統(tǒng)間數(shù)據(jù)集成和共享的需求。主要存在以下三類信息的共享：航班數(shù)據(jù)共享：航班數(shù)據(jù)包括航班計劃、航班動態(tài)、飛機參數(shù)等數(shù)據(jù)，是保障航空公司正常運營的最基本信息，而航空公司內(nèi)部通常都會有超過10個的系統(tǒng)需要獲取航班數(shù)據(jù)，其中包括：電子商務系統(tǒng)、呼叫中心系統(tǒng)、常旅客系統(tǒng)、地服系統(tǒng)、聯(lián)盟成員系統(tǒng)等。目前，航班數(shù)據(jù)的源數(shù)據(jù)系統(tǒng)（一般來自航空公司運控AOC系統(tǒng)）與其他業(yè)務系統(tǒng)之間的

5、數(shù)據(jù)交換和共享都是通過點對點單獨開發(fā)接口的形式實現(xiàn)的，比如通過數(shù)據(jù)庫視圖的緊耦合的方式實現(xiàn)，這在增加各個系統(tǒng)接口復雜性的同時也增加了系統(tǒng)開發(fā)的周期和費用，而且各業(yè)務系統(tǒng)無法從統(tǒng)一的渠道獲取航班數(shù)據(jù)，造成了各業(yè)務系統(tǒng)之間數(shù)據(jù)不一致，如下圖所示：                      圖1. 航空公司航班數(shù)據(jù)共享客戶主數(shù)據(jù)共享：根據(jù)不同的直銷、分銷渠道以及不同的客戶屬性，航空公司的客戶信

6、息通常被分散地存儲在多個不同的客戶服務系統(tǒng)中，其中包括常旅客系統(tǒng)、大客戶系統(tǒng)、電子商務系統(tǒng)等，這些現(xiàn)有系統(tǒng)或多或少地通過點到點的星型結構的接口方式進行了一些互連，在一定程度上實現(xiàn)了客戶數(shù)據(jù)共享，但是仍普遍存在連接混亂、各系統(tǒng)間數(shù)據(jù)更新頻率不一致、各系統(tǒng)內(nèi)同一旅客基本信息不統(tǒng)一等問題，借鑒其他行業(yè)在客戶主數(shù)據(jù)管理方面的發(fā)展趨勢和最佳實踐，因此航空公司需要對客戶主數(shù)據(jù)進行統(tǒng)一存儲和一致性管理，這就需要完成呼叫中心、電子商務、大客戶、常旅客等系統(tǒng)與客戶主數(shù)據(jù)系統(tǒng)之間的集成，希望通過ESB技術實現(xiàn)上述系統(tǒng)間數(shù)據(jù)的實時同步，如下圖所示：     

7、0;                     圖2. 航空公司客戶數(shù)據(jù)共享客票銷售和客戶服務信息共享：在航空公司的直銷渠道中，電子商務與呼叫中心是非常重要的兩大直銷渠道，各自擁有獨立的業(yè)務支持系統(tǒng)，以這兩個系統(tǒng)為例，國內(nèi)各個航空公司擁有的電子商務與呼叫中心這兩個應用系統(tǒng)之間后臺基本沒有任何數(shù)據(jù)共享，在業(yè)務和應用上完全獨立，如下圖：     

8、0;                  圖3. 呼叫中心和電子商務系統(tǒng)渠道分離而實際上這兩個系統(tǒng)之間存在著非常多的來自業(yè)務的數(shù)據(jù)共享需求。例如：當客戶在互連網(wǎng)上完成了全部訂座功能，希望能夠在呼叫中心完成改期升艙、退票退款等操作；而如果客戶在呼叫中心渠道上完成了全部訂座功能，或者在呼叫中心完成改期升艙、退票、退款操作后，也希望能夠在互連網(wǎng)上進行狀態(tài)查詢，如下圖所示：     &#

9、160;                    圖4. 呼叫中心和電子商務系統(tǒng)間數(shù)據(jù)共享因此這兩個系統(tǒng)希望共享客票銷售數(shù)據(jù)、客票服務數(shù)據(jù)（對于升艙、改期、退票、退款、訂單追蹤、郵寄行程單等客票服務流程的相關數(shù)據(jù)）以及銷售業(yè)績管理等進行共享，從而實現(xiàn)航空公司的兩大直銷渠道之間在銷售與服務流程上的統(tǒng)一和客戶體驗的統(tǒng)一，增加客戶滿意度和客戶服務水平?，F(xiàn)狀二：缺乏技術先進的、統(tǒng)一的、標準的IT集成架構在以往各個系統(tǒng)

10、的建設當中，都是采用傳統(tǒng)的點對點的聯(lián)接方式，導致了一個復雜的網(wǎng)狀結構，其弊端在于系統(tǒng)接口眾多，系統(tǒng)間造成密切的耦合性，某一個系統(tǒng)接口的修改導致其他所有系統(tǒng)的修改；系統(tǒng)沒有擴展性，每新增一個系統(tǒng)就需要開發(fā)該系統(tǒng)和其他相關所有系統(tǒng)的接口；系統(tǒng)的后期維護成本過高。沒有建立起統(tǒng)一的數(shù)據(jù)交換平臺和數(shù)據(jù)交換標準。各系統(tǒng)之間根據(jù)自己的需要獲取數(shù)據(jù)，存在著格式上、內(nèi)容上、或者統(tǒng)計口徑上的差異。以航空公司電子商務系統(tǒng)為例，電子商務系統(tǒng)與周邊業(yè)務系統(tǒng)的集成需求如下：            

11、60;       表1. 航空公司電子商務與外圍系統(tǒng)集成舉例上表中，我們粗略列舉了航空公司電子商務系統(tǒng)與其各主要相關系統(tǒng)間交換的業(yè)務數(shù)據(jù)內(nèi)容，以及通訊協(xié)議和數(shù)據(jù)格式，我們可以看出其復雜性，如果沒有一個統(tǒng)一的集成平臺的支撐，那么數(shù)據(jù)格式轉(zhuǎn)換、通訊適配器的開發(fā)、傳輸可靠性保證等問題都需要依賴于自主開發(fā)，其風險是不言而喻的。航空公司商務體系ESB整合方案總體方案概述SOA（面向服務的架構）是當今國外各大航空公司率先考慮的方法論并成為提升下一代提升航空運輸服務的能力引擎，它使IT部門可以搭建靈活的可配置體系以支持隨需應變的航空業(yè)務。鑒于航空

12、公司商務體系建設中存在的這些問題，以及業(yè)界的最佳實踐，我們提出采用ESB整合航空公司的商務體系，其總體架構如下圖所示：                         圖5. 航空公司商務體系集成架構總體系統(tǒng)架構主要由展現(xiàn)層、核心應用層和SOA核心能力層組成，其中通過門戶實現(xiàn)統(tǒng)一用戶接入，該模塊主要包含用戶帳戶信息管理和存儲、用戶登錄身份認證和訪問

13、請求負載均衡等部分。核心應用層包括電子商務系統(tǒng)、呼叫中心系統(tǒng)、常旅客系統(tǒng)、大客戶系統(tǒng)等商務體系中的所有重要的業(yè)務系統(tǒng)。SOA核心能力層由企業(yè)服務總線、服務管理和注冊庫以及組合服務運行引擎三部分組成。其中，企業(yè)服務總線（ESB）是SOA核心能力層的一個中心組件，它負責接入各種服務資源，通過采用統(tǒng)一服務接口使得各種服務或應用與服務之間可以相互方便訪問，以星形結構替代了原來各服務之間的點對點結構，極大地優(yōu)化了系統(tǒng)連接架構，降低了系統(tǒng)集成的復雜度。企業(yè)服務總線下方連入的各個應用系統(tǒng)是航空公司內(nèi)部的各個業(yè)務系統(tǒng)，而右邊是要連接的一些外部系統(tǒng)。組合服務運行引擎通常運行在標準的流程引擎之上，例如BPEL流程

14、引擎，不是本文的重點，在此就不再贅述了。ESB的組件及產(chǎn)品映射模型ESB組件模型及產(chǎn)品映射模型如圖6：                         圖6. 航空公司ESB組件模型其中包括ESB組件、服務注冊和管理組件以及ESB的監(jiān)控和管理組件3部分組成。ESB組件：實現(xiàn)消息傳遞、服務路由、格式轉(zhuǎn)換、交易完整性保證、數(shù)據(jù)解析和處理、安全傳輸、應用

15、適配、協(xié)議轉(zhuǎn)換等功能，可以由WebSphere Message Broker實現(xiàn)。服務注冊和管理：為ESB提供服務管理容器，借助科學的方法論，對航空公司的業(yè)務需求進行分析，對其商務體系的業(yè)務流程進行梳理，建立起航空公司商務體系的服務目錄和服務庫，對這些服務以及服務的元數(shù)據(jù)進行定義和存儲，以便進行服務的查找、發(fā)布、注冊和管理。該組件可以由WebSphere Service Registry and Repository（WSRR）來實現(xiàn)，將所暴露的服務注冊在WSRR中，便于其他系統(tǒng)發(fā)現(xiàn)和調(diào)用。ESB監(jiān)控和管理：ESB是應用集成的樞紐，各個應用之間的信息和服務共享都將通過ESB來進行，因此，ESB

16、平臺本身的監(jiān)控和管理的重要性是不言而喻的。全面、及時的服務監(jiān)控功能除了能夠輔助快捷的故障診斷，還能夠提供完整的服務質(zhì)量評估報告，以衡量現(xiàn)有的應用系統(tǒng)效率，并為優(yōu)化、升級提供指導。服務監(jiān)控需要包括服務、操作等級別的調(diào)用/失敗次數(shù)、響應時間等信息，并且在超過設定值的情況下能夠報警。該組件由Tivoli Omegamon XE for Messaging實現(xiàn)，Tivoli Omegamon XE for Messaging能夠?qū)崿F(xiàn)對IBM WebSphere Message Broker以及底層MQ的資源的自動發(fā)現(xiàn)并進行自動監(jiān)控，幫助管理員及時發(fā)現(xiàn)故障和故障隱患。組件交互模型以前面描述的電子商務系統(tǒng)

17、和呼叫中心之間的訂單交互為例，其組件交互模型如下：                           圖7. 航空公司ESB組件交互模型該模型描述了客戶在呼叫中心預定了機票（產(chǎn)生訂單），然后通過電子商務（B2C）系統(tǒng)修改訂單時通過ESB實現(xiàn)系統(tǒng)間訂單交互的場景。ESB的接口設計    &

18、#160;                   圖8. 航空公司ESB接口設計在上圖中，我們給出了某航空公司的一個示例。在這個例子中，我們看到其電子商務系統(tǒng)、航班信息發(fā)布系統(tǒng)、客戶主數(shù)據(jù)系統(tǒng)都是采用Web Service/實時/XML接口；呼叫中心采用socket/實時/文本、WebService/實時/XML接口；常旅客系統(tǒng)采用FTP/批量/文本、WebService/實時/XML的接口；大客戶系統(tǒng)采用Databa

19、se的接口形式?；诮涌诘臄?shù)據(jù)格式的不同，與ESB相關的系統(tǒng)可以分為以下兩類：基于XML報文的應用系統(tǒng)：基于XML報文交互是比較理想的方式，是目前業(yè)界較為推薦的標準方式。需要說明的是，盡管都采用XML標準，由于各個系統(tǒng)的需求的差別已經(jīng)建設周期的不同，不同的應用系統(tǒng)采用的XML消息很難完全兼容。這需要由ESB實現(xiàn)相應的轉(zhuǎn)換?；趯Ｓ袌笪?自定義報文的應用系統(tǒng)：基于專有報文的應用系統(tǒng)，如國內(nèi)的定座系統(tǒng)，可以先保留現(xiàn)有的報文格式，由ESB實現(xiàn)現(xiàn)有格式與其他報文格式以及XML格式之間的轉(zhuǎn)換。隨著未來條件的成熟，這些系統(tǒng)逐步過度到通過XML實現(xiàn)與ESB以及其他應用系統(tǒng)的集成?；诮涌诘耐ㄓ崊f(xié)議的不同，與

20、ESB相關的系統(tǒng)可以分為以下四類：基于Web Services的系統(tǒng)：基于Web Services的系統(tǒng)，例如目前的呼叫中心和電子商務系統(tǒng)都可以提供這種方式，可以使用SOAP/HTTP（S）與ESB實現(xiàn)整合?；贔TP/Socket的應用系統(tǒng)：需要通過FTP交換數(shù)據(jù)的系統(tǒng)，如FFP系統(tǒng)等，ESB可以直接支持FTP的方式。ESB缺省提供文件適配器，其中就可以支持本地文件和遠程文件通過FTP方式的讀寫?；跀?shù)據(jù)庫的應用系統(tǒng)：基于數(shù)據(jù)庫的系統(tǒng)，如大客戶系統(tǒng)、數(shù)據(jù)倉庫系統(tǒng)，可以通過JDBC適配器與ESB集成。基于傳統(tǒng)應用連接的系統(tǒng)：對于這類系統(tǒng)可以通過定制的Adapter與ESB以及其他應用實現(xiàn)整合，該Adapter可以以Java實現(xiàn)。另一方面，也可以通過XML/MQ實現(xiàn)與ESB的集成，這時，這些傳統(tǒng)應用系統(tǒng)將調(diào)整為面向消息的方式。使用MQ作為一個通用的Adapter與ESB以及其他應用實現(xiàn)