系统架构设计师:信息系统架构设计理论与实践--Web服务在H L 7上的应用-Web服务基础实现框架

今天，由于商业与法律的需要，例如美国的健康保险便利和义务法案（Health Insurance Portability and Accountability Act，HIPAA）-卫生保健组织机构很清楚要与它们的商业结合起来。遗憾的是，大多数的健康信息系统一直是私有，而且在一个卫生保健行业它们只为一个部门服务。Health Level Seven（HL7）是美国国家标准化协会（ANSI）认可的标准化开发组织中的个，它正在全世界保健行业里运行着（Level Seven引用了开放系统互连模型OSI的最高层一-应用层）。传统上，它从事临床建模与数据的管理工作，最近的一个版本一-HL73.0版本扩展到了各种卫生保健行业，如制药业、医疗设备及成像设备。

HL7标准也指定了一些适当的信息基层组织，如Web Services，它就适合传送HL7信息。并且在应用软件之间对于如何确保这个信息的传送的交五性，提供了一个说明性的向导。将HL7应用软件应用在Web Services上，意味着首先设计一个正确的体系结构，其次是提供一个可执行且满足Web Services的环境。本文只是涉及HL7 Web Services Basic profile（HL7WSP）。

1.HL7模型概念

通过对HL7标准规格说明书以及本文以外的一些工具的描述，这部分将介绍一些主要的HL7模型概念和人工制品，这些都与我们的讨论相关。

1）参考信息模型

对于一个给定的卫生保健领域，HL73.0版本说明书是基于参考信息模型的（RIM）。这是种公共的模型框架，包括病例模型、信息模型、交五模型、消息模型和实现信息说明书。HL7的参考信息模型是一个静态的卫生保健信息模型，它代表了至今为止负责HL7标准发展行为的卫生保健领域的各个方面。HL73.0版本标准开发过程定义了一些规则，这些规则用于从参考信息模型中获取一些具体领域信息模型，从而在HL7规格说明书中使这些模型更精确，最后产生XML表单定义（XSD）与一个具体的消息类型联合起来。

2）消息结构

HL7应用软件之间的交互行为是通过消息的交换来完成的。这样，在提供envelopes支持应用程序之间的消息交换期间，这个标准就提供了一个真实的功能水准。HL7消息的封装被称为wrappers，最初是通过RIM中类的定义和关联模型化的。然后，这些说明书被用来为消息wrappers创建XML表单。接下来，在HL 7消息开发框架中所列的过程在图12-11中有所描述。

所有的HL7消息都被放在Transmission Wrapper，Wrapper的目的是支持应用软件之间消息的传输（和确认）。Wrapper的重要部分是一些元素，如消息标志符、消息的创建时间、交互标志符、发送者和接收者标志符、确认编码和消息序列号（可选）。认为HL7消息是在合理的HL7应用软件之间进行交换这一点是很重要的。也就是说，特殊的软件应用或是组成成分（像“顺序实体”）都代表着有组织的或是可管理的实体。所以，在传输层，发送者和接收者概念不会被看成是一个规格说明书的一部分。

3）交互

一次HL7交互就是信息特殊转移过程中的一次联合，一个触发事件就开始了消息的转移，应用软件进行接收和发送消息。在HL7里，一个触发事件是引起信息在应用软件之间进行转移的一系列精确条件，它也代表着一个真实的事件。例如，实验室顺序的安排或是一个病人的登记。

4）应用程序角色

HL7里的每一个应用属于一个具体的应用程序角色。根据一个应用程序提供给其他应用程序的服务或是一个应用程序为了获得特定的服务而发送给其他应用程序的消息，这样一个角色就体现了应用程序的职责。

5）Storyboard像消息类型、交互作用和应用程序角色这些概念都集合在了一个HL7 Storyboard里，它是用来指定在HL7标准化行为范围内与任意卫生保健领域相关联的用例。一个Storyboard是由一小段记叙了它本身的目的及交互作用图表的描述所组成的（在应用层）应用程序角色间相互作用的级数。交互作用的图表指明了相应交互作用的职责（就是应用程序角色）、交换信息的类型以及期望的信息交换的顺序。

2.体系结构

基于刚刚介绍的HL7概念模型，现在我们能更精确地定义出HL7应用。这些都是在支持应用程序角色软件组成中的设计与实现，这些角色是作为交互行为中的一部分来实现发送者/接收者的职责，通过使用Web服务通信基层结构来满足HL7Web服务的（如图12-12所示）。

在图12-12所示的结构里，能够抽象出HL7发送者/接收者内部的这两组功能：商业逻辑和Web服务适配器（需要强调的是，这里商业逻辑的范围是在HL7应用进行它们的发送者的角色和/或信息的接收者内部。也就是说，它支持一种具体的通信模式。应用层商业逻辑、消息的产生，或是为了响应需求而提供的具体服务这些都是在范围之外的）。

至于HL7消息的扩展，我们需要关注一下。商业逻辑的任务如下。

（1）发送端：创建一种具体HL7消息类型的XML描述，消息类型包含消息体、Transmission and Control Wrappers。将消息传送到Web服务适配器，适配器负责传送到接收应用端。

（2）接收端：“找回”由Web服务适配器接收的HL7消息，同时从接收到的XM L消息那里打开TransmissionWrapper、Control Wrapper 和消息体；验证HL7消息是否满足用来交五的商业规则和约束；核实发送应用端是否需要一个应用层的确认信息（HL7消息类型MCI）-一如果是那样的话，发送那个消息。

Web服务适配器的功能主要是用来处理消息的分发和确认信息。因此，主要包括如下内容。

1）发送端

（1）读取接收到的HL7消息的Transmission Wrapper，以便决定如何到达Web服务基层结构上的发送容器（例如接收应用软件），从而配置SOAP。

（2）基于HL7消息类型、应用配置和规则（如安全性）来准备一个SOAP消息，包括作为个S0AP消息体部分的HL7 XML消息，这个消息被发送到Web服务基层组织。

（3）把SO A P消息传递到Web服务代理，通过网络进行传输。

（4）无论发送端什么时候请求，都准备接收并存储来自接收端的相应信息或是应用层的确认消息。

2）接收端

（1）从Web服务站处接收SOAP消息。

（2）验证接收到的SOAP消息满足应用配置和一些约束条件（如安全性）。

（3）或者将这些接收到的消息在内存中以永久的形式保留。

（4）有选择性地从SOA P消息里打开HL7XML消息，同时核对接收到的HL7消息是否与期望的HL7消息类型相符合。

（5）验证是否任意通信层的确认信息都需要被执行，在哪种情况下需要返回一个合适的消息发送到源消息发送端。

（6）传递HL7消息给接收应用端。

在适配器层，这些情况都能够当作多个单行道方式或是请求/就答消息扩展模式来实现。在一个真正的实施过程中，适配器的结构也需要处理综合性应用和互操作能力。例如，如果一个应用业务逻辑不能直接与一个Web服务环境进行交五或是它被搭建在一个与以前实现时不同的平台上。

3.开发HL7 Web服务适配器

原则上，尤其是当范围被限制在只是支持HL7 Web服务时，开发HL7 Web服务就与开发普通的Web服务相类似了。事实上，RIM的标准化模型的有效性，消息类型的说明书，通信模式及Web服务都在一定程序上影响着开发过程。为了高效地开发HL7 Web服务适配器，需要按如下步骤来做。

（1）消息和数据类型的设计。在一个像HL7这样面向消息的环境里开发一个Web服务，必须首先设计可交换的消息、已用的数据类型以及XSD表单里它们的说明书。这项活动完全受益于HL7（使XS D表单自动化产生）所构造的消息和数据类型工具。

（2）适配器模式的选择。创建Web服务适配器的下一步是选择哪一个适配器结构模式能够最好地适合HL7通信模式，这个通信模式是由步骤（1）中所获得的消息类型来指定的。这一步要定义，比如说，一个（仅仅一个）代理/Stub组成成分是必要的。

（3）HL7Web服务契约开发。从一个普通的角度考虑，在创建一个面向消息的Web服务的下一步就能够定义它的契约了，用一种标准化的可用计算机处理的语言称作Web服务描述语言，或者在支持Web服务标准的编程语言里实现它的开发。

（4）产生Web服务Stub 和代理的实现。一旦WS DL契约完成，它就可能创建使用一些工具的Web服务Stub和代理服务器，这些工具是由像WSDL.exe这样的开发平台所提供的。

（5）开发适配器业务逻辑。这一步是建立在前一步代码生成的基础上的，添加了必要的逻辑来支持适配器的功能。

一个普通的WSDL契约都详细说明了一个Web服务的名字和端口，通过这些端口，Web服务器可以和客户端应用程序进行通信。一个端口指定了网络中服务生效的位置。每个端口也指定了端口上的一些有用的操作（portTypes），和客户与服务器在那个端口上进行通信的协议间的

一个绑定。端口类型代表了暴露在Web服务上的各种接口。操作是接口的方法，它们定义了客户端请求服务端的输入信息，以及定义了服务器用于应答客户的输出信息。消息的格式也是基于WS DL契约中所定义的类型的格式（XML表单）。

4.案例研究

一个参考实现案例已经构建了，包括两个系统之间的交互：医疗信息系统（Hospital Information System，HIS）和实验室信息系统（Laboratory Information System，LIS）。

（1）HIS是由两个Sub-systems排序和报告组成的，为此应用程序和Web服务已经被开发。

（2）类似地，LIS是由Web服务和业务逻辑组成的，Web服务从HIS排序系统接收命令，业务逻辑是将确认信息返回到HIS排序或报告系统。

（3）这里，设想中用到的通信模式交换与前面所描述的“发送消息负载一附有确认信息一立即”是相符的。

（4）为了保持业务逻辑的简单实施，当允许一些用户与样品应用程序进行交互时，两个Windows客户应用程序必须被开发。

HIS客户应用程序发送命令请求给HIS Web服务器，并且显示发送命令的接收确认信息。它的用户界面允许用户发送一个命令（发送按钮），因为全球唯一的标识符（GUID）是由客户应用程序自动产生的。当HIS系统接收确认、信息确认和通信结果时，HIS客户用户界面也会通过LIS系统（用三个验证框：OrderAck、ActiveConf和 Result）显示出来。图12-13是用来交换HL7信息的流程，这些信息存在于提前设想的模板的上下文里。

（1）当用户接口从HIS客户机那里收到信号时，HIS业务逻辑就会产生一个序号标识符，同时通过创建一个XML文件以及在HL7负载里加入一个序号ID来构造P0LB_IN2120信息。

（2）业务逻辑发送一个POLB_IN2120信息（SendOrder）给适配器，通过它的代理服务

（P0LB_AR002942服务代理）来调用LIS服务。

（3）在Laboratory端POLB_AR002942Service Stub接收到S O A P信息，同时使它对于LIS Web服务适配器是可用的。

（4）LIS适配器从SO A P信息里得到HL 7信息（Order），同时依据HL7信息类型表单来验证从SO A P那得到的被封装的HL7负载。

（5）LIS适配器从SO A P信息里得到HL7信息（Order），同时依据HL7信息类型表单来验证从SO AP那得到的被封装的HL7负载。

（6）如果需要，它会准备确认序列，这个确认序列是通过构造一个XML文件同时在文件里附上一个预先定义的应答确认来实现的。

（7）当一个新的信息到达时，LIS业务逻辑重新从顺序队列里得到HL7信息，并且将信息发送给LIS客户端。

事实上，对于给定的应用程序角色和交互活动，可以构造一个能自动产生代码的工具，用这个工具来创建需求信息队列和存储引入的信息。这是一种用来构建Web服务适配器代码的方法。

5.结论

在卫生保健领域，HL7是用来为协同工作而创建的基层结构。HL7使用参考信息模型（RIM）来获得具体领域的信息模型，同时把它们精炼到HL7说明书中，结合具体的消息类型自动产生X ML表单定义（XSD）。因为能够被设计所公用，因此这些概念就对它们进行建模，而不是只集中在关于互操作能力的一些技术问题上。我们能够考虑说明书，同时知道如何构建一个应用程序软件，包括角色、协作模式和消息。

从理论到实践，HL7并没有告诉我们怎么构建和设计一些方案，而是当Web服务被用时，本文提到的参考体系结构就是一个相应的出发点。