王 奕，黃宗浩

0 引言

ESB是Enterprise Service Bus（企業(yè)服務(wù)總線）的縮寫。

Forrester研究公司將ESB技術(shù)描寫成“通過起到中間層作用而實現(xiàn)面向服務(wù)架構(gòu)（SOA）的軟件基礎(chǔ)設(shè)施，通過這樣的中間件，就能廣泛利用一套可重復(fù)使用的商業(yè)服務(wù)?！?/p>

“許多SOA項目在很大程度都將ESB作為其核心的軟件基礎(chǔ)設(shè)施。這是因為在一個ESB產(chǎn)品中捆綁了許多解決方案來應(yīng)對各種不同的挑戰(zhàn)。舉例而言，ESB能夠?qū)⑾⒃诙喾N通信協(xié)議之間路由、在多種格式之間進行轉(zhuǎn)換；將業(yè)務(wù)服務(wù)重新組合封裝成標(biāo)準(zhǔn)行為；對服務(wù)水平協(xié)議（SLA）進行監(jiān)控和管理；與安全基礎(chǔ)設(shè)施的緊密集成。”

Forrester公司也對ESB產(chǎn)品應(yīng)該具有的核心功能和擴展功能進行了定義，在此不再累述。

1 醫(yī)院實施ESB的基本過程

我院在實施ESB項目上的基本思路是遵循面向服務(wù)架構(gòu)（SOA）的思想進行分析設(shè)計。因為ESB要作為一個軟件基礎(chǔ)設(shè)施使多方應(yīng)用系統(tǒng)之間能夠進行消息層面的溝通，因此實施ESB的重點在于對醫(yī)院現(xiàn)有各個信息系統(tǒng)內(nèi)部的業(yè)務(wù)流程進行分析，目的是提煉出粗粒度的醫(yī)療服務(wù)接口，將其定義成為 SOA中的 S（Service）。最終可以通過 ESB本身提供的功能，使得消息在各個Service之間按照預(yù)定的路線進行流轉(zhuǎn)。

實施ESB的大致過程包括：針對業(yè)務(wù)流程進行調(diào)研分析，提煉粗粒度的業(yè)務(wù)服務(wù)，定義接口規(guī)范，部署ESB產(chǎn)品，根據(jù)接口規(guī)范實現(xiàn)SOA服務(wù)，注冊SOA服務(wù)到ESB平臺，按照業(yè)務(wù)需求對SOA服務(wù)進行編排。

2 基于ESB架構(gòu)的醫(yī)療業(yè)務(wù)分析

無論是SOA中的S還是ESB中的S都代表著Service（服務(wù)），可見服務(wù)的重要作用。在ESB項目實施過程中，包括從調(diào)研到設(shè)計實施以及后來的持續(xù)維護，都要圍繞著Service進行。

在業(yè)務(wù)分析過程中，要區(qū)分出業(yè)務(wù)流程的粒度。ESB應(yīng)該只關(guān)心粗粒度的流程環(huán)節(jié)，將這些流程環(huán)節(jié)提煉成為ESB Service，將這些服務(wù)注冊到ESB架構(gòu)中，參與ESB消息的業(yè)務(wù)處理。

業(yè)務(wù)分析過程中，需要用到一些分析工具，以圖形化的方式描述業(yè)務(wù)交互過程，如圖1所示：

圖1 業(yè)務(wù)流程分析圖

圖中就將各個業(yè)務(wù)信息系統(tǒng)（不同的條帶代表不同系統(tǒng)）中的業(yè)務(wù)服務(wù)提煉成為ESB服務(wù)參與到業(yè)務(wù)流程中，這個流程就是門診醫(yī)技檢查驅(qū)動的業(yè)務(wù)流程，包括檢查申請單的產(chǎn)生、檢查預(yù)約到檢、一直到最后的檢查報告的反饋。

在我們實際的ESB項目中針對醫(yī)技檢驗檢查整理出類似的流程共達22個。

3 醫(yī)療業(yè)務(wù)服務(wù)的定義

我們在實際項目中定義SOA服務(wù)時遵循了以下幾個原則：

1） 服務(wù)邊界清晰、粒度合適

此處服務(wù)的邊界，可以簡單理解為服務(wù)需要對外隱藏內(nèi)部細節(jié)通過接口發(fā)布服務(wù)功能。SOA服務(wù)的粒度要定義的比較合適，我們知道在一個信息系統(tǒng)內(nèi)部也存在著各種服務(wù)，這些服務(wù)更多的是面向業(yè)務(wù)邏輯的服務(wù)，也因此這些服務(wù)需要細粒度或者說需要保持原子態(tài)以保證其在系統(tǒng)內(nèi)部不斷被復(fù)用。而SOA服務(wù)則需要定義為粗粒度的服務(wù)，比如醫(yī)技檢查申請單除了包括申請單本身的信息屬性（申請單號、申請科室、申請時間等）也要包括病人的基本信息（姓名、性別、年齡）以及繳費信息等等。

2） 基于架構(gòu)（Schema）和契約（Contract）定義服務(wù)（而不是類）

全院內(nèi)部存在多種異構(gòu)系統(tǒng)，比如對J2EE和.NET而言，擁有不同的運行環(huán)境以及底層的基礎(chǔ)平臺，想通過交換兩者的平臺細節(jié)來達到共享服務(wù)的目的幾乎是不可能的。只有在契約中明確消息的架構(gòu)細節(jié)才能夠在異構(gòu)平臺之間共享服務(wù)。在我們的項目中，定義了兩個層次的消息Schema，下面段落會有詳細介紹。

3） 策略驅(qū)動原則

要想在服務(wù)使用者和提供者之間共享服務(wù)，除了基于架構(gòu)定義服務(wù)消息還要有一些元數(shù)據(jù)來為消息服務(wù)，而這些元數(shù)據(jù)是以策略的形式存在于全局以保證各方都可以識別這些策略，包括加密策略、傳輸綁定策略、簽名策略等等。在實際的ESB項目中大多數(shù)ESB產(chǎn)品都支持多種數(shù)據(jù)傳輸協(xié)議，在次不再累述。我們的ESB項目中的傳輸加密策略主要對以下兩種方式進行了選擇，一種是對消息加密，另外一種是對傳輸（Transport）進行加密，前者對傳輸性能會有一定的損失，但是對傳輸環(huán)境的適應(yīng)性強，而后者就需要每兩個傳輸節(jié)點（endpoint）之間，都需要對傳輸管道進行加密。

4 服務(wù)消息的Schema定義

基于上文提到的第二個原則，我們定義了兩個層次的服務(wù)消息。

1） 全局消息的Schema大致如下：

其中，ESBHeader節(jié)點主要用于定義ESB消息分類、消息版本、消息創(chuàng)建的時間；ESBBody主要包含了業(yè)務(wù)數(shù)據(jù)，其中業(yè)務(wù)數(shù)據(jù)是以XSD:Any的類型定義的，也因此這個節(jié)點是通用的，可以包含任意結(jié)構(gòu)的業(yè)務(wù)數(shù)據(jù)；最后ESBFault節(jié)點用于存儲通信過程中的錯誤信息。

2） 業(yè)務(wù)消息的Schema定義大致如下：

其中各個業(yè)務(wù)字段是服務(wù)提供方和使用方共同關(guān)心的，并且需要使用方進行解析的。

5 ESB的框架設(shè)計

現(xiàn)階段有多種ESB產(chǎn)品可供選擇，一個成熟的ESB產(chǎn)品至少需要以下的核心功能：

1） 多種適配器支持不同傳輸協(xié)議

2） 可視化的服務(wù)編排設(shè)計器（針對粗粒度的SOA服務(wù)而言）

3） 業(yè)務(wù)流程管理（BPM）

我們在項目中選擇了Biztalk Server ESB Toolkit做為ESB框架。Biztalk ESB的基本架構(gòu)，如圖2所示：

圖2 Biztalk ESB基本架構(gòu)

其中，入口（On-ramp）和出口（Off-ramp）可支持多種適配器；線路服務(wù)（Itineray Services）支持可視化的線路設(shè)計器，該設(shè)計器可針對SOA服務(wù)進行消息流經(jīng)線路的設(shè)計并可以對線路版本進行控制。在項目實際開發(fā)過程中，需要頻繁進行設(shè)計配置的部分，主要就是線路設(shè)計器和業(yè)務(wù)規(guī)則引擎（BRE）。上圖只是濃縮的核心模塊說明，詳細的功能模塊說明可以參考相關(guān)文檔。

整體的ESB項目框架，如圖3所示：

圖3 ESB總體框架

其中，SOA服務(wù)，主要包括各種類型的醫(yī)技檢查電子申請單、檢查預(yù)約、檢查記賬、檢查報告的服務(wù)，這些服務(wù)可能是某個系統(tǒng)提供的服務(wù)，也可能是需要對多個系統(tǒng)提供的服務(wù)進行重新組合后產(chǎn)生的新的標(biāo)準(zhǔn)化的SOA服務(wù)。

6 醫(yī)療業(yè)務(wù)消息場景

項目中經(jīng)過對相關(guān)業(yè)務(wù)流程的調(diào)研，整理出以下幾種ESB消息流轉(zhuǎn)場景：

1） 簡單路由消息場景

如圖4所示：

圖4 簡單路由消息場景

服務(wù)使用方（圖中的 Client）通過ESB解析器（ESB Resolver）解析到服務(wù)提供方的物理 URI（路徑 1）然后發(fā)送消息給服務(wù)提供方（路徑2）。

此種場景主要目的就是降低服務(wù)調(diào)用方和提供方的耦合，調(diào)用方無需了解提供方的位置、協(xié)議、甚至消息格式的改變，這些問題全部由ESB來解決。此種場景在我們的項目中大量存在，比如醫(yī)技檢查預(yù)約的確認，預(yù)約的取消，獲取預(yù)約狀態(tài)等等。

以預(yù)約確認過程為例來說明該場景下的消息流轉(zhuǎn)的步驟：

消息發(fā)送方發(fā)送預(yù)約確認消息給ESB

ESB通過消息類型判斷該消息應(yīng)該路由的目的地，期間會通過SOA服務(wù)查找等功能。

消息通過動態(tài)發(fā)送端口發(fā)送消息給接收方，目的地址、傳輸協(xié)議都是按照配置動態(tài)改變的。發(fā)送方無需知道這些細節(jié)。

如果消息內(nèi)容格式發(fā)生了一定的變化，這個變化可以由ESB來應(yīng)對，比如預(yù)約信息中的確認狀態(tài)值在發(fā)送方和接收方之間不一致的情況下可以由ESB做映射轉(zhuǎn)換。

2） 消息轉(zhuǎn)發(fā)場景

如圖5所示：

圖5 消息轉(zhuǎn)發(fā)場景

服務(wù)使用方發(fā)送的消息經(jīng)過ESB轉(zhuǎn)發(fā)處理，轉(zhuǎn)發(fā)給了哪些服務(wù)，各服務(wù)的細節(jié)對使用方而言都是透明的。這些消息的轉(zhuǎn)發(fā)都是在ESB線路設(shè)計器（Itinerary Designer）中進行配置。

以獲取醫(yī)技申請單明細的過程為例來說明此種場景：

服務(wù)使用方發(fā)送的查詢信息給ESB

ESB根據(jù)發(fā)送方的消息類型，決定調(diào)用已經(jīng)設(shè)計完成的線路（Itinerary），路線中已經(jīng)包含了幾個SOA服務(wù)，其中有提供申請單明細信息的服務(wù)（可能是 EMR系統(tǒng)提供），還有計算檢查項目費用的服務(wù)（可能是HIS系統(tǒng)提供），ESB要做的就是在多個服務(wù)之間轉(zhuǎn)發(fā)消息并將最終的消息整合之后會傳給調(diào)用方。

3） 發(fā)布訂閱場景

如圖6所示：

圖6 消息發(fā)布訂閱場景

服務(wù)發(fā)布消息到 ESB，相應(yīng)的消息訂閱方就會接收到符合各自格式要求的消息。

我們以醫(yī)技檢查報告為例來說明：

RIS系統(tǒng)作為報告發(fā)布方調(diào)用ESB接口發(fā)布報告，報告的消息體中包含有消息類型。

已經(jīng)在ESB中注冊并訂閱了該類型消息的服務(wù)方（比如EMR系統(tǒng)）就可以接收到該消息。

在消息傳送給EMR之前，消息可以在ESB中進行轉(zhuǎn)換，以符合EMR的消息格式。

7 總結(jié)

我院自2011年5月開始部署ESB系統(tǒng)，至今已運行了半年時間，系統(tǒng)運行相當(dāng)穩(wěn)定，并且已體現(xiàn)出一定價值：

1） 技術(shù)上做到了服務(wù)使用方和提供方之間的低耦合，系統(tǒng)間關(guān)聯(lián)度下降。

2） 更加靈活地應(yīng)對業(yè)務(wù)上的變化。

例如：我院目前檢查預(yù)約的工作由檢查預(yù)約中心負責(zé)，為了能夠讓患者能享受更便利的預(yù)約服務(wù)，我院將推動門診診間檢查預(yù)約的工作。目前預(yù)約服務(wù)都已經(jīng)發(fā)布到ESB系統(tǒng)上，實現(xiàn)以上業(yè)務(wù)流程改造就變得很簡單，只要在門診醫(yī)生站中調(diào)用檢查預(yù)約的相關(guān)服務(wù)即可完成。

3） 醫(yī)院信息系統(tǒng)建造思路的轉(zhuǎn)變。原有的系統(tǒng)建設(shè)模式：

這種模式下，新建的業(yè)務(wù)系統(tǒng)需要了解其需要的服務(wù)由哪一方提供，服務(wù)具體的技術(shù)細節(jié)以及定義好的服務(wù)接口不能有絲毫改變。

新的系統(tǒng)建設(shè)模式：

以服務(wù)總線以及在總線上部署的多種醫(yī)療業(yè)務(wù)服務(wù)為基礎(chǔ)，對今后新建的醫(yī)療業(yè)務(wù)系統(tǒng)而言，在設(shè)計開發(fā)前期首先要做的工作，就是在ESB中查找是否存在已有的服務(wù)可供使用，如果沒有就在ESB上建設(shè)服務(wù)接口，之后系統(tǒng)本身的業(yè)務(wù)設(shè)計依賴于這個服務(wù)接口，這個服務(wù)具體有哪一方實現(xiàn)新建的系統(tǒng)無需關(guān)心。

4） ESB作為公共服務(wù)提供方的平臺。

我院ESB平臺上部署了統(tǒng)一授權(quán)系統(tǒng)服務(wù)，統(tǒng)一用戶系統(tǒng)服務(wù)。依托這些服務(wù)未來的業(yè)務(wù)系統(tǒng)，只需要通過ESB平臺接口使用這些服務(wù)，就可以方便的實現(xiàn)權(quán)限和用戶的管理。

[1]Thomas Erl. SOAPrinciplesofServiceDesign[M].U.S.:Prentice Hall PTR, 2007: 62-67

[2]Ken Vollmer. The Forrester Wave?:Enterprise Service Buses[R]. Forrester Research, Inc. Q2 2011.

[3]Wen Rui, Ma Yaping, Chen Xiaoqing.ESB Infrastructure's Autonomous Mechanism of SOA.Chengdu: 2009 International Symposium on Intelligent Ubiquitous Computing and Education[C], 2009, pp.13-17.

[4]Paul Brebner. Service-Oriented Performance Modeling the MULE Enterprise Service Bus (ESB) Loan Broker Application.Patras: 2009 35th Euromicro Conference on Software Engineering and Advanced Applications[C],2009, pp.404-411.