食品药品监管应用支撑平台通用技术规范Word文档下载推荐.docx
《食品药品监管应用支撑平台通用技术规范Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《食品药品监管应用支撑平台通用技术规范Word文档下载推荐.docx（19页珍藏版）》请在冰点文库上搜索。
本标准依据GB/T1.1——2009给出的规则起草。
本标准由国家食品药品监督管理总局信息中心提出。
本标准由国家食品药品监督管理总局科技和标准司归口。
本标准起草单位：
国家食品药品监督管理总局信息中心、中科软科技股份有限公司、广东省食品药品监督管理局。
本标准主要起草人：
陈锋、张原、陆颖、刘靓、赵坤、张翔、李宗波、刘日听、史先东、李建魁。
1范围
本标准提出了食品药品监管信息化工程应用支撑平台应遵循的技术规范，对应用支撑平台总体架构、统一接入认证、统一用户管理、权限管理、行为审计、服务建设等提出了要求。
本标准适用于食品药品监管信息化工程的设计、开发、建设实施和管理维护。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。
凡是注日期的引用件，仅注日期的版本适用于本文件。
凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
GB/T11457-2006信息技术软件工程术语
GB/T29262-2012信息技术面向服务的体系结构（SOA）术语
CFDAB/T0102.1-2014食品药品监督管信息化基础术语第1部分信息技术
3术语、定义和缩略语
3.1术语和定义
CFDAB/T0102.1-2014界定的以及下列术语和定义适用于本文件。
3.1.1
面向服务的体系结构serviceorientedarchitecture
遵循面向服务原则、具有松耦合特性的体系结构风格。
[GB/T29262-2012，定义2.37]
3.1.2
服务总线servicebus
服务接入与消费的中介基础设施，为基本服务提供了基于标准的事件驱动消息路由。
其基本功能包括：
服务路由、消息转换、事件处理，提供服务调用，及相关中介服务，支持WebService或JMS连接，
连接各种应用，服务，信息，平台资源。
[GB/T29262-2012，定义2.10]
3.1.3
Web服务webservice
一种应用编程接口或Web应用编程接口，通过标准的规约进行定义、并通过标准迸行访问和使用。
[GB/T29262-2012，定义2.57]
3.1.4
接口interface
a）一个共享的边界。
信息跨越边界传送。
b）连接两个或多个其他部件，为了相互间传送信息的硬件或软件部件。
c）连接两个或多个部件，为了在相互间传送信息。
d）作为如b）中连接的或被连接的部件。
[GB/T11457-2006，定义2.795]
3.1.5
服务接口serviceinterface
用于实现使用者和提供者之间的通信合约，它提供了服务的功能、位置等执行通信时所需要的所有细节的描述。
[GB/T29262-2012,定义2.27]
3.2缩略语
ACL：
访问控制列表（AccessControlList）
CA：
数字证书认证中心（CertificateAuthority）
HTTP:
超文本传输协议（HyperTextTransferProtocol）
JMS:
Java消息服务（JavaMessageService）
LDAP:
轻量目录访问协议（LightweightDirectoryAccessProtocol）
RBAC:
基于角色的访问控制（Role-BasedAccessControl）
SOA:
面向服务的体系结构（Service-OrientedArchitecture）
WSDL:
Web服务的描述语言（WebServicesDescriptionLanguage）
4应用支撑平台总体架构
图1为食品药品监管信息化工程建设的应用支撑平台总体框架。
其中，应用支撑平台的基础环境支撑层和应用系统支撑层包括：
a）基础环境支撑层：
主要包括应用系统运行所需要的基础软硬件环境，包括服务器、网络和系统软件等，为应用系统提供基础的环境支撑；
b）应用系统支撑层：
为应用系统和业务门户提供工具支撑、功能支撑、服务支撑。
工具支撑由一系列的开发工具和统一接入认证功能组成；
功能支撑提供应用系统的基础功能，包括：
统一用户管理、权限管理、行为审计等；
服务支撑提供数据服务，并对提供的服务进行管理维护，对服务建设提出要求。
以下重点对应用支撑层的统一接入认证规范、统一用户管理、权限管理规范、行为审计规范、服务建设规范提出要求。
5.1概述
应用支撑平台的统一认证功能，实现对各应用系统的单点登录。
各应用系统应遵循统一接入认证规范的要求，使用单点登录实现应用系统的登录认证，并通过接口获取登录用户信息、使用统一用户管理
提供的用户和机构信息、使用权限管理维护应用系统登录权限。
如图2所示，用户发起服务请求后，首先由CA安全认证网关进行用户信息验证，如果用户信息验证通过，则访问具有权限的应用系统，如果验证不通过则拒绝用户的访问。
5.2单点登录规范
单点登录基于CA安全认证体系实现，应符合以下要求：
a）食品药品监管信息化工程建设基于CA安全认证体系，需要用户身份认证的应用系统应基于食品药品监管信息化工程CA安全认证体系进行用户身份认证。
b）对于已建成且使用自身CA安全认证体系的应用系统，可继续使用其CA安全认证体系，在需要时，与食品药品监管信息化工程建CA证书实现相互认证，CA证书的注销列表通过数据交换方式定期同步。
c）应用支撑平台应提供安全认证网关实现单点登录。
用户单点登录成功后，可使用统一的用户证书访问不同应用系统，无需多次登录。
d）单点登录的实现对应用系统建设有以下要求：
一一各应用系统的用户信息应与安全认证网关使用的LDAP用户信息同步，且用户关键标识一致。
一一各应用系统根据安全认证网关的认证接口获取用户信息。
6统一用户管理规范
应用支撑平台应对应用系统提供统一用户管理功能，各应用系统用户的管理和维护由应用支撑平台统一实现，包括组织机构管理、用户管理、系统账号管理等功能。
各应用系统在开发时，可以通过接口
调用和同步数据表的方式获取用户信息，各应用系统的用户信息和组织机构信息需要与应用支撑平台保持一致。
设计思路如图3所示：
用户和组织机构信息发生变化时，由应用支撑平台进行预处理，各应用系统与应用支撑平台进行用户表和组织表的同步。
7权限管理规范
7.1权限基本要求
应用支撑平台应提供统一权限管理功能，负责系统级别权限过滤，系统内部的功能级别权限过滤，由应用系统独立完成。
如图4所示：
7.2系统访问权限
应用支撑平台实现用户的系统访问权限，各应用系统开发时如需要判断用户是否具有指定系统的权限，可通过调用如下接口获取：
a）权限访问列表接口：
根据用户登录名称获取该用户所具有访问权限的应用列表。
b）权限验证接口：
根据用户登录名称和应用标识，验证该用户是否具有此应用的访问权限。
7.3功能访问权限
功能访问权限由各应用系统根据本系统的需求进行控制，建议包括以下权限控制：
a）功能权限控制：
基于ACL、RBAC等多种方式实现权限控制，权限控制粒度应到每一个功能点，基于角色可自由分配权限。
b）菜单权限控制：
基于角色、菜单实现用户菜单级的授权管理，实现菜单权限可自由分配。
c）数据权限控制：
根据业务需求，对数据进行分类，做到数据权限的控制。
8行为审计规范
8.1概述
应用支撑平台建设应包含行为审计功能。
行为审计包括应用系统日志记录、系统管理日志记录、用户行为日志记录，应用系统应按要求分别调用应用退出系统日志记录接口、系统管理日志记录接口、用
户行为日志记录接口，实现行为审计。
8.2应用系统日志记录接口
应用系统日志记录应用系统关键业务数据的操作信息，日志记录内容应包括：
a）客户端IP地址;
b）登录用户标识;
c）行为分类，如：
用户行为、系统行为等；
d）动作名称，如：
登山、退出等：
e）操作的应用系统名称；
f）操作结果，如：
成功、失败
g）操作安全级别，登录成功岁或退出安全级别为：
1：
登录失败安全级别为：
10；
h）备注。
8.3系统管理日志记录接口
系统管理日志记录管理员的操作，包括菜单注册、角色维护、角色授权、人员授权等操作，系统管理日志记录内容应包括：
a）客户端IP地址；
b）行为分类，如：
c）动作名称，如：
增加、删除、修改、启动、停止等操作；
d）操作的应用系统名称；
e）操作的对象；
f）操作结果，如：
g）操作安全级别，操作安全级别分为1-10级，操作行为对系统安全的影响越严重，安全级别越高，数字越大；
h）备注；
8.4用户行为日志记录接口
用户行为日志记录应用系统对数据的增加、删除、修改以及重要数据的查询。
用户行为日志记录内容应包括：
c）动作名称，如：
增加、删除、修改、启动、停止等等操作；
d）操作的应用系统名称；
e）操作的对象；
f）操作结果，如：
成功、失败；
g）操作安全级别，操作安全级别分为1-10级，操作行为对系统安全的影响越严重，安全级别越高，数字越大；
9WebService建设规范
9.1建设基本要求
Webservice建设宜基于服务总线进行，或按照以下Webservice设计规范、封装规范进行设计。
9.2设计规范
9.2.1概述
Webservice作为应用系司的交互方式，应按照统一的标准进行开发，Webservice的设计包括Webservice的识别与Webservice的定义。
9.2.2Webservice的识别
Webservice的识别应符合以下要求：
a）Webservice的识别是指对业务进行分析和梳理，抽象出业务实现所需的webservice，并按webservice的分类要求进行合理划分。
b）Webservice的识别应分析与业务功能或业务数据相关的接口以及约束该接口的契约，接口和契约采用中立、基于标准的方式进行定义，它独立于实现webservice的硬件平台、操作系统和编程语言。
c）Webservice的识别应从业务的角度出发，包括但不限于下述几点：
一一业务流程切入点：
通过梳理、优化业务流程，将业务流程转化为可重用、更具灵活性的流程服务。
一一用户体验切入点：
关注用户体验需求，为终端用户提供增值、个性化、多渠道的服务，并据此来优化整合内部的应用和流程。
9.2.3Webservice的定义
9.2.3.1定义描述
Webservice的定义是在webservice的识别的基础上定义webservice的各项属性，描述webservice的信息。
webservice的属性包括：
基本属性、技术属性、安全属性、配置属性。
webservice的各项属性定义应分阶段进行，并逐步细化。
webservice的识别阶段定义webservice的基本属性，设计阶段定义webservice的技术属性与安全属性，部署阶段定义webservice的配置属性
序号
属性
说明
取值说明
1
编码
标识webservice的唯一编码
可由英文字母、数字组成。
2
英文名称
可由英文单词组成
3
中文名称
可由中文、字母、数字组成
4
性质编码
如：
entlnfo
5
功能描述
6
开发单位
XXX公司
9.2.3.3基本属性
Webservice的基本属性包括但不限于表2所述信息：
技术属性
9.2.3.4安全属性
Webservice的安全属性包括但不限于表3所述信息：
表3安全属性
9.2.3.5配置属性
Webservice的配置属性包括但不限于表4所述信息：
表4配置属性
部署IP地址
提供webservice功能的网络IP地址
127.0.0.1
接口定义文件
描述webservice接口定义的文件路径
http:
//192.168.1.1/test.wsdll
可以使用的时间
可以使用该webservice的时间段
0：
00-0：
24：
00
是否支持重试
调用webservice失败后，是否支撑重发调用
是/否
9.3封装规范
9.3.1封装原则
Webservice封装应遵循以下原则：
a）webservice封装是webservice实现的手段，webservice封装将应用系统可重用的功能或数据“剥离”出来，对外以相关的接口方式以及约束这个接口的契约提供给消费者调用。
接口和契约的定义是中立的且基于标准的，并独立于实现webservice的硬件平台、操作系统与编程语言。
b）Webservice封装应遵循包括但不限于下述原则：
一一无状态原则：
最大限度减少webservice管理的状态信息以及状态期限。
一一单一实例膘则：
避免功能冗余。
一一接口定义原则：
使用WSDL定义webservice的接口，使用WS-Policy描述webservice的契约，使用XML模式（Schema）定义webservice交换的消息格式。
webservice的使用者依赖webservice的契约调用服务，webservice的定义应相对稳定，修改应通过审核批准。
一一自包含和模块化原则：
webservice封装的是那些在业务上稳定的、重复出现的活动和组件，组成的功能实体是完全独立自主的，可以独立进行部署、版本控制、自管理和恢复。
一一粗粒度原则：
确定webservice的粒度时需要考虑性能需求，以及未来可能进行的更改对webservice实现的影响，应尽可能使用粗粒度模式隐藏其中的细粒度webservice，这样有利于将webservice与其实现的更改隔离开来。
一一松耦合性原则：
webservice的接口和实现相独立，webservice的使用者可以通过组合一个或多个webservice来构建应用，无须理解服务的底层实现。
一一可重用原则：
webservice是可重复使用的。
一一策略声明原则：
应利用策略声明描述对webservice的期望，例如：
安全性方面的要求、与业务有关的语义方面的要求以及webservice级别方面的要求等。
9.3.2封装方式
Webservice的封装方式应符合以下要求：
a）对于技术实现方式和接口不能满足或难以满足本标准webservice的定义与封装要求的现有应用系统，建议通过适配器对现有应用系统进行集成，利用适配器对外提供的各类接口的方式实现webservice的封装。
b）对于采用J2EE支持webservice开发的现有应用系统，可以在不改变现有应用系统的技术实现方式与现有接口的前提下，通过增加对外接口以支持标准接口协议的方式，直接实现现有应用系统功能模块的封装。
c）对于新建的应用系统，应按本规范的webservice的奢砧封装的朴气直接办林持SOA的开
9.4开发规范
9.4.1命名规范
9.4.1.1命名要求
Webservice名称应遵循以下要求：
a）Webservice的方法名称为大小写混合的形式，以小写字母开头，名字中其他单词的首字母以大写字母开头，不宜使用下划线分隔单词。
Webservice的命名应该能描绘出方法的作用和功能，Webservice的名字宜使用动词或动词短语。
和功能，
webservice的名字宜使用动词或动词短语。
b）Webservice的方法参数命名应用一个小写字母开头，后面的单词应用大写字母开头。
c）所有webservice的方法应有完整的注释，注释内容包含方法功能介绍、参数说明、返回类型说明、例外类型，例如：
9.4.1.2命名空间要求
targetNamespace在食品药品监管信息化工程中的命名为：
。
9.4.2WSDL编写说明
9.4.2.1编写要求
WSDL文档利用如下主要元素描述webservice，如表5所示：
表5WSDL文档描述元素
元素
定义
<
portType>
webservice执行的操作
message>
webservice使用的消息
types>
webservice使用的数据类型
binding>
webservice使用的通信协议
WSDL文档可包含赞成示素，service元素可以在一个WSDL文档中描述多个webService的定义，WSDL文档也可包含其他元素，例如：
extension元素。
WSDL文档中各主要元素具体描述如下：
a）<
元素是最重要的WSDL元素，它可描述可被执行的操作，以及相关的消息，<
name属性的值对应Java中是类名。
b）<
message＞元素定义了web
中函数的参数。
函数的参数，<
message＞元素中的每个子元索都对应Java
c）<
标签定义了webservice用到的数据类型，这些数据类型用来定义webservice方法的参
数和返回值，数据类型可以是Java基本数据类型，也可以通过XMLSchema语法自定义数据类
型。
d）<
元素定义了webservice消息格式和通讯协议的细节。
9.4.2.2WSDL实例
以下是WSDL文档的简化片段的举例：
示例：
wsdl:
partelement=”tns:
concatResponse”name=”parameters”/>
wsdl:
message>
portTypename=”SimpleService”>
portTypename=”concat”>
operationname=”concat”>
wsdl:
outputmessage=”tns:
concatResponse”>
/wsdl:
operation>
bindingname=”SimpleServiceSOAP”type=”tns:
SimpleService”>
soap:
bindingstyle=”document”transport=http:
//schemas.xnlsoap.org/soap/http/>
operationsoapAction=
input>
bodyuse=”literal”/>
output>
operation>
binding>
9.4.3适配器开发规范
食品药品监管信息化工程适用的适配器类型包括：
a）SOCKET（通常也称作“套接字”）通讯方式适配器。
b）HTTP通讯方式适配器。
c）JMS通讯方式适配器。
适配器分为长连接和短连接，以及同步通讯方式和异步通讯方式。
通过适配器可以进行
a）定义webservice:
定义webservice的方法、参数等信息。
b）转换webservice的输入参数：
把节点的输入参数转换为webservice的方法参数。
c）调用webservice:
调用webservice，并输入webservice对应的参数。
d）打包webservice的返回结果：
把webservice运行的结果打包返回。
升级会员 