企業服務總線在醫療領域的實際應用

王 奕，黃宗浩

0 引言

ESB是Enterprise Service Bus（企業服務總線）的縮寫。

Forrester研究公司將ESB技術描寫成“通過起到中間層作用而實現面向服務架構（SOA）的軟件基礎設施，通過這樣的中間件，就能廣泛利用一套可重復使用的商業服務。”

“許多SOA項目在很大程度都將ESB作為其核心的軟件基礎設施。這是因為在一個ESB產品中捆綁了許多解決方案來應對各種不同的挑戰。舉例而言，ESB能夠將消息在多種通信協議之間路由、在多種格式之間進行轉換；將業務服務重新組合封裝成標準行為；對服務水平協議（SLA）進行監控和管理；與安全基礎設施的緊密集成。”

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

1 醫院實施ESB的基本過程

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

實施ESB的大致過程包括：針對業務流程進行調研分析，提煉粗粒度的業務服務，定義接口規范，部署ESB產品，根據接口規范實現SOA服務，注冊SOA服務到ESB平臺，按照業務需求對SOA服務進行編排。

2 基于ESB架構的醫療業務分析

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

在業務分析過程中，要區分出業務流程的粒度。ESB應該只關心粗粒度的流程環節，將這些流程環節提煉成為ESB Service，將這些服務注冊到ESB架構中，參與ESB消息的業務處理。

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

圖1 業務流程分析圖

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

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

3 醫療業務服務的定義

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

1） 服務邊界清晰、粒度合適

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

2） 基于架構（Schema）和契約（Contract）定義服務（而不是類）

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

3） 策略驅動原則

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

4 服務消息的Schema定義

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

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

其中，ESBHeader節點主要用于定義ESB消息分類、消息版本、消息創建的時間；ESBBody主要包含了業務數據，其中業務數據是以XSD:Any的類型定義的，也因此這個節點是通用的，可以包含任意結構的業務數據；最后ESBFault節點用于存儲通信過程中的錯誤信息。

2） 業務消息的Schema定義大致如下：

其中各個業務字段是服務提供方和使用方共同關心的，并且需要使用方進行解析的。

5 ESB的框架設計

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

1） 多種適配器支持不同傳輸協議

2） 可視化的服務編排設計器（針對粗粒度的SOA服務而言）

3） 業務流程管理（BPM）

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

圖2 Biztalk ESB基本架構

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

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

圖3 ESB總體框架

其中，SOA服務，主要包括各種類型的醫技檢查電子申請單、檢查預約、檢查記賬、檢查報告的服務，這些服務可能是某個系統提供的服務，也可能是需要對多個系統提供的服務進行重新組合后產生的新的標準化的SOA服務。

6 醫療業務消息場景

項目中經過對相關業務流程的調研，整理出以下幾種ESB消息流轉場景：

1） 簡單路由消息場景

如圖4所示：

圖4 簡單路由消息場景

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

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

以預約確認過程為例來說明該場景下的消息流轉的步驟：

消息發送方發送預約確認消息給ESB

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

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

如果消息內容格式發生了一定的變化，這個變化可以由ESB來應對，比如預約信息中的確認狀態值在發送方和接收方之間不一致的情況下可以由ESB做映射轉換。

2） 消息轉發場景

如圖5所示：

圖5 消息轉發場景

服務使用方發送的消息經過ESB轉發處理，轉發給了哪些服務，各服務的細節對使用方而言都是透明的。這些消息的轉發都是在ESB線路設計器（Itinerary Designer）中進行配置。

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

服務使用方發送的查詢信息給ESB

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

3） 發布訂閱場景

如圖6所示：

圖6 消息發布訂閱場景

服務發布消息到 ESB，相應的消息訂閱方就會接收到符合各自格式要求的消息。

我們以醫技檢查報告為例來說明：

RIS系統作為報告發布方調用ESB接口發布報告，報告的消息體中包含有消息類型。

已經在ESB中注冊并訂閱了該類型消息的服務方（比如EMR系統）就可以接收到該消息。

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

7 總結

我院自2011年5月開始部署ESB系統，至今已運行了半年時間，系統運行相當穩定，并且已體現出一定價值：

1） 技術上做到了服務使用方和提供方之間的低耦合，系統間關聯度下降。

2） 更加靈活地應對業務上的變化。

例如：我院目前檢查預約的工作由檢查預約中心負責，為了能夠讓患者能享受更便利的預約服務，我院將推動門診診間檢查預約的工作。目前預約服務都已經發布到ESB系統上，實現以上業務流程改造就變得很簡單，只要在門診醫生站中調用檢查預約的相關服務即可完成。

3） 醫院信息系統建造思路的轉變。原有的系統建設模式：

這種模式下，新建的業務系統需要了解其需要的服務由哪一方提供，服務具體的技術細節以及定義好的服務接口不能有絲毫改變。

新的系統建設模式：

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

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

我院ESB平臺上部署了統一授權系統服務，統一用戶系統服務。依托這些服務未來的業務系統，只需要通過ESB平臺接口使用這些服務，就可以方便的實現權限和用戶的管理。

[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.