e医疗 e医疗

信息技术
推动医疗改革与创新
广告

开发者社区精选 | 漫谈应用集成的现在与未来(下):集成方案与评价,以及应用集成的发展

作者:InterSystems 供稿

InterSystems开发者社区汇集了大量有用、有趣的实践探讨。我们今天推荐的是InterSystems中国技术总监乔鹏的一篇长文:漫谈应用集成的现在与未来。


全文很长,分为五部分,目前已在开发者社区发布。包括:

1. 什么是应用集成?

2. 如何做应用集成?

3. 什么是集成平台?

4. 集成方案与评价

5. 应用集成的发展


为便于阅读,我们将长文分为上、中、下三篇进行推送:


04

集成方案与评价

应用集成项目的效果和实施有很大关系,且和底层采用的集成平台技术相关。评价它的因素太多了,例如性能(消息吞吐量)、高可用、持续集成能力、建设成本......


而我们这里关注集成三要素和集成平台基础能力,这些集成的核心需求来考察集成方案。

图片图:集成三要素与集成平台基础能力

即无论什么样的方案,都需要留意是否关注在集成3要素上,是否解决了3个核心问题。为分析市场上常见的集成方案,我们把不基于集成平台的常见集成方案也纳入进来。

4.1 基于点对点接口

不依赖于集成平台。应用需要大量的接口改造工作,复杂度随被集成应用的数量呈指数增长。因为通过各自应用的改造,事件和完整的跨业务边界流程被割裂在各个应用中,没有地方可以一览应用间的流程,可以说缺少流程和上下文梳理。虽然它目前仍是应用集成的主流方式,但其固有缺点使其很难持续部署在日益复杂的多应用业务场景下。

    图片

4.2 基于中间表的数据交换

使用中间表的方案是上面点对点接口的一种特例,其思路是通过SQL这一种接口单向打通应用:将需要传递的信息放在中间表里,数据用户在业务流程节点上去中间表获取信息。这种方式的流程自动化程度通常较低,适合的业务场景也比较有限。例如医生站下达了检验医嘱,医嘱并不会推送给检验系统;患者拿着检验申请单到检验科,检验系统通过扫申请单二维码获取申请单编号,并在这时去医生站开放到检验医嘱中间表获取完整的医嘱信息。“事件”、“流程”是在患者人工参与下完成的:人工传递医嘱,将前段业务流程(医生下达检验医嘱)和后段业务流程(检验科处理医嘱流程)关联起来;“患者到达检验科窗口”是后段流程(检验科处理医嘱流程)触发事件。

4.3 基于消息交换

基于消息交换”是主流的集成方案,通常是利用消息路由作为“流程”的承载机制,通过消息路由规则解决集成三要素中的“流程”问题。而消息本身就要承载另外二个要素:事件和上下文了。因此对于消息标准的选择是影响方案的关键因素之一。

这类方案要关注:

  • 是否解决了应用连接问题。如果仅是一个消息引擎,而要求被集成的业务系统都需要被改造以连接到消息引擎去发送消息、轮询消息引擎获得自己需要接收的消息,那么这个方案的成本就非常高了!

  • 是否有平台统一的消息标准。每个业务系统对相同的业务对象 - 例如患者 - 要求不同的数据,如果在平台上没有做标准化,会在平台上传递太多的消息类型,而且都是残缺的信息,这些消息的管理成本太高、而消息的数据价值很低。作为上下文载体的消息,其对业务的抽象能力非常重要。

4.3.1 基于行业互操作消息标准

行业互操作消息标准对业务事件和上下文都有梳理。例如,在对事件的梳理和实现上:

HL7 V2的消息名称代表了业务场景和业务事件。例如ADT_A01消息,ADT代表患者管理业务:入院(Admission)、出院(Discharge)、转院(Transfer),A01是患者入院事件。

HL7 V3也类似,但其结构层层封装,远比HL7 V2复杂。例如PRPA_IN101001UV01, PRPA是业务场景(PR:Practice)的患者管理域(PA:Patient Administration),IN是交互(interaction)规范。而其内部定义了这个交互对应的事件:

图片

而消息路由规则承载了“流程”:

图片

目前在医疗互操作标准中,HL7组织发行的标准采纳范围最广、影响范围最大。HL7的历史很长、标准众多,如果我们要参考或采用其标准,必须要了解它发行的这些标准的用途和差异。国内市场上,所谓基于HL7 V3消息的方案不少,但大多数对HL7 V3标准的遵循质量并不高。

图片图:HL7组织不同标准的采纳度随时间的变化及趋势,枣红色柱状代表当前时间。

需要注意的是,行业的互操作标准对于应用集成来说非常重要,但其标准往往来自于对既往业务的总结。实际中总有超出现有标准覆盖的业务,因此基于标准消息的方案也要考虑可扩展性。 例如 HL7 V2具有非常简单和灵活的可扩展性,通常通过自定义的Z字段扩展;而HL7 V3由于其RIM方法论,相当难于扩展。这也是图中大家看到的HL7 V3全球采纳度远不及V2的原因之一。

对于标准通过扩展也不能满足的业务,就依靠底层的建模与转换能力和方案的丰满程度了。

4.3.2 自定义消息

当需求变化时,消息结构自主可控,这是用户自定义消息的核心优势。自定义消息很考验经验 - 需要对业务对象和流程抽象。如果不能覆盖主要的用例,意味着消息结构可能需要经常变更,从而影响方案和接口的稳定性。

这个方案有一个比较流行的分支:

对消息体不建模、路由时不做拆包处理 - 任何的消息体内容都可以传,从而避免因为需求变化而更新消息模型(schema)的工作。它不做消息校验和基于消息内容的路由,仅根据消息类型、甚至定死的路由目标设置进行路由。方案最大好处是平台建设方“无事一身轻”:平台仅提供基于消息类型的路由机制;而各个应用需要改造以发送、接收、校验和处理消息,工作量较大。

4.4 基于文档交换

文档通常是小结性的信息,发生在业务阶段性节点上,例如“出院小结”发生在出院时,它不是细颗粒度“事件”。所以文档交换并不是主流的集成方案,通常作为基于消息或服务的方案的补充。文档结构是对“上下文”的定义,通常采用的有互联互通文档、HL7 CDA文档或用户自定义文档。基于文档交换的“流程”特别简单,通常是:注册、查询、获取。而应用需要具有使用文档流程服务的能力。

4.5 基于服务总线(ESB)

将应用的功能在ESB上封装为服务,并通过ESB来协同这些服务,就是基于服务总线的集成方案,它也是主流的集成方案。服务本身封装了事件、上下文。ESB协调这些服务调用的流程,通常是通过业务流程建模能力实现的,它提供比消息路由规则更直观、更灵活、更丰富的流程建模和管理能力,甚至可以被业务专家直接使用。

图片

需要注意的是,有服务不等于用服务总线。例如一些方案中,集成厂商扔出一份“服务”文档,要求各个应用厂商建设“服务接口”,但后台并没有ESB,不做服务注册、数据转换等,这其实是一种点对点方案。还有一些解决方案仅有注册、发布固定服务的能力,例如自定义的SOAP服务。并不能注册别的服务-例如TCP或HTTP的服务,或新的服务。这样的方案连接能力不足。

4.5.1 基于行业互操作服务标准

医疗行业,IHE、互联互通成熟度标准,都抽象和定义了服务标准,例如下面IHE常见的几个服务的场景、角色和事件(事务):

图片

可能大家注意到了,上面没提3要素之一的上下文。通常这些服务标准也规范了服务的请求和响应模型,例如IHE使用HL7 V3消息或FHIR消息;而互联互通服务使用互联互通消息标准。

基于服务总线的集成方案,通常需要具有持续的服务注册与发布的能力。这也是评价方案的因素之一。

4.5.2 用户自定义服务

由厂商基于经验或项目需求定义服务,并使用ESB注册、发布服务。对服务的规范能力和设计弹性是这类方案的关键。

另外,方案是否提供良好的连接能力,也是自定义服务方案的评价因素。

4.6 基于事件驱动(发布/订阅)

绕了这么久,终于提到了开篇所说的FHIR订阅范式。

事件驱动(EDA)是SOA的继承者,其核心特征是通过事件生成能力和事件(及表达事件的上下文)的发布/订阅,打破紧耦合的服务调用,以松耦合架构实现更灵活的服务调用流程。通过对事件的灵活定义和发布/订阅机制,EDA应对业务变更只需要增加、调整订阅关系,而无需修改固定的业务流程模型或消息路由规则。

基于事件驱动的集成方案现在越来越广泛地被采用,为用户提供了可持续集成的灵活架构,对集成厂商而言也降低了业务变化时的开发实施成本!

事件生成能力和灵活性、发布/订阅便捷性是评价方案的关键。另外,事件驱动是以SOA为基础的,它仍要基于ESB封装服务和协同前道业务流程,而且对服务标准化程度和调用方式也提出了要求 - 例如应该尽可能使用异步服务调用方式,而不是同步调用。

图片

FHIR订阅基于W3的WebSub,提供FHIR的订阅资源Subscription 和订阅主题资源 SubscriptionTopic,本身就是一个API时代的事件驱动实现。

05

应用集成的发展

应用集成随应用的软件开发架构的进化而进化。FHIR 的6个互操作范式涵盖了上面提到的消息、服务、文档,另外三个—— API、订阅和资源仓库正体现了近年软件架构上的发展。

5.1 基于API的应用集成

上面提到的应用集成方案基本都是中心化的,应对主流的单体架构应用。而软件开发架构发展的一个趋势是去中心化,例如微服务架构。

微服务架构是站在SOA肩膀之上的软件架构,去中心理念、开发的敏捷性、部署的弹性、快速迭代能力让其近年几乎和各行各业的数字化转型画上了等号。微服务架构通过按主题域驱动设计(Domain-Driven Design) ,将业务进行细颗粒度的划分,使用API打破了应用边界。

既然微服务架构下,应用边界都被突破了,基于应用边界的应用集成显然对微服务架构应用不再必要了,转而需要对这些微服务进行集成。这涉及到微服务的发现与注册、微服务的编排、微服务路由、微服务流控、微服务安全、微服务监控等诸多领域,架构复杂度相当高。

市面的API网关一定程度上可以应对“API”集成,通常有API发布、API协同调用、数据转换、API转换等能力,让其能涵盖API的调用”流程“,而对目前API的主要载体RESTful API的连接能力当然不在话下。同时,API网关也不必中心化部署,适合微服务软件架构向外暴露服务。

在医疗行业,FHIR提供了一套支持资源CRUD的API,并且提供了用户自定义API的扩展能力。虽然FHIR API不等于微服务,但它赋予了基于FHIR的应用间使用API进行互操作(集成)的能力,再借助其行业语义级的资源模型和事件定义能力,让FHIR API成为行业中一种可行的互操作范式。 

需要注意的是,API网关不是集成平台,API集成严格上也不能叫做应用集成。只有在微服务架构的应用间,它才能充分发挥作用。而在多种架构应用并存的今天,仅靠API网关显然解决不了应用集成的需求。在微服务架构应用全面、大规模部署前,应用集成仍需要集成平台的支撑、API网关来补充。相信微服务架构未来会越来越重要,但并不会一统天下。

5.2 基于FHIR资源仓库的应用集成

微服务架构中,服务可以非常弹性的部署、快速的迭代,但数据并不容易 - 高效地同步或复制数据是个难题。能否在微服务架构上,让数据保持逻辑上的集中存储以解决这个难题?

FHIR的第5个互操作范式 - 资源仓库,基于这个思路,为基于FHIR API的应用集成带来了一个有趣的分支。FHIR的资源仓库为这种方案提供一个统一行业语义的、逻辑的数据中心,而且其中的数据是可以读写操作的。之所以说是逻辑数据中心,是因为不同FHIR资源可以存在多个FHIR仓库中,互相之间通过资源引用 - 例如URL - 关联在一起,而不必把所有资源数据物理上保存在一起。

FHIR资源模型提供上下文语义和事件定义,FHIR服务器提供统一的语义层和连接层,API网关以及FHIR生态中的CDS hooks、订阅等提供流程层面的支持。而“生长”在FHIR资源仓库上的应用,天生就是互联互通的!

图片

这个方案不知道有谁已经真的实施了,但的确开拓了具备行业天生互联互通能力的应用开发架构的新思路。

当我们讨论未来的时候,其实未来已来。数据编织、数字孪生、组装式应用、超级自动化......已经出现在我们身边,也深刻影响着应用架构和应用集成。对应用集成的发展,让我们拭目以待!

赞(0)
未经允许不得转载:e医疗 » 开发者社区精选 | 漫谈应用集成的现在与未来(下):集成方案与评价,以及应用集成的发展
分享到:
广告