| 集成医疗保健服务，第 1 部分: 将 Enterprise Service Bus 用于医疗保健 | |||
| 摘自: 被阅读次数: 18 | |||
由 于 2010-07-06 22:47:49 提供 | |||
这篇由两部分组成的文章将演示各种医疗保健相关的服务通过一个服务总线进行聚合，我称之为（可能不够准确）Healthcare Service Bus (HSB)。在第 1 部分中，我将介绍一个用例场景，其中为病人服务的各种应用程序需要连接到 HSB，我将解释 HSB 应当提供的特性。接下来，我将介绍 Java Business Integration (JBI) 架构，它用于构建 HSB。按照以下顺序了解发生在 JBI 服务器内部的事件，您将了解到 JBI 如何在内部用于业务集成，以及其组件如何与外部应用程序协同。第 1 部分的{zh1}一章将提供配置实例，它将演示如何控制 JBI 组件行为，以使其用于医疗保健。在第 2 部分中，您将学习如何使用开源 JBI 实现 (Apache ServiceMix)现有的功能以及通过实现 ServiceMix 新功能集成医疗保健服务。
HSB 集成了大量医疗保健相关的服务。想象一下需要救命的紧急病人的需求，包括输血、紧急xx和放射检查。 当病人到达医疗机构，主治医生使用服务总线通过病人手机上运行的应用程序查看过敏史。医生还可将对病人最初情况的观察输入到连接到总线的医疗xx应用程序中。医生的观察通过服务总线传送到托管病人所在保险公司门户网站的 Web 服务器。 医生然后在相同的xx应用程序中开具输血xx。然后xx自动通过服务总线不仅传送到血库，还传送到捐赠组织应用程序中，它将向那些血液样本预先与病人配型成功的捐赠者发送短信。对捐赠组织应用程序的需求也通过服务总线传送。 医生还会开具紧急xx和放射检查xx，这些也输入同样的xx应用程序。xx应用程序通过总线发送xx到医疗机构内部的药房和放射科。
您可以看到在该用例中，HSB 允许各种应用程序相互连通，相互操作，从而聚合服务。应用程序的两种主要类型 — 服务使用者和服务提供者 — 连接到 HSB。向 HSB 发送输血需求的xx应用程序作为服务使用者（请求或使用服务的应用程序）。向潜在血液捐赠者发送短信的捐赠组织应用程序作为服务提供者（提供所请求服务的应用程序）。相互连通 和 相互操作 是不同的需求，它们共同提供了服务聚合。相互连通 意思是服务提供者和服务使用者有一种通用方式可以连接（到达）对方，从而可以 相互操作 对方（交互信息和消息）。HSB 使用通用的 XML 格式相互交换消息。 图 1 显示服务提供者和服务使用者连接到 HSB： 
请注意 显示三个服务提供者连接到 HSB：Insurance Company Portal、Donor Group 和 Radiology Department 应用程序。HSB 应当能将服务使用者连接到内部和外部的服务提供者，以便它们能相互操作。在 中，Radiology Department 应用程序在医疗机构内部；Donor Group 和 Insurance Company Portal 应用程序在医疗机构外部。
为了确保相互连通，HSB 必须：
HSB 的相互连接是个有趣的应用程序，其架构如图 2 所示： 
显示了两个不同医疗机构的 HSB。其中一个机构有个 Blood Bank 应用程序，Prescription 应用程序可以通过两个 HSB 的互联进行调用。
将 XML 用于医疗保健服务互操作有两种方式：
我将演示的 HSB 能与使用 WSDL、SOAP 和 HL7 标准的医疗保健应用程序相互连接。
这样的用于相互操作和相互连接的一般架构通常是指 Enterprise Service Bus (ESB)，它能够：
ESB 不是新构想。目前有几种 ESB 实现。（查看 中常用开源 ESB 的链接。）这意味着不必从头开始构建 HSB。可以配置现有的 ESB 用于医疗保健。
JBI 规范定义了标准的 Java 业务集成环境。JBI 提供了我所讲述的所有 ESB 特性，因此我将用它来构建 HSB。 有几个 JBI 实现可用，包括流行的来自于 Apache 的称为 ServiceMix 的开源实现。该系列其余部分关于使用 JBI 以及配置 ServiceMix 来构建 HSB。
图 3 显示 JBI 如何用作 HSB： 
在 中可以看到 JBI 有三个主要部件，是 Binding Components (BCs)、Service Engines (SEs) 和 Normalized Message Router (NMR)。 我将借助当 Prescription 应用程序（服务使用者）连接到 Donor Group 应用程序（服务提供者）时所发生的一个事件序列（如图 4 所示）来解释 JBI 组件的工作方式： 
中出现的序列如下： 第 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 将规范化信息移交给 中所示的 NMR。整个 JBI 环境包含一个 NMR。 第 5 步：NMR 的工作是从 BC 接收规范化信息，确认目标服务提供者，并传送（路由）规范化消息到另一个目标服务 BC。在这一步，NMR 将规范化消息发送到连接 Donor Group 应用程序的 BC。 第 6 步: Donor Group 应用程序的 BC 对规范化消息解除规范化，从而将它转换成 Donor Group 应用程序可以理解的格式。
第 7 步: BC 将解除规范化的消息移交给 Donor Group 应用程序。 事件序列揭示了关于 JBI 的简单的两点：
这种解耦架构的主要好处就是只需实现一次特定的数据格式或标准，以 BC 的形式。以后，所有根据特定格式提供服务的服务提供者只要简单使用 BC 实例来集成到 JBI 环境。 例如，如果必须要集成 HL7 到 JBI，就需要一个理解 HL7 的 BC。如果有 HL7 BC，可以将任何 HL7 服务集成到 JBI，从而形成 HSB。 本系列的第 2 部分将给出构建基于 HL7 的 BC 和将 HL7 集成到 JBI 的实际步骤。但是现在，还有更多关于 JBI 的内容要学习。
此处的论述以及 演示了服务使用者和处于 JBI 环境外的服务提供者的通信。 回想在一下本文开头的用例中，Prescription 应用程序还向内部放射科发送消息。这意味着 JBI 环境还应当能托管 Radiology Department 应用程序作为内部服务。JBI 中的内部服务作为 SE。 SE 和 BC 基本一样，只多出一个特性：SE 还包含内部服务（例如，Radiology Department 应用程序）的业务逻辑。BC 和 SE 都连接到 JBI 的 NMR，如 所示，我在图 5 中做了些修改，以便演示作为 SE 的 Radiology Department 应用程序： 
访问内部服务（即，SE）的事件序列如图 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 在内部将消息解除规范化，并调用所需的业务逻辑。 事件序列 — 与 中演示的事件序列很像 — 显示了 SE 包含 BC 的功能和服务提供程序的业务逻辑。 似乎 SE 不必要混合两种不同的东西（BC的功能和业务逻辑）。在第 2 部分中，我将向你演示如何在现有 BC 之上构建内部服务的业务逻辑，而不需要混在一起。
还回到 ，其中我演示了 HSB 的相互连接。这种相互连接可以通过 JBI 实现，如图 7 所示： 
请注意 中显示了不同的应用程序连接到两个独立的 JBI 环境。当 Prescription 应用程序（在 中显示连接到{dy}个 JBI）发送消息到 Blood Bank 应用程序（位于第二个 JBI 环境的服务提供者）会按照顺序发生以下事件： 第 1 步：Prescription 应用程序（服务使用者）连接到{dy}个 JBI 并要求 Blood Bank 应用程序提供服务。 第 2 步：{dy}个 JBI 环境发送请求到 Prescription 应用程序的 BC。 第 3 步：Prescription 应用程序的 BC 将服务调用请求转换成规范化消息。 第 4 步：Prescription 应用程序将规范化消息移交给 NMR。 第 5 步：NMR 将规范化消息发送给连接到第二个 JBI 环境的 BC。 第 6 步：连接到第二个 JBI 环境的 BC 将消息解除规范化。 第 7 步：连接到第二个 JBI 环境的 BC 将解除规范化的消息移交给第二个 JBI 环境。 第 8 步：第二个 JBI 环境接收请求，并将它发送到连接{dy}个 JBI 环境的 BC。这意味着两个 JBI 环境通过合适的 BC 相互连接。 第 9 步：连接{dy}个 JBI 环境的 BC 将把服务调用请求转换成规范化消息。 第 10 步：连接{dy}个 JBI 环境的 BC 将规范化消息移交给 NMR。 第 11 步：NMR 发送规范化消息给 Blood Bank 应用程序（SE）。 第 12 步：SE 在内部将消息解除规范化并调用所需业务逻辑。
前面的讲解及图 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 规范提供了详细的 XML 模式，它用于定义所希望在 JBI 中托管的所有 BC 和 SE 的行为。现在我将描述如何能使用 JBI 模式来配置 JBI 实现作为 HSB。 本文中不会讨论整个 JBI 模式。我将重点讲解重要的 JBI 标记，称为
可以看到 包含
中的 <identification> 标记提供了 BC 的名称和描述。
现在看看 中的
还包含另一对标记，名为 引导意味着让 BC 投入服务。在启动 JBI 服务器（ServiceMix）时开始引导。引导类包含所有将 BC xx、启动和运行的逻辑。 现在看看清单 2 中的
清单 3 显示另一个
如果将 与 对比，将会看到两个主要区别：
您已看到如何使用 JBI 的 JBI 实现如 ServiceMix 提供预置的 BC，它与实现捆绑在一起。您甚至不需要为这样的 BC 配置 第 2 部分将各部分组合起来，演示如何使用 ServiceMix 现有功能以及构建和配置新功能 — 即，实现和配置 BC 或 SE — 来集成医疗保健服务。 学习
讨论
原文链接: |
