团体标准《电子信息系统数据互操作指南》征求意见
团体标准《电子信息系统数据互操作指南》征求意见
我院申请的团体标准《电子信息系统数据互操作指南》现在我院官网广泛征求意见,请相关专家在2023年5月13日前将修改建议反馈至 周曼 15810054229 处。
电子信息系统数据互操作指南
1 范围
本标准规定了数据互操作的总体要求、互操作实现方法及互操作管理要求。
本标准适用于电子信息系统相关数据进行互操作。
2 引用文件
下列文件中的有关条款通过引用而成为本标准的条款。所有文件均应注明日期或版本,其后的任何修改单(不包括勘误的内容)或修订版本都不适用于本标准。
GB/T 18391.1-2009 信息技术 元数据注册系统(MDR) 第1部分:框架
3 术语和定义、缩略语
3.1 术语和定义
下列术语和定义适用于本标准:
3.1.1 互操作性 interoperability
两个或多个系统或组件交换信息和使用已交换信息的能力。互操作性包括两个方面的能力:交换信息的能力;使用所交换信息的能力。
3.1.2 数据提供方 data provider
提供数据资源交换内容的机构和软件系统。
3.1.3 数据使用方 data user
使用数据资源交换内容的机构和软件系统。
3.1.4 管理者 manager
管理数据资源节点的机构。
3.2 缩略语
LCIM——概念互操作等级模型(Levels of Conceptual Interoperability Model)
PSM——平台相关模型(Platform Specific Model)
XML——可扩展标记语言
OMT——标准化记录格式
HTTP——超文本传输协议(Hyper Text Transfer Protocol)
URL——统一资源定位器(Uniform Resource Locator)
SOAP——简单对象访问协议(Simple Object Access Protocol)
4 总体要求
4.1 概述
相关系统之间存在系统异构(不同的编程语言编写)、数据库数据异构(不同数据库模型)等异构的问题。为达到相关数据进行互操作的目的,在新业务系统开发的整个生命周期应统筹系统分析与设计、规范系统的开发,降低系统间异构性,着眼于提高数据和服务的可见性、可访问性、可理解性,应遵循技术互操作性框架。
4.2 互操作性
一般系统间互操作性划分为递进的等级。
各互操作性层次并不是孤立的,高层次互操作性是以低层互操作性的实现为基础的:
- 技术互操作:为其它层的互操作提供了物理连接基础;
- 语法互操作:要求系统间按照公共的数据结构交换格式化的数据;
- 语义互操作:系统通过公共参考模型能够解析数据的含义。
4.3 语义互操作
实现语义互操作性的主要技术手段,包括元数据、本体论、模型驱动框架三种,宜选用元数据投递映射的方案来实现数据和服务的可见性、可访问、可理解。
5 互操作实现方法
5.1 技术互操作性框架
信息系统设计应遵循技术互操作性框架。技术互操作性框架主要解决技术层面上的互操作性问题,主要实现参与互操作系统的数据与服务的可见性和可访问性,主要流程如下:
- 通过数据和服务的元数据注册,建立共享空间,打破系统原有的边界;
- 通过一个智能接口理解交互信息,根据智能接口对交互信息的推理结果,决定系统是访问共享服务库还是共享数据库;
- 系统根据相应的元数据信息(含有服务和数据的关键属性)得知调用什么服务或者提取什么数据以及如何调用服务或提取数据,如下图1所示。
图1技术互操作性框架
5.2 服务注册
参与互操作的系统应将它所能提供的服务在服务共享空间中的软件应用处注册,注册内容是服务关键属性的元数据。通过服务注册,就可以创建参与互操作的系统所能提供服务的关键描述信息的目录;同时,系统将服务的具体实现方式也投递到共享空间中的服务库。系统想要调用某一服务时,只需在服务元数据目录出查询就可以得到服务的来源,如何调用等信息。服务注册如图2所示:
图2 服务注册示意图
通过创建共享服务空间,彻底打破系统的边界。任何一个系统都可以根据需要使用服务共享空间中的服务。
5.2.0.1 服务设计原则
- 接口协议统一原则
所有服务的接口均基于HTTP协议。服务提供方和服务使用方必须同时使用同一种类型的技术来进行开发和调用,调用的服务通过HTTP URL中特点属性进行标识。
- 数据格式统一原则
服务的接口规范涉及范围包含以服务方式接入数据共享交换系统的数据,数据采用XML格式表示,并且符合相应的Schema,服务提供方和服务使用方必须同时使用同一种格式进行数据交互。具体参考附录A。
- 服务定义唯一性原则
一个服务应该只实现一个业务功能,业务功能的区别通过服务编码来区分,不应通过定义不同的业务数据在同一服务编码下实现不同的业务功能。
- 报文内容处理原则
服务请求和返回的报文应符合XML格式。服务请求方和提供方应采用的XML解析器来构造和解析数据,XML不同含义的段落应定义明确含义的字段名称,相同内容的数据应采用数组来进行描述,双方可根据XML路径进行精确定位,不应根据字段顺序来获取字段值,字段值不受字段顺序调整的影响。报文统一采用UTF-8进行编码。
- 规则校验原则
服务提供方应对请求报文格式和关键信息进行合规性和业务校验,防止非法访问和入侵。
- 数据量原则
数据共享交换系统所传递的单条大小原则上不大于1M,否则应建议采用文件传输、直连交换等方式。
- 数据实时性原则
服务交换原则上要求:数据提供频率是实时的,对于不能实时提供的数据,需在数据共享交换系统总注明原因和实际的更新频率。
- 持久化原则
服务使用方在使用服务的过程中,由数据共享交换系统进行整个过程的日志记录,并对调用的详细信息进行持久化,便于对账和稽核。建议服务调用方和提供方对调用的关键信息进行持久化。
5.2.0.2 服务注册
服务共享空间提供多种标准协议的服务接入,包括HTTP、WebService服务。
- 标准协议
HTTP接入允许通过HTTP协议接收有效请求负载,并通过请求获取到请求参数进行业务处理,转发到服务接入地址,并将返回的数据进行规范化输出,发送给服务使用方。
- 服务注册
- HTTP服务
- GET方式传递参数的服务
- POST方式传递参数的服务
- FORM表单提交
- WebService服务
WebService服务主要利用HTPP和SOAP协议是在数据在Web上传输,SOAP通过HTTP调用对象执行远程功能调用,Web用户能够使用SOAP和HTTP通过Web调用的方法来调用远程对象。
5.2.0.3 安全控制
- 身份鉴权
对外提供统一的身份认证策略,访问服务时,必须首先经过鉴权,鉴权通过后才允许访问。
- 访问控制
只能调用授权范围内的服务,每次服务调用,都要验证身份。
- 传输加密
为保障数据安全,涉及保密信息的服务要求必须进行加密处理。
5.3 数据管理
为提高数据的可见性和可访问性,应建立一个共享空间,用户和应用将自身的数据贴上“元数据”的标签以便数据容易被发现,同时将数据投递到“共享空间”以供用户使用。通过用户与应用的元数据注册,创建元数据目录,维护共享数据库,促进用户的数据投递。只要需要,用户和系统应用都可以检索并“提取”自己感兴趣的数据。结构如图3:
图3 数据管理示意图
元数据目录包含了存储在相应共享空间的所有数据资产的信息,主要结构为:
- “结构化”元数据描述了数据的组成,数据中用到了哪些元素或域;
- “发现”元数据描述了数据的关键属性和概念,便于用户和系统应用快速搜索范围广泛的数据。确定满足他们需要的数据
5.3.0.1 提供数据
- 数据初始导入
业务系统向数据共享空间添加交换数据时,操作如下:
- 注册业务数据目录,配置数据存储信息;
- 准备数据,并将业务数据写入至数据共享空间。
- 数据更新
- 业务数据更新,需要根据数据唯一表示,更新相应数据字段;
- 将更新时间字段设为当前时间。
- 废弃数据
当已添加到数据共享空间的业务数据被确认为无效记录时,应执废置交换数据操作来进行逻辑删除。
- 根据业务唯一标识定位确认为无效的数据记录;
- 将业务数据状态标识字段更新为废弃;
- 将更新时间字段设为当前时间。
5.3.0.2 获取数据
数据使用方根据业务需求,根据业务主题,在数据共享空间查询并申请数据,申请成功后,即可通过数据交换功能,获取更新数据。操作如下:
- 根据业务需要,在 “发现”元数据注册目录查找业务主题数据;
- 根据业务需要,申请数据;
- 申请通过后,将数据从数据共享空间提取返回请求用户,同时返回“结构化”元数据相关的信息。
5.3.0.3 “结构化”元数据注册
数据投递时,将数据的组成,数据中用到的元素或域封装为“结构化”元数据,将“结构化”元数据作为目录注册到数据共享空间;
注册方式 见5.2.1.2;
5.3.0.4 “发现”元数据注册
数据投递时,将数据的关键属性和概念封装为“发现”元数据,将“发现”元数据注册作为目录注册到数据共享空间;
注册方式 见5.2.1.2;
5.3.0.5 安全控制
具体见5.2.1.3
5.4 智能接口
将系统所在领域中共同认可的词汇以及这些词汇和词汇之间相互关系的明确定义,以及词汇之间关系所满足的公理共同构成一个知识库;同时建立不同领域知识库之间的映射规则,这些映射规则是辅助推理的,如果再加上推理引擎和用户接口,就可以构成一个智能推理系统。当系统发出请求时,由该推理系统对交互信息进行相应演算,推断出系统是请求数据还是请求服务,以及数据请求的服务方,然后再到相应的共享服务库以及共享数据库,调用相应服务或提取相应数据。智能接口示意图如图4所示。
图4 智能接口
5.4.0.1 知识库的整理
- 整理符合相关的词汇,记录知识库;
- 整理相关词汇的关系,记录知识库;
- 建立梳理不同领域与知识库之间的映射规则,辅助推理。
5.4.0.2 接口要求
5.4.0.2.1 接口设计原则
接口设计原则主要包括:
- 安全性原则:应提供多种安全可靠的技术手段,保证服务接口的安全;
- 开放性原则:应采用通用的接口设计标准,保证与其他系统的互联互通;
- 灵活性原则:应能根据业务变化,灵活调整接口性能;
- 松耦合原则:应避免服务提供方的业务系统对服务接口实现的依赖。
5.4.0.2.2 接口技术要求
接口技术要求包括但不限于:
- 接口方式:一般包括WebService和REST两种方式,WebService服务描述的内容格式应符WSDL 1.1,服务消息封装应符合SOAP 1.1/1.2标准,REST服务消息封装应符合HTTP 1.0/1.1标准,若为REST方式,应标明REST操作;
- 接口输入参数:
- REST类型的服务接口,应允许在Header里输入授权验证相关参数;
- WebService类型的服务接口,不应在header中传递参数,应在body中传递参数;
- 传递参数为中文字符时,应采用UTF-8编码。
- 接口返回数据:
- 返回数据应采用固定格式封装,如XML、JSON等;
- 服务接口调用失败,应通过返回码响应。
6 互操作管理要求
6.1 组织结构保障
互操作的障碍是缺乏对这一问题负责的集中或协调机构,应建立一个机构统一来协调,负责系统建设的总体规划,通过组织层面的协调,为技术层面互操作性解决扫清障碍,降低技术层面上保证互操作的难度。
具体要求如下:
- 决定要做什么以及怎样来构造,打破“烟囱”式系统,在系统开发源头进行规范、统筹兼顾,避免系统的重复开发,降低系统间的异构性;
- 加强用户、领域专家、系统开发人员间的沟通,确认互操作性需求,减少模糊不清的术语名词,消除组织间使用术语带来的麻烦;
- 建立模型管理与注册机制,对经过实践检验的、有效的模型进行注册,建立模型库,防止模型开发的无序性,降低模型的异构性。
6.2 管理角色的职责
6.2.1 数据提供方
数据提供方的职责包括:
a) 负责业务数据目录的梳理;
b) 配合管理方与资源提供方协商确定信息共享的具体内容、条件、方式、频率;
c) 对数据交换内容设置相应的使用授权;
d) 在管理方的指导下完成资源优化等其它相关工作。
6.2.2 数据使用方
数据使用方的职责包括:
a) 负责按要求提交资源需求方案;
b) 对于交换获得的信息内容在授权范围内进行使用,保障数据资源按要求合理合规使用;
c) 配合管理方与资源提供方协商确定信息共享的具体内容、条件、方式、频率。
6.2.3 管理方
管理方的职责包括:
a) 负责交换智能接口、服务共享空间、数据空间空间系统的管理维护;
b) 负责对信息交换流程进行规划、配置及部署;
c) 负责对信息交换流程实施日常管理及监控维护;
d) 负责保证信息交换系统的安全,确保交换数据信息在授权的范围内交换共享;
e) 制定相关规范和标准;
f) 组织并指导数据资源供需双方协商,根据协商结果制定信息交换流程,并进行配置、部署;
g) 对数据资源交换的准确性、稳定性等指标进行实时监测,及时传达上级要求,并对多有关情况进行定期通报。
附 录 A
(资料性附录)
数据接口规范XML Schema
<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns="" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata" id="DataSchema">
<xs:element name="DataSchema" msdata:IsDataSet="true" msdata:Locale="en-US">
<xs:complexType>
<xs:sequence>
<xs:element name="DataInformation">
<xs:complexType>
<xs:sequence>
<xs:element name="DisplayName" type="xs:string" minOccurs="1"/>
<xs:element name="From" type="xs:string" minOccurs="1"/>
<xs:element name="IPAddress" type="xs:string" minOccurs="0"/>
<xs:element name="DateTime" type="xs:string" minOccurs="0"/>
<xs:element name="RecordNumber" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="DataSet">
<xs:complexType>
<xs:sequence>
<xs:element name="RecordData" minOccurs="1" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="OptionType" type="xs:string" minOccurs="0"/>
<xs:element name="UnitData" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="IDName" type="xs:string" minOccurs="1"/>
<xs:element name="DisplayName" type="xs:string" minOccurs="1"/>
<xs:element name="Value" type="xs:string" minOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
_________________________