將 Enterprise Service Bus 用於醫療保健
這篇由兩部分組成的文章將演示各種醫療保健相關的服務通過一個服務總線進行聚合，我稱 之為（可能不夠准確）Healthcare Service Bus (HSB)。在第 1 部分中，我將介紹一個用例場 景，其中為病人服務的各種應用程序需要連接到 HSB，我將解釋 HSB 應當提供的特性。接下來 ，我將介紹 Java Business Integration (JBI) 架構，它用於構建 HSB。按照以下順序了解發 生在 JBI 服務器內部的事件，您將了解到 JBI 如何在內部用於業務集成，以及其組件如何與 外部應用程序協同。第 1 部分的最後一章將提供配置實例，它將演示如何控制 JBI 組件行為 ，以使其用於醫療保健。在第 2 部分中，您將學習如何使用開源 JBI 實現 (Apache ServiceMix)現有的功能以及通過實現 ServiceMix 新功能集成醫療保健服務。
醫療保健服務總線
HSB 集成了大量醫療保健相關的服務。想象一下需要救命的緊急病人的需求，包括輸血、緊 急處方和放射檢查。
當病人到達醫療機構，主治醫生使用服務總線通過病人手機上運行的應用程序查看過敏史。 醫生還可將對病人最初情況的觀察輸入到連接到總線的醫療處方應用程序中。醫生的觀察通過 服務總線傳送到托管病人所在保險公司門戶網站的 Web 服務器。
醫生然後在相同的處方應用程序中開具輸血處方。然後處方自動通過服務總線不僅傳送到血 庫，還傳送到捐贈組織應用程序中，它將向那些血液樣本預先與病人配型成功的捐贈者發送短 信。對捐贈組織應用程序的需求也通過服務總線傳送。
醫生還會開具緊急藥物和放射檢查處方，這些也輸入同樣的處方應用程序。處方應用程序通 過總線發送處方到醫療機構內部的藥房和放射科。
服務聚合
您可以看到在該用例中，HSB 允許各種應用程序相互連通，相互操作，從而聚合服務。應用 程序的兩種主要類型 — 服務使用者和服務提供者 — 連接到 HSB。向 HSB 發送輸血需求的處 方應用程序作為服務使用者（請求或使用服務的應用程序）。向潛在血液捐贈者發送短信的捐 贈組織應用程序作為服務提供者（提供所請求服務的應用程序）。相互連通 和 相互操作 是不 同的需求，它們共同提供了服務聚合。相互連通 意思是服務提供者和服務使用者有一種通用方 式可以連接（到達）對方，從而可以 相互操作 對方（交互信息和消息）。HSB 使用通用的 XML 格式相互交換消息。
HSB 作為 SOA
像 HSB 這樣嚴重依賴 “服務” 的架構稱作 Service Oriented Architecture (SOA)。SOA 就是說一切皆服務。發送短信的捐贈組織應用程序是服務。放射科也是一個服務，它根據需要 進行放射檢查。在 SOA 中，任何公開服務的應用程序都是服務提供者，要求、請求或使用服務 的應用程序都是服務使用者。
圖 1 顯示服務提供者和服務使用者連接到 HSB：
圖 1. 服務提供者和服務使用者連接到 HSB
請注意 圖 1 顯示三個服務提供者連接到 HSB：Insurance Company Portal、Donor Group 和 Radiology Department 應用程序。HSB 應當能將服務使用者連接到內部和外部的服務提供 者，以便它們能相互操作。在 圖 1 中，Radiology Department 應用程序在醫療機構內部； Donor Group 和 Insurance Company Portal 應用程序在醫療機構外部。
所需的 HSB 特性
為了確保相互連通，HSB 必須：
記錄所有連接的服務提供者，以便它能將服務使用請求從服務使用者路由到正確的服務提供 者。
提供一種標准機制，讓服務提供者和服務使用者通過服務總線相互對話。
允許其他 HSB 與其相互連接。
HSB 相互連接
HSB 的相互連接是個有趣的應用程序，其架構如圖 2 所示：
圖 2. HSB 的相互連接
圖 2 顯示了兩個不同醫療機構的 HSB。其中一個機構有個 Blood Bank 應用程序， Prescription 應用程序可以通過兩個 HSB 的互聯進行調用。
用於互操作醫療保健的 XML
將 XML 用於醫療保健服務互操作有兩種方式：
Web 服務：基於 Web Services Description Language (WSDL) 和 Simple Object Access Protocol (SOAP) 的 Web 服務在很多行業（包括醫療保健）中經常使用。WSDL 使用 XML 來定 義服務；即，定義服務提供的接口。SOAP 是基於 XML 的協議，用於在服務提供者和使用者之 間提供實際的消息交換。HSB 應該能夠與任何使用 WSDL 和 SOAP 的醫療保健應用程序相互連 接。
Health Level 7：Health Level 7 (HL7) 是一組通用的醫療保健標准，它定義了很多用於 指定醫療保健信息的數據結構，例如醫療記錄、處方、病人出院摘要。（早期的 HL7 版本 1 和 2 基於 ASCII。最新的 HL7 版本 3.X 使用 XML 作為定義消息結構的數據格式。）
將 HSB 普及到其他行業
此處討論的相互連接和相互操作需求，除了醫療保健，也適用於其他行業。例如，旅游業的 各種服務 — 酒店、航空公司、汽車租賃和旅游經營者 — 需要能相互連接相互操作來服務客 戶。HSB 的 三個相互連接特性 也適用於旅游業。不同的服務提供者，如旅館和汽車租賃，可 以輕松使用 WSDL 和 SOAP 相互操作。特定行業的基於 XML 的標准，如 HL7，任何行業都會存 在。
我將演示的 HSB 能與使用 WSDL、SOAP 和 HL7 標准的醫療保健應用程序相互連接。
ESB：一個用於相互操作和相互連接的一般架構
這樣的用於相互操作和相互連接的一般架構通常是指 Enterprise Service Bus (ESB)，它 能夠：
基於 SOA。
允許服務提供者和使用者使用 WSDL 和 SOAP。
具備可擴展性和靈活性，它允許服務提供者和使用者使用特定行業基於 XML 的標准，如 HL7。
ESB 不是新構想。目前有幾種 ESB 實現。這意味著不必從頭開始構建 HSB。可以配置現有 的 ESB 用於醫療保健。
將 JBI 用作 HSB
JBI 規范定義了標准的 Java 業務集成環境。JBI 提供了我所講述的所有 ESB 特性，因此 我將用它來構建 HSB。
有幾個 JBI 實現可用，包括流行的來自於 Apache 的稱為 ServiceMix 的開源實現。該系 列其余部分關於使用 JBI 以及配置 ServiceMix 來構建 HSB。
JBI 組件共同用於醫療保健
圖 3 顯示 JBI 如何用作 HSB：
圖 3. JBI 用作 HSB
在 圖 3 中可以看到 JBI 有三個主要部件，是 Binding Components (BCs)、Service Engines (SEs) 和 Normalized Message Router (NMR)。
我將借助當 Prescription 應用程序（服務使用者）連接到 Donor Group 應用程序（服務 提供者）時所發生的一個事件序列（如圖 4 所示）來解釋 JBI 組件的工作方式：
圖 4. 服務使用者通過 JBI 連接到服務提供者
圖 4 中出現的序列如下：
第 1 步：Prescription 應用程序（服務使用者）連接到 JBI 並要求 Donor Group 應用程 序（位於 JBI 環境外的服務提供者）提供的服務。
第 2 步：JBI 環境將服務請求發送到合適的 BC — 它接收來自 Prescription 應用程序的 所有服務。每一個與 JBI 協同工作的服務使用者或提供者在 JBI 環境中都有一個專用 BC。
第 3 步：BC 將服務調用請求轉換成 JBI 規范定義的規范化格式。定義規范化格式的目的 是允許 BC 之間相互操作。所有 JBI BC 都理解規范化格式。每個 BC 還理解 BC 所附屬的服 務提供者或使用者的格式。換句話說， JBI 的規范化特性就是所有 BC 將從各自的消息使用者 或提供者接收到的消息轉換成通用格式。
第 4 步：Prescription 應用程序的 BC 將規范化信息移交給 圖 4 中所示的 NMR。整個 JBI 環境包含一個 NMR。
第 5 步：NMR 的工作是從 BC 接收規范化信息，確認目標服務提供者，並傳送（路由）規 范化消息到另一個目標服務 BC。在這一步，NMR 將規范化消息發送到連接 Donor Group 應用 程序的 BC。
第 6 步: Donor Group 應用程序的 BC 對規范化消息解除規范化，從而將它轉換成 Donor Group 應用程序可以理解的格式。
第 7 步: BC 將解除規范化的消息移交給 Donor Group 應用程序。
事件序列揭示了關於 JBI 的簡單的兩點：
JBI 運行基於 規范化消息路由 的構想。每個消息被 BC 規范化，並移交到 NMR。NMR 將消 息路由到另一個 BC，它將消息解除規范化，轉換成目標服務提供者能理解的格式。
規范化消息路由機制提供了解耦 結構。解耦意味著服務提供者和使用者只通過 NMR 機制進 行交互。它們不直接交互。
這種解耦架構的主要好處就是只需實現一次特定的數據格式或標准，以 BC 的形式。以後， 所有根據特定格式提供服務的服務提供者只要簡單使用 BC 實例來集成到 JBI 環境。
例如，如果必須要集成 HL7 到 JBI，就需要一個理解 HL7 的 BC。如果有 HL7 BC，可以將 任何 HL7 服務集成到 JBI，從而形成 HSB。
本系列的第 2 部分將給出構建基於 HL7 的 BC 和將 HL7 集成到 JBI 的實際步驟。但是現 在，還有更多關於 JBI 的內容要學習。
將內部和外部服務混合到 JBI 中
此處的論述以及 圖 4 演示了服務使用者和處於 JBI 環境外的服務提供者的通信。
回想在一下本文開頭的用例中，Prescription 應用程序還向內部放射科發送消息。這意味 著 JBI 環境還應當能托管 Radiology Department 應用程序作為內部服務。JBI 中的內部服務 作為 SE。
SE 和 BC 基本一樣，只多出一個特性：SE 還包含內部服務（例如，Radiology Department 應用程序）的業務邏輯。BC 和 SE 都連接到 JBI 的 NMR，如 圖 3 所示，我在圖 5 中做了些 修改，以便演示作為 SE 的 Radiology Department 應用程序：
圖 5. 作為 SE 的 Radiology Department 應用程序
訪問內部服務（即，SE）的事件序列如圖 6 所示：
圖 6. 服務使用者訪問內部服務提供者
圖 6 的事件序列表示出了當服務使用者如 Prescription 應用程序發送消息給 Radiology Department 應用程序（內部服務提供者）所發生的事件：
第 1 步：Prescription 應用程序（服務使用者）連接到 JBI 並要求 Radiology Department 提供服務。
第 2 步：JBI 環境將服務請求發送到 Prescription 應用程序的 BC。
第 3 步：BC 將服務調用請求轉換成規范化消息。
第 4 步：BC 將規范化消息移交給 NMR。
第 5 步：NMR 將規范消息發送到 Radiology Department 應用程序（SE）。
第 6 步：SE 在內部將消息解除規范化，並調用所需的業務邏輯。
事件序列 — 與 圖 4 中演示的事件序列很像 — 顯示了 SE 包含 BC 的功能和服務提供程 序的業務邏輯。
似乎 SE 不必要混合兩種不同的東西（BC的功能和業務邏輯）。在第 2 部分中，我將向你 演示如何在現有 BC 之上構建內部服務的業務邏輯，而不需要混在一起。
相互連接基於 JBI 的 ESB
還回到 圖 2，其中我演示了 HSB 的相互連接。這種相互連接可以通過 JBI 實現，如圖 7 所示：
圖 7. 兩個相互連接的 JBI 環境
請注意 圖 7 中顯示了不同的應用程序連接到兩個獨立的 JBI 環境。當 Prescription 應 用程序（在 圖 7 中顯示連接到第一個 JBI）發送消息到 Blood Bank 應用程序（位於第二個 JBI 環境的服務提供者）會按照順序發生以下事件：
第 1 步：Prescription 應用程序（服務使用者）連接到第一個 JBI 並要求 Blood Bank 應用程序提供服務。
第 2 步：第一個 JBI 環境發送請求到 Prescription 應用程序的 BC。
第 3 步：Prescription 應用程序的 BC 將服務調用請求轉換成規范化消息。
第 4 步：Prescription 應用程序將規范化消息移交給 NMR。
第 5 步：NMR 將規范化消息發送給連接到第二個 JBI 環境的 BC。
第 6 步：連接到第二個 JBI 環境的 BC 將消息解除規范化。
第 7 步：連接到第二個 JBI 環境的 BC 將解除規范化的消息移交給第二個 JBI 環境。
第 8 步：第二個 JBI 環境接收請求，並將它發送到連接第一個 JBI 環境的 BC。這意味著 兩個 JBI 環境通過合適的 BC 相互連接。
第 9 步：連接第一個 JBI 環境的 BC 將把服務調用請求轉換成規范化消息。
第 10 步：連接第一個 JBI 環境的 BC 將規范化消息移交給 NMR。
第 11 步：NMR 發送規范化消息給 Blood Bank 應用程序（SE）。
第 12 步：SE 在內部將消息解除規范化並調用所需業務邏輯。
JBI 中的消息交換模式
前面的講解及圖 4、5、6 和 7 演示了一種單向通信 — 從服務使用者發送消息給服務提供 者。服務提供者（例如 Donor Group 應用程序）不發送返回信息。JBI 文檔將這種類型消息傳 遞稱為 in-only 消息交換。in-only 消息交換模式適用於 Donor Group 應用程序這樣的服務 ，它只要將單向消息送到組織中。不需要返回信息到請求的 Prescription 應用程序中。
其他一些服務（例如 Insurance Company Portal 應用程序）也許會被要求返回響應。這種 請求-響應消息模式在 JBI 中也是允許的，被稱為 in-out。您也許會猜到，響應也是以同樣方 式通過 JBI 環境 — BC、SE 和 NMR — 從服務提供者發出，最終到達服務使用者。因此我不 再講述 in-out 消息傳送的事件順序。
配置和引導 JBI 環境
JBI 規范提供了詳細的 XML 模式，它用於定義所希望在 JBI 中托管的所有 BC 和 SE 的行 為。現在我將描述如何能使用 JBI 模式來配置 JBI 實現作為 HSB。
本文中不會討論整個 JBI 模式。我將重點講解重要的 JBI 標記，稱為 <component> 。第 2 部分將會演示更多 JBI 模式標記的使用。
<component> 標記定義 JBI 組件。組件可以是 BC 或 SE。清單 1 顯示 Prescription 應用程序的 BC 的 MXL 配置是什麼樣子：
清單 1. prescription 應用程序的 BC 的 XML 配置
<?xml version="1.0" encoding="UTF-8"?>
<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">
<component type="binding-component"
component-class-loader-delegation="parent-first"
bootstrap-class-loader-delegation="parent-first">
<identification>
<name>Prescription-Application</name>
<description>Binding Component for the prescription application</description>
</identification>
<component-class-name>
org.apache.servicemix.cxfbc.CxfBcComponent
</component-class-
<component-class-path>
<path-element>lib/servicemix-cxf-bc-2009.01.jar</path-element>
<path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path- element>
<!-- other path-element tags -->
</component-class-path>
<bootstrap-class-name>
org.apache.servicemix.common.DefaultBootstrap
</bootstrap-class-name>
<bootstrap-class-path>
<path-element>lib/servicemix-cxf-bc-2009.01.jar</path-element>
<path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path- element>
<!-- other path-element tags -->
</bootstrap-class-path>
</component>
</jbi>
可以看到 清單 1 包含 <component> 標記，它有一個 type 屬性，五個子標記，名 為 <identification>、<component-class-name>、 <component-class- path>、<bootstrap-class-name> 和 <bootstrap-class-path>。
type 屬性指定組件是 BC 還是 SE。清單 1 配置的是 Prescription 應用程序的 BC，因此 type 屬性值應當是 binding-component。
清單 1 中的 <identification> 標記提供了 BC 的名稱和描述。
<component-class-name> 標記指定實現 BC 所需的邏輯的 Java 類。JBI 規范有個 標准接口名為 javax.jbi.component.Component，所有 BC 都應當實現。本系列中我將使用 Apache ServiceMix 來演示 HSB 如何工作。ServiceMix 提供 BC，它可用於與使用基於 SOAP 的 Web 服務的服務使用者協同工作。實現這個 BC 的邏輯的類名為 org.apache.servicemix.cxfbc.CxfBcComponent。在第 2 部分中，我將用這個類來演示 Prescription 應用程序如何與 JBI 一起工作。這就是在 清單 1 中包含 org.apache.servicemix.cxfbc.CxfBcComponent 作為包裝在 <component-class-name> 標記中的組件類的名稱的原因。
現在看看 清單 1 中的 <component-class-path> 標記。它有兩個子標記，名為 <path-element>。 這些標記指定執行組件類需要的所有 JAR 文件的路徑。這意味著 <component-class-name> 和 <component-class-path> 標記形成一對，來指定 BC 的 Java 類的名稱以及用於執行 Java 類的完整類路徑。
清單 1 還包含另一對標記，名為 <bootstrap-class-name> 和 <bootstrap- class-path>。這一對與前一對 <component-class-name> 和 <component-class -path> 標記相似。引導對指定實現引導 BC 的 Java 類的名稱和類路徑。
引導意味著讓 BC 投入服務。在啟動 JBI 服務器（ServiceMix）時開始引導。引導類包含 所有將 BC 激活、啟動和運行的邏輯。
現在看看清單 2 中的 <component> 標記，它表示外部服務提供者，如 Donor Group 應用程序。清單 2 和 清單 1 有一模一樣的結構，因此無需多解釋。
清單 2. 外部服務提供者的 XML 配置
<?xml version="1.0" encoding="UTF-8"?>
<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">
<component type="binding-component"
component-class-loader-delegation="parent-first"
bootstrap-class-loader-delegation="parent-first">
<identification>
<name>Donor-Group-Application</name>
<description>Binding Component for the Donor Group application</description>
</identification>
<component-class-name>
org.apache.servicemix.cxfbc.CxfBcComponent
</component-class-
<component-class-path>
<path-element>lib/servicemix-cxf-bc-2009.01.jar</path-element>
<path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path- element>
<!-- other path-element tags -->
</component-class-path>
<bootstrap-class-name>
org.apache.servicemix.common.DefaultBootstrap
</bootstrap-class-name>
<bootstrap-class-path>
<path-element>lib/servicemix-cxf-bc-2009.01.jar</path-element>
<path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path- element>
<!-- other path-element tags -->
</bootstrap-class-path>
</component>
</jbi>
清單 3 顯示另一個 <component> 標記，它描述了如何配置 SE — 一個內部服務提 供者（例如 Radiology Department 應用程序）：
清單 3. 內部服務提供者的 XML 配置
<?xml version="1.0" encoding="UTF-8"?>
<jbi xmlns="http://java.sun.com/xml/ns/jbi" version="1.0">
<component type="service-engine"
component-class-loader-delegation="parent-first"
bootstrap-class-loader-delegation="parent-first">
<identification>
<name>Radiology-Department-Application</name>
<description>Radiology Department Service Application</description>
</identification>
<component-class-name>
org.hsb.radiology.RadiologyBean</component-class-name>
<component-class-path>
<path-element>lib/radiology-bean.jar</path-element>
<path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path- element>
<!-- other path-element tags -->
</component-class-path>
<bootstrap-class-name>
org.apache.servicemix.common.DefaultBootstrap
</bootstrap-class-name>
<bootstrap-class-path>
<path-element>lib/ radiology-bean.jar</path-element>
<path-element>lib/geronimo-annotation_1.0_spec-1.1.1.jar</path- element>
<!-- other path-element tags -->
</bootstrap-class-path>
</component>
</jbi>
如果將 清單 3 與 清單 2 對比，將會看到兩個主要區別：type 屬性值在 清單 2 中是 binding-component（因為是表示外部服務提供者的 BC），而 清單 3 中的 type 屬性值（以 粗體顯示）是 service-engine，因為它是表示內部服務的 SE。
未完待續
您已看到如何使用 JBI 的 <component> 標記來配置 BC 和 SE。JBI 還提供重用機 制來構建可用於各種場景的通用 BC。
JBI 實現如 ServiceMix 提供預置的 BC，它與實現捆綁在一起。您甚至不需要為這樣的 BC 配置 <component> 標記，因為實現已經知道這種 BC 的類和其他細節。
第 2 部分將各部分組合起來，演示如何使用 ServiceMix 現有功能以及構建和配置新功能 — 即，實現和配置 BC 或 SE — 來集成醫療保健服務。
