——第1部分：总则 ——第2部分：应用系统分类及代码规范 ——第3部分：应用系统描述规范 ——第4部分：组织身份模型数据规范 ——第5部分：应用服务运行管理框架规范 ——第6部分：组织身份服务接口规范 ——第7部分：访问控制服务接口规范 ——第8部分：单点登录服务接口规范 ——第9部分：电子表单服务接口规范 ——第10部分：业务流程服务接口规范 |
第1部分 总则
1 范围
本部分规定了本规范的适用范围、通用的名词术语以及各部分内容的相互关系等。
本规范主要用于深圳市各级党政机关的信息系统规划、建设，以及系统集成商、软件开发商和监理单位进行电子政务信息系统的开发与整合。
在涉及国家秘密的信息系统规划、建设中，需参照《涉及国家秘密的信息系统分级保护管理办法》和相关标准、规定。
本部分适用于总标题《深圳市电子政务应用服务规范》下的所有部分。
2 规范性引用文件
下列文件中的条款通过本部分的引用而成为本部分的条款。
凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。
凡是不注日期的引用文件，其最新版本适用于本部分。
GB/T 1.1—2000标准化工作导则 第1部分：标准的结构和编写规则
GB/T 13016—1991标准体系表编制原则和要求
GB/T 20000.1—2002标准化工作指南 第1部分：标准化和相关活动的通用术语
GB/T 21062.1—2007政务信息资源交换体系 第1部分：总体框架
GB/T 21063.1—2007政务信息资源目录体系 第1部分：总体框架
GB/T 19488.1—2004电子政务数据元 第1部分：设计和管理规范
GB/T 21064—2007电子政务系统总体设计要求
HTTP RFC 2616超文本传输协议http://www.w3.org/Protocols/rfc2616/rfc2616.html
SOAP简单对象访问协议（SOAP）http://www.w3.org/TR/SOAP/
WSDL Web服务描述语言（WSDL）http://www.w3.org/TR/wsdl
3 术语和定义
3.1 术语定义
UID：（Unique Identified）。
UID是指在一台机器上生成的字符串，它保证对在同一时空中的所有机器都是唯一的，用于唯一标识一个对象。
UID通常采用UUID标准，但并不限制采用其他格式或标准。
请参考：RFC 4122: A Universally Unique Identifier（UUID）URN Namespace（http://www.ietf.org/rfc/rfc4122.txt）。
3.2 本规范的命名空间
本规范的命名空间如表F-1所示。
在命名空间下，用model、service和exception进行细分，model下放置模型实体类，service下放置服务类，exception下放置异常类。
对象的完整类名是对象所处的完整包名和类名，其格式为：命名空间+model+实体对象类名，区分大小写，如Person实体对象的完整类名是egov.appservice.org.model.Person。
3.3 数据项格式定义
4 编制目的
本规范在现有电子政务建设经验及电子政务标准体系的基础上，规范了应用系统的分类规则和描述方法，采用面向服务架构（SOA）的思想，提出应用服务框架的总体结构和技术要求，定义了组织身份模型，规范了组织身份、访问控制、单点登录、电子表单、业务流程五类共性的、基础的应用服务接口，并可扩展多种类型的应用服务，为应用系统提供服务和支撑，实现软件和业务的高层次复用。
依据本规范，可将原有应用系统中可重用、可共享的功能单元服务化，利于应用系统整合。
各应用系统在不同应用服务框架之间，采用对等的分布式调用机制，通过应用支撑平台的互操作调用，可实现互联互通。
本规范用于规范深圳市电子政务应用系统建设，规范业务系统需求，统一应用服务管理。
5 规范各部分内容
5.1 电子政务应用服务规范体系
电子政务应用服务规范体系如图F-1所示。
图F-1 电子政务应用服务规范体系示意图
本规范由：
总则、 应用系统分类及代码规范、 应用系统描述规范、 组织身份模型数据规范、 应用服务运行管理框架规范、 组织身份服务接口规范、 访问控制服务接口规范、 单点登录服务接口规范、 电子表单服务接口规范、 业务流程服务接口规范共10部分构成 |
5.2 各部分综述
5.2.1第1部分：总则
该部分规定了电子政务应用服务规范的使用范围、通用名词术语以及各部分内容的相互关系。
5.2.2第2部分：应用系统分类及代码规范
该部分规定了电子政务的应用系统分类和编码的原则，以及主题分类类目表。该部分适用于制定电子政务应用系统规划建设时的统一分类工作。
5.2.3第3部分：应用系统描述规范
该部分规定了电子政务中应用系统描述的要素构成。
该部分对编写电子政务应用系统招标文件的技术需求，给出了指导性意见。
该部分适用于在规划、建设电子政务应用系统时，规范描述应用系统的建设结果，使业务人员和技术人员用共同的方式表达和理解应用系统。
5.2.4第4部分：组织身份模型数据规范
该部分规定了电子政务系统中组织身份模型包含的实体、各实体的基本属性及实体间的关系，为电子政务各应用系统中组织身份的应用提供了一致性的语义，为组织身份的统一管理提供了基础元数据。
5.2.5第5部分：应用服务运行管理框架规范
该部分定义了应用服务、服务组件和服务模块，以及它们之间的关系，规定了相应的元数据和元数据的扩展原则及方法，给出了应用服务运行管理框架的组成部分和各部分的功能和技术要求，提供了应用服务框架之间的分布式调用机制，规定了应用服务发布、调用和管理的技术要求和服务接口。
5.2.6第6部分：组织身份服务接口规范
该部分规定了电子政务应用系统中组织身份各种实体的操作接口、实体间关系的操作接口和实体查询接口，规定了组织身份服务的服务注册接口、同其他系统的数据同步接口。
5.2.7第7部分：访问控制服务接口规范
该部分定义了权限管理模型，给出了访问控制框架的组成部分和各部分的技术要求，规定了权限访问接口和权限管理接口、数据集权限接口，提出了访问控制技术要求。适用于应用系统的资源权限控制和数据权限控制。
5.2.8第8部分：单点登录服务接口规范
该部分规定了单点登录服务接口，定义了单点登录票据的模式。适用于需做单点登录整合的应用系统。
5.2.9第9部分：电子表单服务接口规范
该部分定义了电子表单的基本概念，规范了电子表单服务的组成部分、功能以及技术要求，规定了电子表单使用和管理的服务接口，为使用电子表单的应用系统提供统一的、标准的表单服务。
5.2.10第10部分：业务流程服务接口规范
该部分定义了业务流程服务的基本概念，规定了流程定义、流程实例和活动实例的基本状态，规范了流程服务提供的服务接口，包括流程模型服务接口、流程实例服务接口、应用调用服务接口、流程互操作服务接口、流程管理服务接口五部分内容，为应用系统提供统一的流程服务。
第2部分 应用系统分类及代码规范
1 范围
本部分规定了电子政务的应用系统分类和编码的原则，以及主题分类类目表。
本部分主要用于深圳市各级党政机关的信息系统规划与建设，以及电子政务信息系统建设的系统集成商、软件开发商和监理单位进行信息化规划、建设。
适用于制定电子政务应用系统规划建设时的统一分类工作。
2 规范性引用文件
下列文件中的条款通过本部分的引用而成为本部分的条款。
凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。
凡是不注日期的引用文件，其最新版本适用于本部分。
GB/T 7027—2002信息分类和编码的基本原则与方法 GB/T 10113—2003分类与编码通用术语 GB/T 20001.3—2001标准编写导则 第3部分：信息分类编码 GB/T 19488.1—2004电子政务数据元 第一部分：设计和管理规范 GB/T 11714—1997全国组织机构代码编制规则 SZDB/Z 17.1—2008深圳市电子政务应用服务规范 第1部分：总则 |
3 术语和定义
《GB/T 10113—2003分类与编码通用术语》确立的术语适用于本部分。
4 分类原则
（1）科学性。本部分选择电子政务应用系统稳定的本质属性或特征作为分类的基础和依据。
（2）系统性。本部分选择对电子政务应用系统的服务主体、服务内容等进行分类。
（3）可扩延性。本部分可根据实际情况对主题分类进行类目扩充，扩充的类目应符合本部分类目的设置规则。
（4）兼容性。本部分与相关的国家分类标准及相关的国际标准协调一致。
（5）实用性。本部分从系统工程角度出发，立足信息化工程实践。
5 分类代码编码规则
5.1分类代码结构
本部分的分类规则采用统一的代码结构，代码编制规则如下：
（1）单位标识采用组织机构代码，包括其八位数字（或大写拉丁字母）本体代码和一位数字（或大写拉丁字母）校验码，无分隔符。
（2）主题分类用2位大写英文字符表示。
（3）一级系统分类用3位阿拉伯数字编码表示。
（4）二级系统分类用3位阿拉伯数字编码表示。
在主题分类中4组代码代表4种主题类别：
· GB：政府对企业（G2B）
· GC：政府对公民（G2C）
· GG：政府对政府（G2G）
· GI：政府部门内部（GI）
分类代码结构如图F-2所示。
主题分类类目如表F-3所示。
应用系统分类示例如表F-4所示。
第3部分 应用系统描述规范
1 范围
本部分规定了电子政务中应用系统描述的要素构成。
本部分对编写电子政务应用系统招标文件的技术需求，给出了指导性意见。
本部分主要用于深圳市各级党政机关的信息系统规划与建设，以及电子政务信息系统建设的系统集成商、软件开发商和监理单位进行信息化规划、建设。
适用于在规划、建设电子政务应用系统时，规范描述应用系统的建设结果，使业务人员和技术人员用共同的方式表达和理解应用系统。
2 规范性引用文件
下列文件中的条款通过本部分的引用而成为本部分的条款。
凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。
凡是不注日期的引用文件，其最新版本适用于本部分。
GB/T 21064—2007电子政务系统总体设计要求
GB/T 8567—2006计算机软件文档编制规范
SZDB/Z 17.1—2008深圳市电子政务应用服务规范 第1部分：总则
3 术语和定义
《GB/T 8567—2006计算机软件文档编制规范》确立的术语适用于本部分。
4 描述要素
（1）系统名称。采用准确、简洁、能突出系统最核心用途的名称。
（2）系统分类编码。依据本规范《第2部分：应用系统分类及代码规范》，说明应用系统的分类编码。
（3）系统总体目标。通过文字描述应用系统建设需达到的目的，业务范围、最终效果。
（4）使用用户及部门。说明应用系统建立以后，使用系统的主要用户和部门。
（5）系统逻辑结构图。采用图示的方式，主要描述应用系统各业务功能之间与其他相关业务功能之间的逻辑关系，并进行简要的文字说明。
（6）业务流程。说明应用系统涉及的业务流程，以流程图的方式展现业务处理过程，通过业务流程的描述明确各部门间的业务协同关系。
（7）相关表证单书。说明应用系统涉及的各种业务表格、证书、单据的格式。
（8）系统功能描述。说明应用系统包含的功能名称，并对各功能项进行具体描述。
（9）权限说明。根据业务流程的管理和安全需要为系统设定的不同角色，并对角色的使用权限进行描述。
（10）系统指标、数据口径解释。对应用系统涉及的各类指标和数据口径进行解释。
（11）系统信息资源。说明应用系统建设中引入或产生的各种信息资源，包括信息资源清单、数据描述、接口要求、数据处理过程、信息管理要求等。
● 信息资源清单包括信息资源名称、分类、来源、用途等描述。
● 数据描述指对主要数据的简要描述，包括数据名称、类型、单位、格式、范围等。
● 接口要求指信息资源在引入和使用过程中的传输、接口调用方式及条件限制。
● 信息管理要求指信息的采集、更新、管理的方式和要求。
● 数据处理过程指对数据的使用、加工过程。
（12）外部接口。应用系统与其他系统进行交互操作的接口，以及对这种交互操所使用的格式、时间或其他因素的约束。
（13）性能。对系统的负载能力、响应时间、处理时间、查询等待时间、故障恢复时间等要求。
（14）系统实施。包括以下方面：
● 对系统开发采用的编程语言、技术架构的要求。
● 对系统运行需要的硬件设施的要求。包括计算机与服务器、存储设备、网络与通信设备、机房设备等其他所需设备和环境。
● 对系统使用或引入到系统中的软件的要求。包括操作系统、数据库管理系统、通信及网络软件、应用服务器中间件、测试软件等。
（15）系统安全要求。应用系统的安全等级要求、数据存储与传输的保密约束、使用限制等。
（16）标准与规范。应用系统必须遵序的技术标准与规范。
（17）运维管理。应用系统在运行维护期间的管理要求，包括管理制度、技术支持方式、驻场维护、用户培训、绩效评定等。
第4部分 组织身份模型数据规范
1 范围
本部分规定了电子政务系统中组织身份模型包含的实体、各实体的基本属性及实体间的关系，为电子政务各应用系统中组织身份的应用提供了一致性的语义，为组织身份的统一管理提供了基础元数据。
本部分主要用于深圳市各级党政机关的信息系统规划与建设，以及电子政务信息系统建设的系统集成商、软件开发商和监理单位进行信息化规划、建设。
适用于在电子政务系统建设开发中，对政府部门组织结构抽象建模时进行规范性引导。主要对模型中包含的实体及属性进行规范。
本部分适用于总标题《深圳市电子政务应用服务规范》下的所有部分。
2 规范性引用文件
下列文件中的条款通过本部分的引用而成为本部分的条款。
凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。
凡是不注日期的引用文件，其最新版本适用于本部分。
GB 12407—1990干部职务级别代码
GB 11714—1997全国组织机构代码编制规则
GB/T 16987—2002组织机构代码信息数据库（基本库）数据格式
GB/T2260—2007中华人民共和国行政区划代码
GB/T 20091—2006组织机构类型
GB/T 14946—2002全国干部、人事管理信息系统指标体系分类与代码
SZDB/Z 17.1—2008深圳市电子政务应用服务规范 第1部分：总则
3 术语和定义
版本号：是一个0或正整数，从0开始，以递增1为一个新版本号。
用来区分同一个对象在不同时间内的不同状态，一个对象的某一版本号代表了这个对象的特定状态。
序号：是一个整数，用来进行排序。职务级别：具一个整数类型的属性，请参考GB 12407-1990《干部职务级别代码》，如表F-5所示。
4 组织身份模型概述
组织身份模型是对电子政务系统中涉及的机构、部门、人员、角色、用户组、岗位等实体的抽象，是电子政务应用系统的一个基础数据模型。
组织身份模型对机构、部门、人员实体提供了区分实体生命周期信息的数据项（版本号）。
基于这个数据项，可实现对这些实体全生命周期的信息管理及其他相关业务逻辑的处理。如对某个人员在某个时间段职务变化的信息查询。
5 组织模型定义
5.1 组织模型实体定义
机构：对应的实体名为Organization，指在社会生活中，人们为实现某种职能所建立的、由人财物和信息等若干因素有序地联结起来的、相对稳定的社会实体单位的抽象，通常指机关、团体或其他工作单位及其内部组织，例如深圳市人民政府。
部门：对应的实体名为Department，是根据行政划分而实际存在的实体部门的抽象，例如深圳市政府办公厅。
人员：对应的实体名为Person，是部门内的实体人员及类似实体的抽象，例如张三。
角色：对应的实体名为Role，指在处理特定业务时设定的具有特定工作范围或工作职责，用于解决特定业务问题的实体抽象，例如办公室文件管理员。
用户组：对应的实体名为Group，是为满足特定业务需求而组建的、不受机构或部门限制的人员集合的抽象，可以是临时的或长期的，例如信息化领导小组。
岗位：对应的实体名为Position，是根据部门编制、实际存在的工作岗位的实体抽象，例如工商局局长。
5.1.1 实体的描述方法
对各实体的属性进行描述，实体的属性包括数据类型、值域、约束、示例、描述五方面的定义。
（1）数据类型。说明实体属性的数据类型，对实体属性的有效值域及允许的有效操作进行规定，例如整型、实型、布尔型、字符型、日期型等。
（2）值域。说明实体属性可以取值的范围。
（3）约束。说明实体属性必须遵守的一些强制性规则，如不可取空值等。
（4）示例。对于每一个属性元素，都列举一个填写内容示例，如部门名字的取值示例：信息化办公室。
（5）描述。对实体属性的意义进行简短的描述。
5.1.2 实体描述
1．机构
机构是指在社会生活中，人们为实现某种职能所建立的、由人财物和信息等若干因素有序地联结起来的、相对稳定的社会实体单位的抽象，通常指机关、团体或其他工作单位及其内部组织，例如深圳市人民政府。
机构属性如表F-6所示。
2．部门
部门是根据行政划分而实际存在的实体部门的抽象，例如：深圳市政府办公厅。
部门属性如表F-7所示。
3．人员人员是部门内的实体人员及类似实体的抽象，例如：张三。
人员属性如表F-8所示。
4．角色
角色是指在处理特定业务时设定的具有特定工作范围或工作职责，用于解决特定业务问题的实体抽象，例如办公室文件管理员。
角色属性如表F-9所示。
5．用户组
用户组是为满足特定业务需求而组建的，不受机构或部门限制的人员集合的抽象，可以是临时的或长期的，例如信息化领导小组。
用户组的属性如表F-10所示。
6．岗位
岗位是根据部门编制实际存在的工作岗位的实体抽象，如工商局局长。
岗位的属性如表F-11所示。
5.2 组织身份模型实体关系
如图F-3所示，组织身份模型实体关系是组织身份模型中各个实体之间的关联关系的统称。
● 机构和部门的关系：一对多关系，一个机构可以包含多个部门，一个部门只能被一个机构包含。
● 机构和人员的关系：一对多关系，一个机构可以包含多个人员，一个人员只能被一个机构包含。
● 机构和角色的关系：一对多关系，一个机构可以包含多个角色，一个角色只能被一个机构包含。
● 机构和岗位的关系：一对多关系，一个机构可以包含多个岗位，一个岗位只能被一个机构包含。
● 机构和组的关系：一对多关系，一个机构可以包含多个组，一个组只能被一个机构包含。
● 部门和部门的关系：一对多关系，一个部门可以包含多个子部门，一个子部门只能被一个部门包含。
● 部门和人员的关系：一对多关系，一个部门可以包含多个人员，一个人员只能被一个部门包含。
● 部门和角色的关系：一对多关系，一个部门可以包含多个角色，一个角色只能被一个部门包含。
● 部门和岗位的关系：一对多关系，一个部门可以包含多个岗位，一个岗位只能被一个部门包含。
● 部门和组的关系：一对多关系，一个部门可以包含多个组，一个组只能被一个部门包含。
● 组和组的关系：多对多关系，一个组可以包含多个组，一个组也可以被多个组包含。
● 组和人员的关系：多对多关系，一个组可以包含多个人，一个人也可以被多个组包含。
● 岗位和人员的关系：多对多关系，一个岗位可以由多个人员担任，一个人员也可以担任多个岗位。
● 角色和人员的关系：多对多关系，一个人员可以担当多种角色，一个角色也以由多个人员担当。
● 角色和角色的关系：一个角色可以包含多个子角色，一个子角色也可以被多个父角色包含。
5.3 实现要求
5.3.1 实体属性的扩展
由于各个实体在不同环境下的抽象会有不同，所以本部分规定了对每个实体的属性的扩展方法，所有的实体都包含一个properties属性，它是一个键、值对应的数据结构，里面的键代表属性名，值代表属性值。
如人员实体中，若properties中有一组值为（“英文名”，“jiem”），则表明这个人员实体对象具有一个“英文名”属性，其属性值为“jiem”。
5.3.2 实体生命周期信息的体现
由于电子政务应用系统的特殊要求，对于一些实体必须保证它的整个生命周期的信息具有可跟踪性。
基于此需求，本部分规定了机构、部门、人员三个实体对象必须具有版本号（version）属性，版本号属性请参考“3术语和定义”。
版本号属性的具体值体现了实体生命周期的状态，据此能做出对实体生命周期的管理及相关业务逻辑的设计。
图F-4是××区组织身份模型示例。
第5部分 应用服务运行管理框架
1 范围
本部分定义了应用服务、服务组件和服务模块，以及它们之间的关系，规定了相应的元数据和元数据的扩展原则及方法，给出了应用服务运行管理框架的组成部分和各部分的功能和技术要求，提供了应用服务框架之间的分布式调用机制，规定了应用服务发布、调用和管理的技术要求和服务接口。
本部分主要用于深圳市各级党政机关的信息系统规划与建设，以及电子政务信息系统建设的系统集成商、软件开发商和监理单位进行信息化规划、建设。
适用于构建共性的、基础的、开放的应用支撑平台，为应用系统建设提供基础的应用服务。
并可将原有应用系统中可重用、可共享的功能单元服务化，利于应用系统整合。
各应用系统在不同应用服务框架之间，采用对等的分布式调用机制，通过应用支撑平台的互操作调用，可实现互联互通。
2 规范性引用文件
下列文件中的条款通过本部分的引用而成为本部分的条款。
凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。
凡是不注日期的引用文件，其最新版本适用于本部分。
GB/T 19488.1—2004电子政务数据元 第1部分：设计和管理规范
GB/T 21062.3—2007政务信息资源交换体系 第3部分：数据接口规范
GB/T 21062.4—2007政务信息资源交换体系 第4部分：技术管理要求
GB/T 21064—2007电子政务系统总体设计要求
GB/Z 19669—2005 XML在电子政务中的应用指南
SZDB/Z 17.1—2008深圳市电子政务应用服务规范 第1部分：总则
3 术语和定义
3.1 名词解释
local调用：本地调用，指调用方与被调用方处于同一个运行环境中，并可直接通过API的方式进行调用。
remote调用：远程调用，指调用方与被调用方处于不同的运行环境或不同的主机、网络环境中，通过Web服务的方式进行远程调用。
lazy调用：延迟的、延后的调用，指在调用服务时先获得服务的代理对象，只在实际执行调用时才真正发起调用。
3.2 术语定义
3.2.1 应用服务
应用服务是电子政务应用系统中公共的、可定义的、可注册的和可调用的功能单元。
应用服务作为公共服务，在更高层的基础上提供软件复用和业务复用，可通过应用服务元数据明确定义，可通过应用服务框架发布并注册在服务库中，可将第三方发布好的服务注册在服务库中，可通过应用服务框架进行监控和管理，可随时透明的被本地或远程查找和调用。
应用服务应该满足如下技术要求：
（1）同时以API和Web服务的形式提供服务。
（2）应用服务都是无状态的，每次对应用服务的调用都具有完整语义，与上下文无关。
（3）消息传输基于HTTP/1.1（RFC 2616）或JMS协议。
（4）采用W3C的SOAP 1.2作为消息封装格式。
（5）采用W3C的WSDL 1.2作为服务描述规范。
3.2.2 应用服务运行管理框架
应用服务运行管理框架简称应用服务框架，是应用服务的运行、监控、管理的框架。
应用服务框架提供了统一的服务库注册、存储、查询的应用服务元数据信息，提供了发布、调用应用服务的功能，可对应用服务及调用进行监控、管理，同时提供了本地和远程调用，可支持分布式应用和负载均衡。
在不同的应用服务框架之间，采用对等的分布式调用机制，可注册远程的服务库到本地。
可通过应用服务框架之间的互操作调用，实现互联互通。
应用服务框架本身不提供访问控制的功能，但可借助访问控制服务模块实现对应用服务的认证、授权和访问控制。
应用服务框架作为软件基础设施，通过部署在上面的服务模块，以标准的协议对外提供服务，可实现更高层次的软件复用和业务复用，可将原有应用系统中可重用、可共享的功能单元服务化，利于应用系统整合。
应用服务框架提供高度可集成的能力，采用标准的Web服务协议组作为服务接口描述和调用规范，可屏蔽不同软件平台的差异，实现透明的互操作。
3.2.3 服务模块
服务模块是进行部署的最小单位，是满足某些特定功能需求的一组相关应用服务的集合，可以是软件包的形式，也可以是第三方提供的应用服务集合的形式。
服务模块可通过元数据描述文件（服务组件描述模式schema）描述并部署在应用服务框架上，也可通过应用服务框架提供的界面或API来部署，由应用服务框架实行统一的监控和管理。
3.2.4 服务组件
服务组件是服务模块的基本组成元素和基本构建单位，是粒度最小的实现和发布单元，是相关的一组应用服务的具体实现，它的功能以应用服务的形式提供。
服务组件具有可设置的属性，其属性是可以改变服务功能的数据。服务模块由一个或多个服务组件及相关配置信息构成。
4 元数据
4.1 元数据描述方法
采用摘要表示的方法定义和描述元数据，摘要包括以下属性：中文名、英文名、数据类型、值域、约束、说明。
（1）中文名。元数据的中文名称，中文名称在同一类元数据中是唯一的。
（2）英文名。元数据的英文名称，英文名称在同一类元数据中是唯一的，比较时不区分大小写。可包含的字符为大小写的英文字母、数字，所有组成词汇为无缝连写。
（3）数据类型。元数据的数据类型。
（4）值域。元数据可以取值的范围。
（5）约束。元数据的约束性条件，包括是否非空、最大出现的次数、是否唯一。
（6）说明。对元数据含义的进一步的解释及补充说明。
4.2 应用服务及服务组件元数据
通过应用服务元数据对应用服务进行描述，发布、查找和调用应用服务时都需使用元数据信息。
应用服务和服务组件都使用相同的元数据描述。
本部分定义了核心元数据，即所有应用服务描述中共性的、必不可少的元数据，如表F-12所示。
4.3 服务模块元数据
5 应用服务框架组成
5.1 工作原理
应用服务框架提供了应用服务的发布、注册、查找、调用、监控、管理功能，其中涉及三个角色：服务提供者、服务请求者、服务库。
图F-5所示，应用服务工作原理如下：
（1）服务提供者开发符合应用服务技术要求的功能单元，将开发好的功能发布为应用服务，并将应用服务在服务库中注册。
（2）服务请求者在服务库中查找所需服务，根据返回的结果确定需要调用的应用服务。
（3）服务请求者根据需要调用的应用服务，获得应用服务的代理对象。
（4）服务请求者发起调用请求，对应用服务进行实际调用，并获得服务返回的结果。
在整个提供服务的过程中，三个角色的基本功能如下。
（1）服务提供者：发布服务、进行注册。
（2）服务请求者：查找服务、调用服务。
（3）服务库：服务注册、服务查找、监控管理。
5.2 总体框架
如图F-6所示，应用服务框架由服务库、发布模块、调用模块、管理模块和监控模块五部分组成。
服务库提供对应用服务元数据的注册、存储和查找功能，可以将服务模块、服务组件和应用服务注册在服务库中。
发布模块提供将功能单元服务化的功能，读取并解析注册描述文件，将描述在其中的接口发布为应用服务，并自动注册到服务库中。
调用模块封装对应用服务的调用过程，屏蔽技术实现细节，直接实现对应用服务的调用，可与应用服务框架部署在一起，也可单独部署在应用服务的调用端。
调用模块可将远程应用服务框架注册到本地，能对远程服务库查找和调用，实现不同应用服务框架之间的分布式调用。
管理模块提供对服务模块、组件和应用服务的管理功能，通过访问控制服务模块实现对应用服务的授权和访问控制，并提供UI界面实现人机交互。
监控模块在记录应用服务调用日志的基础上提供审计、统计和分析功能，可监控和改变应用服务的运行状态。
6 应用服务框架技术要求
应用服务框架作为应用支撑平台的基础架构，要求稳定、可靠，能够满足分布式、负载均衡、高可用的要求，能够动态部署和更新服务模块，能够实现对服务的实时管理。
6.1 服务库
服务库在应用服务框架中是服务模块、服务组件和应用服务信息的存储仓库，并提供管理服务接口，包括注册服务、修改服务、删除服务、改变服务状态等接口。
为使服务能够被发现、被使用，还提供服务信息的查询、获取接口。服务库作为应用服务框架的核心部分之一，要求稳定、高效及支持集群。对应用服务信息的存储可以采用多种方式，包括目录服务、数据库、文件系统或其他方式。
6.1.1 注册服务
应用服务框架应提供注册服务的功能。它可注册两类服务，一类由应用服务框架发布的服务，这类应用服务在发布的同时，自动在服务库注册，并将服务的状态标记为活动状态。
另一类是第三方发布的Web服务，可通过人工或自动的方式注册。
人工方式可以通过服务库提供的UI界面进行注册，自动方式可以调用服务库提供的服务注册接口注册。
通过管理服务接口可对应用服务进行变更、删除、改变状态等操作。
6.1.2 查找服务
（1）人工查找服务。服务库提供UI界面，通过此界面可对服务进行查找，可查看服务的元数据属性，了解服务的运行状态及服务质量（QoS）等信息。
（2）自动查找服务。服务的调用方可通过筛选条件进行服务查询。
6.2 发布模块
应用服务框架提供发布服务的功能，可将封装良好的功能单元发布为应用服务。
服务提供方在描述文件中对服务模块和组件的实现进行描述和配置，应用服务框架读取此配置文件，将其中服务组件的具体实现发布为应用服务，并自动将其注册到服务库。
本部分不规定服务模块描述文件的位置，而是通过META-INF/MANIFEST.MF文件中的Asf-Definition属性确定服务模块描述文件的位置。应用服务框架应支持服务模块的动态部署和更新，不必重新启动系统。
6.3 调用模块
通过查找服务确定需要调用的服务后，可通过应用服务接口获得服务对象，此接口返回服务的代理对象，只有在实际执行调用时，才会根据应用服务的位置，发起local调用或remote调用。
如果应用服务在远程，发起remote调用；
如果应用服务在本地，发起local调用。执行local调用时，根据不同的开发语言，对象是按照传引用方式（传地址）或传值方式引用；
执行remote调用时，对象是按照传值方式引用。关于调用服务的技术要求：
（1）要求支持Lazy调用，首先获得的是服务的代理对象，只有在实际执行调用时，才真正发起调用。
（2）要求透明的支持local调用和remote调用，在客户端代码及配置不做改动的情况下，可以动态调整应用服务提供方的位置。
6.4 管理模块
（1）应用服务管理功能。应用服务管理功能包括应用服务的注册、删除、修改、改变服务状态等功能，并提供对服务模块、服务组件的管理功能。
（2）应用服务列表。应用服务框架应提供应用服务列表，其中的信息包括服务的名称、所属的服务库、服务的状态、服务的处理日志和服务的性能记录等。
（3）应用服务认证、访问控制。应用服务框架本身不提供访问控制的功能，可借助访问控制服务模块实现对应用服务的认证、授权和访问控制，如只允许经过认证的服务请求者才可访问指定的应用服务。
6.5 监控模块
（1）监控。应用服务框架可以监控服务模块、组件和应用服务的运行状态，并可改变应用服务状态。
（2）日志。应用服务框架详细记录每次服务调用的日志信息，包括调用的发起者、调用的服务、发起时间、响应时间、成功/失败等信息。
（3）审计。应用服务框架提供审计功能，对服务的调用情况进行审计。
（4）统计分析。应用服务框架提供对应用服务的运行状况的统计、分析功能，包括应用服务的运行状态、调用次数、平均响应时间、成功/失败次数等信息。
7 接口定义
本接口所处的命名空间为：egov.appservice.asf。
7.1 服务组件管理接口
7.1.1注册服务组件接口
注册服务组件接口如表F-14所示。
7.1.2 修改服务组件接口
修改服务组件接口如表F-15所示。
7.1.3 删除服务组件接口
删除服务组件接口如表F-16所示。
7.1.4 查找服务组件接口
查找服务组件接口如表F-17所示。
7.1.5 获取服务组件接口
获取服务组件接口如表F-18所示。
7.2 服务模块管理接口
7.2.1 创建服务模块接口
创建服务模块接口如表F-19所示。
7.2.2 修改服务模块接口
修改服务模块接口如表F-20所示。
7.2.3 删除服务模块接口
删除服务模块接口如表F-21所示。
7.2.4 查找服务模块接口
查找服务模块接口如表F-22所示。
7.2.5 获取服务模块接口
获取服务模块接口如表F-23所示。
7.3 应用服务管理接口
7.3.1 获取应用服务状态接口
获取应用服务状态接口如表F-24所示。
7.3.2 改变应用服务状态接口
改变应用服务状态接口如表F-25所示。
7.3.3 查询应用服务接口
查询应用服务接口如表F-26所示。
7.3.4 应用服务日志接口
应用服务日志接口如表F-27所示。
7.4 服务库管理接口
7.4.1 注册远程服务库接口
注册远程服务库接口如表F-28所示。
7.4.2 移除远程服务库接口
移除远程服务库接口如表F-29所示。
7.4.3 查询远程服务库接口
查询远程服务库接口如表F-30所示。
7.4.4 查询远程应用服务接口
查询远程应用服务接口如表F-31所示。
7.5 获取应用服务接口
7.5.1 获得本地平台客户端接口
获得本地平台客户端接口如表F-32所示。
7.5.2 获得远程平台客户端
获得远程平台客户端如表F-33所示。
7.5.3 通过UID获取服务接口
通过UID获取服务接口如表F-34所示。
7.5.4 通过Name获取服务接口
通过Name获取服务接口如表F-35所示。
7.5.5 通过WSDL获取服务接口
通过WSDL获取服务接口如表F-36所示。
7.6 异常约定
应用服务运行管理框架应包含异常如表F-37所示。
应用服务框架异常关系示如图F-7所示。
第6部分 组织身份服务接口规范
1 范围
本部分规定了电子政务应用系统中组织身份各种实体的操作接口、实体间关系的操作接口和实体查询接口，规定了组织身份服务的服务注册接口、同其他系统的数据同步接口。
本部分主要用于深圳市各级党政机关的信息系统规划与建设，以及电子政务信息系统建设的系统集成商、软件开发商和监理单位进行信息化规划、建设。
适用于依据本规范“第4部分：组织身份模型数据规范”建立的组织模型基础上，对组织身份管理接口、信息接口和同步接口的开发过程进行规范性指导。
本部分也适用于指导基于组织模型构建的各类应用系统对组织模型相关接口的调用，实现组织身份统一管理。
2 规范性引用文件
下列文件中的条款通过本部分的引用而成为本部分的条款。
凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。
凡是不注日期的引用文件，其最新版本适用于本部分。
SZDB/Z 17.1—2008深圳市电子政务应用服务规范 第1部分：总则
SZDB/Z 17.4—2008深圳市电子政务应用服务规范 第4部分：组织身份模型数据规范
ISO/IEC 9075: 1992, Information Technology-Database Language SQL
3 作用
规范组织身份服务的管理接口、信息接口和同步接口，使应用系统以统一的方式获取组织身份信息。
应用系统只需关注业务流程及业务逻辑的设计，认证、组织身份信息均可以由组织身份服务接口获得。
组织身份服务以组织身份模型为数据来源，为访问控制服务、单点登录服务等提供运行支撑。
4 接口定义
本接口所处的命名空间为：egov.appservice.org。
组织身份服务接口分为身份认证接口、组织身份管理接口、组织身份信息接口、身份同步接口四大类。
4.1 身份认证接口
为其他应用系统提供统一的身份认证。
4.1.1 认证接口
认证接口描述如表F-38所示。
4.1.2 CA认证通知接口
CA认证通知接口描述如表F-39所示。
4.2 组织身份管理接口
4.2.1 对实体的管理
1．部门对象的管理
（1）创建部门
创建部门描述如表F-40所示。
（2）更新部门
更新部门描述如表F-41所示。
（3）移动部门
移动部门描述如表F-42所示。
（4）删除部门
删除部门描述如表F-43所示。
（5）禁用部门
禁用部门描述如表F-44所示。
（6）恢复部门
恢复部门描述如表F-45所示。
2．人员对象管理
（1）创建人员
创建人员描述如表F-46所示。
（2）更新人员
更新人员描述如表F-47所示。
（3）移动人员
移动人员描述如表F-48所示。
（4）删除人员
删除人员描述如表F-49所示。
（5）禁用人员
禁用人员描述如表F-50所示。
（6）恢复人员
创建人员描述如表F-51所示。
3．角色对象
（1）创建角色
创建角色描述如表F-52所示。
（2）更新角色
更新角色描述如表F-53所示。
（3）移动角色
移动角色描述如表F-54所示。
（4）删除角色
删除角色描述如表F-55所示。
4．用户组对象
（1）创建用户组
创建用户组描述如表F-56所示。
（2）更新用户
组更新用户组描述如表F-57所示。
（3）移动用户组
（4）删除用户组
5．岗位对象
（1）创建岗位
（2）更新岗位
（3）移动岗位
（4）删除岗位
6．机构对象
（1）创建机构
（2）更新机构
（3）删除机构
（4）禁用机构
（5）恢复机构
4.2.2对实体对象关系的管理
1．组和人员的关系
（1）建立关系
（2）删除关系
2．用户组和子用户组的关系
（1）建立关系
（2）删除关系
3．角色和人员的关系
（1）建立关系
（2）删除关系
4．角色和子角色的关系
（1）建立关系
（2）删除关系
5．岗位和人员的关系
（1）建立关系
（2）删除关系
4.3 组织身份信息接口
4.3.1组织查询
1．根据唯一标识查询实体对象
2．根据条件查询实体对象
4.3.2获得组织身份信息
1．获得机构信息
（1）获得所有机构对象
（2）获得机构直接包含的部门
（3）获得机构直接包含的用户组
（4）获得机构直接包含的角色
（5）获得机构直接包含的岗位
（6）获得机构直接包含的人员
2．获得人员信息
（1）获得人员父节点
（2）获得人员所属岗位
（3）获得人员所属的组
（4）获得人员所承担的角色
3．获得部门信息
（1）获得部门父节点
（2）获得部门直接包含的子部门
（3）获得部门直接包含的用户组
（4）获得部门直接包含的角色
（5）获得部门直接包含的岗位
（6）获得部门直接包含的人员
（7）获得部门包含的所有人员
4．获得用户组信息
（1）获得用户组父节点
（2）获得用户组的所有人员
（3）获得用户组直接包含的人员
（4）获得用户组的子用户组
（5）获得用户组的父用户组
5．获得角色信息
（1）获得角色的父节点
（2）获得角色的所有承担者
（3）获得角色的直接承担者
（4）获得角色的子角色
（5）获得角色的父角色
6．获得岗位信息接口
（1）获得岗位的父节点
（2）获得本岗位的所有人员
4.4 组织身份监听接口
组织身份同步服务可以从组织身份模型向其他应用系统同步组织身份数据。
（1）eventType：事件类型，表明由于该类型事件引起源对象发生变化，对应下表中的第二列。事件类型有：
● 创建（C）：创建了一个实体，值为1。
● 更新（U）：更新了一个实体对象的属性，或者改变了该实体的状态，值为2。
● 移动（M）：移动了一个实体到另一个节点下面，并移动了包含在实体下的所有对象，值为3。
● 删除（D）：删除了一个实体，同时删除了包含在实体下的所有对象，值为4。
● 增加（A）：建立了实体间的引用关系，值为5。
● 移除（R）：删除了实体间的引用关系，值为6。
● 同步（SYNC）：从指定的节点开始，递归同步此节点下的所有节点，值为7。
（2）objects：描述发生变化的源对象数组，对应下表中的第三列。
（3）targetUID：被影响的目标对象，对应下表中的第四列。
4.4.1注册服务
4.4.2注销服务
4.4.3获得监听服务列表
4.4.4执行同步
4.5异常约定
第7部分 访问控制服务接口规范
1 范围
本部分定义了权限管理模型，给出了访问控制框架的组成部分和各部分的技术要求，规定了权限访问接口、权限管理接口和数据集权限接口，提出了访问控制技术要求。
适用于应用系统的资源权限控制和数据权限控制。
本部分主要用于深圳市各级党政机关的信息系统规划与建设，以及电子政务信息系统建设的系统集成商、软件开发商和监理单位进行信息化规划、建设。
适用于对应用系统的资源和数据进行授权、权限控制，提供权限管理服务。
2 规范性引用文档
下列文件中的条款通过本部分的引用而成为本部分的条款。
凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。
凡是不注日期的引用文件，其最新版本适用于本部分。
SZDB/Z 17.1—2008深圳市电子政务应用服务规范 第1部分：总则
SZDB/Z 17.4—2008深圳市电子政务应用服务规范 第4部分：组织身份模型数据规范
SZDB/Z 17.6—2008深圳市电子政务应用服务规范 第6部分：组织身份服务接口规范
ISO/IEC 9075: 1992, Information Technology-Database Language SQL
3 权限管理模型
3.1 概述
访问控制是针对越权使用资源的防御措施。
基本目标是为了限制访问主体（用户、进程、服务等）对访问客体（文件、系统等）的访问权限，使计算机系统在合法的范围内使用，决定用户能做什么，也决定代表用户的程序能做什么。
访问控制决定了谁能够访问系统，能访问系统的何种资源以及如何使用这些资源。
访问控制能够阻止未经允许的用户有意或无意地越权获取数据。
3.2 访问控制基本概念
主体（Subject）：或称为发起者（Initiator），是可以访问资源的实体，通常指用户或代表用户执行的程序。
客体（Object）：是需要保护的资源，又称作目标（Target）。
授权（Authorization）：是可以对资源执行的动作，例如读、写、执行或拒绝访问。
3.3 访问控制服务原理
通过建立统一的访问控制模型，提供统一的权限访问接口和管理接口，提供统计、日志、事件、审计、查询等功能，实现应用系统权限管理的一致性、易管理和易维护。
通过权限访问接口，为各应用系统提供统一的访问策略和权限控制。通过权限管理接口，使各应用系统能够创建自己的访问控制资源并进行权限分配。
3.4 权限管理模型
根据电子政务体系对访问控制的要求，访问控制模型参考Constrained RBAC模型，并在此基础上进行扩展，增加Actor对象，即用户（User）和角色（Role）的集合；增加域（Domain）对象，即授权的作用范围；
增加用户（User）和权限（Permission）的关系，即除对角色授权外，单个用户（User）可以直接授权。
基本概念定义如下：
操作者（Actor）：执行者、参与者。包含用户和角色的集合总称，可以是应用系统的代理，或其他任何能够发起请求的对象。可以反向包含自身，即树状结构。接口中引用的actorUID泛指用户对象、角色对象和代理对象的UID值。
用户（User）：发起请求的主体，对应组织机构中得Person对象，或者一个应用代理程序。可以通过授权管理对用户直接进行授权。
角色（Role）：一组具有相同属性或者业务需求的人员集合，是授权的主体，可以是组织模型中的机构、部门、用户组、角色、岗位等。组织机构类型参见第4部分组织身份模型数据规范。
资源（Resource）：对象（Object）。资源或对象，被授权对象。可以反向包含自身，即树状结构。
操作（Operation）：权限类型。是访问控制可以执行的最小功能项，被Actor调用或执行。
许可（Permission）：同义词Privilege。是一个许可，对在一个或多个Resource上执行的Operation的许可。
会话（Session）：每个Session是一个用户到多个Role的映像，当一个Actor启动它所有角色的一个子集的时候，建立了一个Session。每个Session和单个的Actor关联，并且Actor可以关联到一个或多个Session。
域（Domain）：描述作用范围，也叫作用域。通过分配不同的对象（Actor、Resource、Operation）生成授权范围，授权是在域的范围内进行。
3.5 模型实体描述
3.5.1 执行者（Actor）
3.5.2 资源（Resource）
3.5.3 操作类型（Operation）
3.5.4 域（Domain）
3.6 访问控制规则
（1）授权方式。正向授权，开始时假定主体没有任何权限，然后根据需要授予权限。
（2）权限继承。权限的继承通过对象的父子关联实现，如果设置为可继承，则执行者子对象自动继承父对象的权限，子资源自动继承父资源的权限。
（3）权限过滤。通过设置相应的权限过滤规则，控制资源的权限继承，过滤当前资源节点从父节点继承获得的访问权限。
（4）再授权。再授权是指权限拥有者将自己拥有的权限再分配给其他用户，这个授权过程称之为再授权过程。再授权中的权限具有包含关系，即只能授予自己拥有的权限。
（5）权限回收。权限回收是指系统回收已经分配给用户的权限。根据不同的情况，通过权限继承得到的权限，如果父权限被回收，子权限必定被回收；通过再授权得到的权限，根据设置不同规则，可规定父权限被回收，保留或回收子权限。
（6）权限排斥。权限的排斥主要是指当用户拥有权限A时，则不能同时再拥有权限B。通过定义权限排斥规则，通过静态方式或者动态方式计算权限排斥。
（7）负权限。负权限是指操作者不应该拥有的权限。负权限通过权限计算叠加完成，计算时负权限优先。
（8）权限等效。权限等效是指如果设置用户B等效于用户A，则用户B拥有用户A的所有权限。A称为被权限等效对象，B称为权限等效对象。权限等效具有时效性。
4．访问控制接口
接口命名空间：egov.appservic.ac。访问控制接口分为权限访问接口、管理接口、数据权限接口三类。
4.1 权限访问接口
4.1.1 权限判断
判断Actor对Resource是否有指定操作权限描述如表F-120所示。
4.1.2 权限查询
1．获得Actor对象对Resource的操作类型
2．获得Actor对象能以指定操作类型访问的资源
3．获得在资源对象上具有指定操作类型的Actor对象
4．获取Actor数组对资源数组是否具有指定的操作
4.2 管理接口
4.2.1 操作者管理
1．创建操作者
2．修改操作者
3．删除操作者
4．获得操作者对象
5．获得操作者包含的子对象
6．获得操作者的父对象
7．查找操作者
4.2.2资源管理
1．创建资源对象
2．更新资源对象
3．删除资源对象
4．获得资源对象
5．获得资源对象的子对象
6．获得资源对象的父对象
7．查找资源对象
4.2.3 操作类型管理
1．创建操作类型
2．更新操作类型
3．删除操作类型
4．增加子操作类型
5．移除子操作类型
6．获得操作类型对象
7．获得子操作类型
8．获得父操作类型
9．查找操作类型
4.2.4 域管理
1．创建域对象
2．修改域对象
3．删除域对象
4．获得域对象
5．查找域对象
6．向域中增加对象
7．从域中移除对象
8．获得域中对象
9．获得对象所属的域对象
4.2.5 分配权限
1．直接授权
2．批量授权
3．权限回收
4．新建权限过滤
5．删除权限过滤
6．获得权限过滤
7．新建权限等效
8．删除权限等效
9．获取权限等效的对象
10．获取被权限等效的对象
4.3 数据权限
数据权限根据不同的业务需求，可以划分为行数据权限、数据范围权限、表权限、字段权限。其中行数据权限、数据范围权限可归为行权限，表权限、字段权限可归为列权限。
为了对数据资源进行授权和控制，将数据映射为Resource，对数据的操作映射为Operation，整个授权过程与普通的Resource对象相同。
由此根据数据类型的不同，会产生相应的Resource对象：
（1）DataRowResource，行数据资源，资源类型名称是DataRowResource，记录行数据的基本信息，由于数据动态产生，只有在数据产生时生成DateRowResource对象。
（2）DataScopeResource，数据范围资源，资源类型名称是DataScopeResource，记录符合特定条件的行数据集合，由于包含多条动态数据，DateScopeResource对象只记录产生数据集合的条件，并不包含实体数据。
（3）TableResource，表资源，资源类型名称是TableResource，映射数据库表对象。
（4）TableColumnResource，字段资源，资源类型名称是TableColumnResource，映射数据库表列字段。
4.3.1 DataRowResource
4.3.2 DataScopeResource
4.3.3 TableResource
4.3.4 TableColumnResource
4.3.5获得Actor对象能以指定操作访问的行数据资源
4.3.6获得Actor对象能以指定操作类型访问的数据范围资源
4.3.7获得Actor对象能以指定操作类型访问的数据范围资源SQL
4.4 异常约定
5 访问控制要求
5.1 日志
要求能够记录用户访问日志，包括用户登录、用户操作等；
授权日志，包括权限的授予、权限变更等；
系统日志，包括访问异常、权限操作异常等。可以根据访问者的权限提供日志的查询、删除功能，日志纪录可以是log文件、数据库、XML等。
5.2 审计
通过对用户访问日志和权限日志进行分析，检查某一时间顺序的用户访问过程和授权过程，对其中出现的资源访问、权限授予、权限变更、权限策略等进行检查，形成审计结果。
5.3 统计
对指定条件下的访问纪录或者权限纪录进行统计，获得统计信息，如获得访问者对指定资源对象的访问次数；
访问者的对指定资源的权限变更纪录等。可以通过列表方式或者图表方式进行展示。
第8部分 单点登录服务接口规范
1 范围
本部分规定了单点登录服务接口，定义了单点登录票据的模式。
本部分主要用于深圳市各级党政机关的信息系统规划与建设，以及电子政务信息系统建设的系统集成商、软件开发商和监理单位进行信息化规划、建设。
适用于需做单点登录整合的应用系统，也适用于应用系统间实现基于票据传递的单点登录整合。
用于指导开发商对应用系统进行单点登录整合，约束应用系统单点登录接入的实现。
2 规范性引用文件
下列文件中的条款通过本部分的引用而成为本部分的条款。
凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。
凡是不注日期的引用文件，其最新版本适用于本部分。
SZDB/Z 17.1—2008深圳市电子政务应用服务规范 第1部分：总则
SZDB/Z 17.4—2008深圳市电子政务应用服务规范 第4部分：组织身份模型数据规范
SZDB/Z 17.6—2008深圳市电子政务应用服务规范 第6部分：组织身份服务接口规范
3 术语和定义
票据：用户在通过单点登录验证后获得，包含用户的基本信息，如唯一标识、登录名、票据的有效期等。
票据标识：用户在通过单点登录验证后获得票据的唯一标识。
4 作用
通过单点登录服务让用户在一次输入用户名密码验证登录后，访问所有应用系统而不需要再输入用户名和密码进行验证；
用户在一次注销后，即可在所有应用系统实现注销。
单点登录服务以组织身份模型为数据基础，以组织身份服务为运行支撑。
实现单点登录服务的前提是，各应用系统采用统一的组织身份数据模型。
单点登录服务中的认证及获取用户信息均应调用组织身份服务接口。
5 单点登录服务逻辑
5.1 服务代理
为用户提供单点登录认证，认证成功后为该用户颁发对应的票据。
将票据和票据标识保存在服务器上，同时将票据的标识保存在用户的客户端。
在用户请求注销时，负责通知各应用系统注销该用户。
5.2 访问拦截组件
拦截用户对应用系统的访问请求，根据保存在客户端的用户票据标识，向单点登录代理服务器请求用户的票据，如果正确地得到了用户的票据，则调用应用系统二次认证接口（参见6.4）。
如果二次认证通过，则允许用户访问该应用系统；
如果票据标识不存在或者票据无效，则不允许用户访问该应用系统。
5.3 对应用系统的约束
5.3.1 应用系统二次认证
根据用户的票据标识从单点登录代理服务器中获得用户票据，从票据中获得用户的基本信息，再进行应用系统的本地认证。
5.3.2 应用系统本地注销
用户在入口点注销后，由单点登录服务代理通知各应用系统，在所有的应用系统中注销该用户。
6 接口定义
本接口所处的命名空间为：egov.appservice.sso。
6.1 单点登录认证接口
6.2 获取单点登录票据接口
6.3 单点登录注销接口
6.4 应用系统二次认证接口
6.5 应用系统本地注销接口
6.6 单点登录服务异常规定
第9部分 电子表单服务接口规范
1 范围
本部分定义了电子表单的基本概念，规范了电子表单服务的组成部分、功能以及技术要求，规定了电子表单使用和管理的服务接口，为使用电子表单的应用系统提供统一的、标准的表单服务。
本部分主要用于深圳市各级党政机关的信息系统规划与建设，以及电子政务信息系统建设的系统集成商、软件开发商和监理单位进行信息化规划、建设。
适用于设计与建设电子政务中的电子表单系统，以及使用电子表单服务接口的应用系统。
2 规范性引用文件
下列文件中的条款通过本部分的引用而成为本部分的条款。
凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。
凡是不注日期的引用文件，其最新版本适用于本部分。
GB/Z 19669—2005 XML在电子政务中的应用指南
GB/T 19667.1—2005基于XML的电子公文格式规范第一部分：总则
GB/T 19667.2—2005基于XML的电子公文格式规范第二部分：公文体
GB/T 19488.1—2004电子政务数据元 第一部分：设计和管理规范
SZDB/Z 17.1—2008深圳市电子政务应用服务规范 第1部分：总则
3 术语和定义
资源节点UID（resourceUID）：为方便查询、显示及对表单模板进行权限管理，对具有相同或相似业务功能的表单模板进行分组管理。
所有的资源节点共同构成树形结构，表单模板放在资源节点下。
表单模板（FormTemplate）：定义了表单的基本结构和属性，包括样式、数据项、校验、计算等内容，用来载入表单数据并在权限控制下动态生成表单文档。
表单模板可采用HTML格式、XML格式或者其他格式进行描述，通过标签或控件及相应的属性值进行定义，如一般发文签批单。
表单文档（FormDoc）：是表单模板的应用实例。表单文档是由表单模板和表单数据在权限控制下动态生成的文档，包括含有表单数据静态存储的电子文档，用于为最终用户提供显示、录入、修改的人机界面，如一份发文。
表单数据（FormData）：表单文档中的数据部分，一份表单文档对应于一份表单数据，采用XML格式进行表示。
4 电子表单服务的组成部分
电子表单服务由三部分组成：表单设计器、表单填写器、表单服务器。
表单设计者通过表单设计器在线或者离线设计表单模板（FormTemplate），通过表单服务器上传到服务器端，放入到文档库中的表单模板库。
文档库可以使用数据库、文件系统或其他的存储方式，如果需要采用数据库分离存储表单中的数据，表单设计器则需提供数据映射功能。
表单使用者通过表单填写器调用表单模板进行填写操作，通过表单服务器提交表单数据并保存到表单实例库；
使用者可以通过表单填写器浏览、查找、修改已经填写的表单文档。
5 电子表单服务接口
本接口所处的命名空间为：egov.appservice.form。
5.1 表单模板管理接口
5.1.1 部署表单模板
5.1.2 删除表单模板
5.1.3 更新表单模板
5.1.4 获取表单模板对象
5.1.5 获取表单模板所有版本
5.1.6 查询表单模板
5.1.7 导入表单模板
5.1.8 导出表单模板
5.2 表单文档服务接口
5.2.1 生成表单文档
5.2.2 输出表单文档
5.2.3 提交表单数据
5.2.4 提交表单文档
5.2.5 删除表单文档
5.2.6 查询表单文档
5.2.7 获取表单数据
5.2.8 设置表单数据
5.2.9 异常约定
第10部分 业务流程服务接口
1 范围
本部分定义了业务流程服务的基本概念，规定了流程定义、流程实例和活动实例的基本状态，规范了流程服务提供的服务接口，包括流程模型服务接口、流程实例服务接口、应用调用服务接口、流程互操作服务接口、流程管理服务接口五部分内容，为应用系统提供统一的流程服务。
本部分主要用于深圳市各级党政机关的信息系统规划与建设，以及电子政务信息系统建设的系统集成商、软件开发商和监理单位进行信息化规划、建设。适用于规划与开发业务流程相关的应用系统，采用业务流程进行任务的手工和自动办理，实现应用系统和业务流程之间的互相调用，以及不同业务流程之间的互操作。
2 规范性引用文件
下列文件中的条款通过本部分的引用而成为本部分的条款。
凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。
凡是不注日期的引用文件，其最新版本适用于本部分。GB/T 19487—2004电子政务业务流程设计方法通用规范
SZDB/Z 17.1—2008深圳市电子政务应用服务规范 第1部分：总则
SZDB/Z 17.7—2008深圳市电子政务应用服务规范 第7部分：访问控制服务接口规范
3 术语和定义
资源节点UID（resourceUID）：为方便查询、显示以及权限管理，对具有相同或相似业务功能的流程定义进行资源映射。
一个资源节点对应一个流程定义，资源节点可以递归包含，形成树状结构。对资源节点的操作请参照本规范第7部分中“4.2.2资源管理”。
流程定义版本（version）：用来区分同一个流程定义在不同时间内的不同状态，保存在流程服务器上。
版本的产生由客户端决定，版本号是一个0或正整数，从0开始，以递增1为一个新版本号。
流程定义（ProcessDefinition）：是实现一个业务流转过程的自动化处理模型，包括活动及活动之间关系的网、过程和单独活动（参与者、应用）开始和结束的约定，如发文流程。
流程实例（ProcessInstacnce）：一个流程定义过程单次执行的表示，如一份具体的发文。
活动实例（ActivityInstance）：一个流程定义中活动单次执行的表示。
它属于一个流程实例，在某个时刻，一个流程实例可同时有若干个ActivityInstance，但一个ActivityInstance只能与一个ProcessInstance相关。
工作项（WorkItem）：活动实例对应的工作列表中的项。一个活动实例中有一个以上的工作项，通过工作列表展现给最终用户。
流程实例数据（InstanceVariable）：包含单个流程实例中的所有流程相关数据的集合，如表单数据、意见、正文、附件、签名等。
4 状态定义
4.1 流程定义状态
（1）Edit：编辑状态，不能创建、运行流程实例，已有的流程实例可以被查询。
（2）Debug：调试状态，可以创建、运行流程实例，流程实例可以被查询。但在调试状态，创建和运行的流程实例均带有debug标记，便于以后清除。
（3）Running：正常执行状态，可以创建、运行流程实例，流程实例可以被查询。
（4）Suspended：挂起状态，不能再创建新的流程实例，已有的流程实例可以继续执行。
（5）Freeze：冻结状态，不能创建新的流程实例，已有的流程实例也不能继续执行。
（6）Hide：隐藏状态，不能创建新的流程实例，已有的流程实例不能继续执行，而且隐藏状态下所有的流程实例均不能被查询和显示。
注：√表示可以执行
4.2 流程实例/活动实例状态
（1）open：流程实例是可以执行的。
（2）open.running：流程实例正在执行。
（3）open.notRunning：流程实例暂时不能执行。
（4）open.notRunning.notStarted：流程实例已经创建，但还没有启动。
（5）open.notRunning.suspended：流程实例处于挂起状态。
（6）closed：流程实例正常执行完毕。
（7）closed.aborted：流程实例被用户选择跳过。
（8）closed.terminated：流程实例被用户选择终止。
（9）closed.completed：流程实例正常执行完毕。
流程实例/活动实例状态示意图
5 业务流程服务
5.1 流程服务总体概述
业务流程服务的核心组件是流程服务器，流程服务器可以提供五类服务：流程模型服务、流程实例服务、应用调用服务、流程互操作服务和流程管理服务。
业务流程服务示意图
（1）流程模型服务：是对流程模型的管理服务。流程模型提供对业务流程的形式化描述，通过流程定义工具输入或输出定义好的流程模型，以及图形化展示。
（2）流程实例服务：是操作并控制流程实例、活动实例运行和状态的服务。本类服务访问和操作流程中的实例数据。各应用系统主要使用的是本类服务，包括执行流程的客户端。
（3）应用调用服务：是调用其他应用程序实现任务自动化的服务。本类服务来实现流程服务和各应用系统间的调用，可在流程服务的各环节调用其他应用程序，实现业务流程贯通。
（4）流程互操作服务：是流程服务之间相互通讯和调用的服务。本类服务实现流程服务器之间的协同工作。
（5）流程管理服务：是对流程服务器进行监控、管理的服务。本类服务可以启动、停止流程服务器，获取流程运行的日志信息，导出或迁移流程定义等。
5.2 流程模型服务
流程模型服务是对流程模型的管理服务。
流程模型提供对业务流程的形式化描述，通过流程定义工具输入或输出定义好的流程模型，以及图形化展示。
流程模型服务包括部署、删除、更新、查找、获取流程定义、控制流程定义版本、获取和改变流程定义状态等服务。
5.2.1部署指定流程定义
5.2.2更新指定版本流程定义
5.2.3删除流程定义
5.2.4获取指定流程定义状态
5.2.5改变指定流程定义状态
5.2.6查找指定的流程定义
5.2.7获取最新版本的流程定义
5.2.8获取指定版本的流程定义
5.2.9获取流程定义的所有版本
5.3 流程实例服务
是操作并控制流程实例、活动实例运行和状态的服务。本类服务访问和操作流程中的实例数据。
各应用系统主要使用的是本类服务，包括执行流程的客户端。
包括创建并启动流程实例、删除流程实例、获取及改变流程实例的状态、获取活动列表和改变活动状态、获取工作项列表、改变工作项状态、重新分配工作项等。
5.3.1获取流程实例对象
5.3.2创建流程实例
5.3.3创建流程实例并指定起始节点
5.3.4创建子流程实例
5.3.5删除指定的流程实例
5.3.6获取指定流程实例状态
5.3.7改变指定流程实例状态
5.3.8改变指定流程实例依赖的定义版本
5.3.9查找指定流程实例
5.3.10获取指定的活动实例
5.3.11获取指定活动的后续活动
5.3.12获取指定活动的前驱活动
5.3.13获取指定流程实例的活动实例组
5.3.14获取指定流程实例的子流程实例数组
5.3.15获取指定流程实例的父流程实例
5.3.16获取指定活动实例状态
5.3.17改变指定活动实例状态
5.3.18活动实例回退
5.3.19获取工作列表
5.3.20更新指定的工作项
5.3.21结束指定的工作项
5.3.22获取流程实例数据
5.3.23设置流程实例数据
5.3.24指派活动参与者
5.3.25运行指定的活动实例
5.3.26运行指定路径的活动实例
5.3.27启动流程实例
5.3.28结束流程实例
5.4 应用调用服务
是调用其他应用程序实现任务自动化的服务。
本类服务来实现流程服务和各应用系统间的调用，可在流程服务的各环节调用其他应用程序，实现业务流程贯通。
应用调用服务通常用来调用其他应用程序执行特定的任务，如调用PDF生成程序生成PDF文档、调用打印服务器打印文档
应用调用服务通过“应用代理”组件来完成调用。
应用调用服务必须提供“双向”服务，既可以从流程服务调用应用程序，也可以从应用程序调用流程服务。
应用调用服务同时提供更新数据的功能，包括应用程序更新流程服务数据以及流程服务更新应用程序数据。
5.4.1同步调用应用程序
5.4.2异步调用应用程序
5.4.3获取异步应用程序调用结果
5.4.4获取应用程序状态
5.4.5强制停止应用程序
5.5 流程互操作服务
是流程服务之间相互通讯和调用的服务。本类服务实现流程服务器之间的协同工作。
5.5.1 调用服务
5.5.2 接收数据
5.5.3 答复服务
5.5.4 赋值服务
5.6 流程管理服务
是对流程服务器进行监控、管理的服务。本类服务可以启动、停止流程服务器，获取流程运行的日志信息，导出或迁移流程定义等。
5.6.1 启动流程服务器
5.6.2 停止流程服务器
5.6.3 活动实例跳转
5.6.4 重新指派工作项
5.6.5 获取指定流程实例的历程
5.6.6 导出指定版本的流程定义
5.6.7 导入流程定义
5.6.8 获取指定日志信息
5.7 异常约定
