DB33/T 939-2014 政务通系统建设技术规范
DB33/T 939-2014
基本信息
发布历史
-
2014年09月
文前页预览
研制信息
- 起草单位:
- 起草人:
- 出版信息:
- 页数:50页 | 字数:- | 开本: -
内容描述
ICS35.240.20
L67
DB33
浙江省地方标准
DB33/T939—2014
政务通系统建设技术规范
Technicalspecificationsforconstructionongovernment’s
integratedcommunication
2014-09-25发布2014-10-25实施
浙江省质量技术监督局发布
DB33/T939—2014
目次
前言III
1范围1
2规范性引用文件1
3术语和定义1
4缩略语2
5设计原则2
5.1易用性2
5.2安全可靠性3
5.3先进性3
5.4可维护性3
6组织身份模型3
6.1概述3
6.2组织模型3
6.3数据的描述方法4
6.4基本数据集4
6.5人员登录名命名要求7
7数据传输8
7.1文字数据传输8
7.2文件或图片数据传输8
7.3音视频数据8
8系统功能要求8
8.1系统组成8
8.2多客户端要求8
8.3客户端基本功能要求8
8.4管理端功能10
8.5二次开发和接口11
8.6应交付的技术文档11
9互联互通要求11
9.1技术架构11
9.2互联互通建设要求12
9.3互联互通接口12
10安全要求12
附录A(规范性附录)组织身份模型示例13
I
DB33/T939—2014
附录B(规范性附录)浙江省一级和二级域名规划15
附录C(规范性附录)互联互通协议说明18
II
DB33/T939—2014
前言
本标准依据GB/T1.1-2009给出的规则起草。
本标准由浙江省政府办公厅提出并归口。
本标准起草单位:浙江省政府办公厅电子政务处、浙江省电子政务学会、浙江省行政首脑机关信息
中心、杭州市人民政府电子政务办公室、浙江医学高等专科学校、浙江省交通信息中心、浙江省质量技
术监督信息中心、杭州易和互联软件技术有限公司。
本标准主要起草人:金加和、徐颖、辛均益、黄锐、陈立三、陈仲永、柴琳、王冬茜、胡瑞玉、蒋
伟杰、周旭光。
III
DB33/T939—2014
政务通系统建设技术规范
1范围
本标准规定了政务通系统建设的设计原则、组织身份模型、数据传输、系统功能、互联互通和安全
要求。
本标准适用于全省各级政府机关政务通系统建设。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅所注日期的版本适用于本文
件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
GB/T2260中华人民共和国行政区划代码
GB/T9387.2信息处理系统开放系统互连基本参考模型第2部分:安全体系结构
GB/T14946.1全国干部、人事管理信息系统指标体系分类与代码
GB/T15278信息处理数据加密物理层互操作性要求
GB/T16987组织机构代码信息数据库(基本库)数据格式
GB/T20988信息系统灾难恢复规范
ISO/IEC7498-1信息技术开放系统互连基本参考模型第1部分:基本模型
ISO/IEC10181-3信息技术开放系统互连开放系统安全框架第3部分:访问控制框架
RFC3489简单的用UDP穿透NAT协议
RFC5766中继方式穿越NAT:STUN的扩展
RFC6120可扩展消息传递协议
3术语和定义
下列术语和定义适用于本标准。
3.1
政务通
以统一身份管理与认证、统一通信技术、统一管理后台为支撑,集成各类应用系统,为政府和公众
用户提供基于PC、移动客户端沟通和政务资源共享等服务的平台。
3.2
统一用户
建立集中的用户数据库,实现用户信息的统一存储、管理和分发,并作为其它应用系统集中认证的
认证源。数据主要包括用户基本信息、组织架构信息、角色信息、权限信息等。
3.3
1
DB33/T939—2014
统一认证
为各类应用系统提供用户身份认证服务,认证介质支持用户名密码、数字证书等。
3.4
单点登录
当用户访问多个应用系统时,只需提交一次认证信息就可访问授权的应用。
3.5
统一通信
把计算机技术与传统通信技术融为一体的通信模式,让人们无论任何时间、任何地点,都可通过任
何设备、任何网络,获得数据、图像和声音的自由通信。主要包括即时通信、短信、文件传输、语音视
频、电话等多种通信方式。
3.6
登录名
用户登录政务通和其它应用系统的唯一账号。
3.7
互联互通
在网络环境可互通的情况下,各级单位独立建设的政务通系统之间,通过通信和数据交换技术,实
现组织架构、在线状态、即时消息、文件传输、音视频、群等功能的互联互通。
4缩略语
下列缩略语适用于本标准。
ICE:交互式连通建立方式(InteractiveConnectivityEstablishment)
NAT:网络地址转换(NetworkAddressTranslation)
RFC:征求评议文件(RequestForComments)
SSL/TLS:安全套接层/传输层安全((SecureSocketsLayer/TransportLayerSecurity)
STUN:简单的用UDP穿透NAT(SimpleTraversalofUserDatagramProtocolThroughNetwork
AddressTranslators)
TCP:传输控制协议(TransmissionControlProtocol)
TURN:中继方式穿越NAT:STUN的扩展(TraversalUsingRelaysaroundNAT:RelayExtensionsto
SessionTraversalUtilitiesforNAT)
UDP:用户数据报协议(UserDatagramProtocol)
5设计原则
5.1易用性
易用性方面应符合以下要求:
a)政务通客户端响应时间应在3秒之内,当耗用较长的时间时应有明确提示并宜有进度显示;
b)当不同的方式能够达到相同或相似效果时,应选取令客户访问或使用更简单快捷的方式;
2
DB33/T939—2014
c)主要功能应处于突出的位置,常用的功能应处于容易操作的位置;
d)每个功能应有清晰的流程,各个步骤需要的条件、产生的结果、操作人员以及实现方式等都应
清晰无误;
e)实现功能服务的程序应是正确的、健壮的;
f)用户操作的每一个步骤(无论正确与否)完成后应被提示当前状态;
g)界面设计应充分考虑用户体验,要友好清晰、操作简单。
5.2安全可靠性
安全可靠性方面应符合以下要求:
a)应采用稳定可靠的成熟技术,保证系统长期安全运行;
b)系统中的硬、软件及信息资源应满足可靠性设计要求;
c)系统消息支持SSL/TLS传输;
d)系统具有容错能力,管理、维护方便;
e)对网络的设计、选型、安装、调试等各环节进行统一规划和分析,确保系统运行可靠;
f)提供多层次安全控制手段,建立完善的安全管理体系,确保数据的安全性、完整性,有可靠的
防病毒措施;
g)应能满足当地的环境、气候条件,抗干扰能力强。
5.3先进性
先进性方面应符合以下要求:
a)政务通性能取决于服务器接入方式和接入带宽、摆放地点、软硬件性能和用户在线数量、网络
拥塞程度等多方面因素。如果目标群体不止本地,则还应考虑地理因素造成的性能下降;
b)当两个客户端进行文件、音频、视频等大数据传输时,优先使用点对点方式传输,点对点不通
时,才采用服务器中转方式;
c)客户端点击响应速度,正常情况下,平均响应时间在3秒以内,如有超过则应有响应的提示;
d)服务端并发用户数,根据省市县各级行政单位的人员规模分级制定。
5.4可维护性
可维护性应符合以下要求:
a)系统设计应采用开发技术、开放结构、开放系统组件和开放用户接口,以利于网络的维护、扩
展升级及外界信息的沟通,并符合ISO/IEC7498-1的要求;
b)网络规划设计既要满足用户发展在配置上的预留,又能满足因技术发展需要而实现低成本扩展
和升级的需求。应充分考虑到联网用户增加和业务扩展的情况,留有必要的扩充能力及接口。
6组织身份模型
6.1概述
对浙江省电子政务系统中涉及的部门、人员等实体进行抽象,根据抽象定义建立浙江省电子政务系
统的一个基础数据模型。
组织架构示意图见本标准附录A。
6.2组织模型
3
DB33/T939—2014
6.2.1部门
根据行政职能划分而实际存在的实体部门的抽象,部门分为两类,一是有独立法人的机构,即政府
组成部门,二是独立机构的内设部门。
示例:浙江省财政厅为政府组成部门,浙江省财政厅行政政法处为内设部门。
6.2.2人员
部门内的实体人员。
示例:张三。
6.2.3模型关系
部门和人员的关系:多对多的关系。一个部门可包含多个人员,一个人员可属于多个部门。
6.3数据的描述方法
6.3.1中文名称
实体的中文名称属性。
6.3.2英文名称
实体的英文名称属性。
6.3.3约束
实体属性应遵守的一些强制性规则,如不可取空值等。
6.3.4数据类型
实体的数据类型属性,如整型、实型、布尔型、字符型、日期型等。
6.3.5值域
实体可取值的范围。
6.3.6备注
实体的进一步解释和举例。
6.4基本数据集
6.4.1部门
根据行政划分而实际存在的实体部门的抽象。部门基本数据集见表1。
示例:浙江省财政厅。
4
DB33/T939—2014
表1部门基本数据集
中文名称英文名称约束数据类型值域(字节)备注
非空唯部门的唯一ID号,32位无意义
部门标识deptid字符型32
一字符串。
上级部门Parentdelpid可为空字符型32部门的上级部门ID。
部门名称deptname非空字符型≤255如浙江省财政厅。
部门英文名字deptenname可为空字符型≤255部门英文名字。
如浙江省工商行政管理局简称
部门简称deptaliasname可为空字符型≤255
浙江省工商局。
表示一个部门的行政级别,符合
部门级别代码deptgradecode可为空字符型2
GB/T14946.1的规定。
表示一个部门的类型,符合
部门类型depttype可为空字符型10
GB/T16987的规定。
成立日期establishDate可为空日期型17
表示一个部门的行政区域代码,
行政区域代码divisionsCode非空字符型≤10
符合GB/T2260的规定。
取值一个实际存在的人员实体
部门主管deptManager可为空字符型32
对象的人员标识ID。
部门楼牌号deptOffice可为空字符型≤255
邮政编码postcode可为空字符型6
电话号码phone可为空字符型≤30
传真号码fax可为空字符型≤30
电子邮件email可为空字符型≤255
状态0:正常。
state非空整形正整数
1:逻辑删除。
描述description可为空字符型≤1000
版本号version非空整型正整数
6.4.2人员
部门内的实体人员。人员基本数据集见表2。
示例:张三。
5
DB33/T939—2014
表2人员基本数据集
定义英文名称约束数据类型值域(字节)描述
userid32人员唯一ID,32位无意义字
人员标识非空唯一字符型
符串。
姓名username非空字符型≤255人员的真实姓名。
登录名loginname非空唯一字符型≤255
密码loginpwd非空字符型≤255
密码加密类型loginpwdtype非空字符型1
性别sex非空字符型1
出生日期birthday可为空日期型17
默认值为0。
值:0.身份证;1.护照;2.
证件类型idtype可为空字符型1
户口簿;3.军官证;4.士兵
证;5.驾驶证。
证件号码idnum可为空字符型≤18对应证件类型的证件号码。
职务userposition可为空字符型≤255
职称usertitle可为空字符型≤255
国籍country可为空字符型≤255
省籍province可为空字符型≤255
城市city可为空字符型≤255
办公地址officeaddress可为空字符型≤255
邮编postcode可为空字符型6
常用电话telephone可为空字符型≤13
备用电话telephone2可为空字符型≤13
常用手机mobile可为空字符型≤11
手机短号mobilecornet可为空字符型≤11
备用手机mobile2可为空字符型≤11
办公传真officefax可为空字符型≤255
邮件email可为空字符型≤255
CA证书KEYcakey可为空字符型≤255
6
DB33/T939—2014
表2人员基本数据集(续)
定义英文名称约束数据类型值域(字节)描述
家庭电话homephone可为空字符型≤255
家庭地址homeaddress可为空字符型≤255
默认值为1。
是否在编official非空字符型1
值:1.在编;2.不在编。
表示人员的编制类别,如行
编制类别officialtype非空字符型≤255
政编制。
0:正常。
状态state非空整型正整数
1:逻辑删除。
版本号version非空整型正整数
6.4.3部门人员关联表
部门人员关联表见表3。
表3部门人员关联表
定义英文名称约束数据类型值域(字节)描述
部门标识Deptid非空字符型32
人员标识userid非空字符型32
6.5人员登录名命名要求
人员登录名应唯一,由该人员姓的拼音、名的拼音首字母、分隔符“.”(下脚点,不包括双引号)、
二级域名(见本标准附录B)组成。当一个人员属于多个单位时,该人员的域名取所属主单位的域名。
如登录名重名,可用人员姓名拼音;如拼音重名,可在登录名后添加阿拉伯数字区分。
登录名的组成见图1。
图1登录名的组成
示例1:浙江省政府办公厅秘书处工作人员张三,因省政府办公厅的二级域名为bgt.zj,按本标准该人员的登录名
为zhangs.bgt.zj。
7
DB33/T939—2014
示例2:浙江省发改委办公室下工作人员张三,因省发改委的二级域名为fgw.zj,按本标准该用户的登录名为
zhangs.fgw.zj。
示例3:杭州市政府办公厅秘书处工作人员张三,因杭州市政府办公厅的二级域名为bgt.hz,按本标准该人员的登
录名为zhangs.bgt.hz。
示例4:温州乐清市办公室秘书科工作人员张三,因温州乐清市办公室的三级域名为bgs.yq.wz,按本标准该人员的
登录名为zhangs.bgs.yq.wz。
7数据传输
7.1文字数据传输
文字数据基于TCP协议,通过服务器中转传输,支持SSL/TLS安全通道。传输的文字数据最大不超过
1M(约50万汉字)。
7.2文件或图片数据传输
文件和图片数据基于UDP协议,通过ICE技术选择最合适的网络传输方式实现数据传输。单个文件或
图片大小不超过4GB,支持断点续传,支持SSL、TLS安全通道。
7.3音视频数据
音频数据采用GIPS的iLIBC/iSAC/G722/PCM16/RED/AVT编解码技术,视频采用I420/VP8编解码技术,
基于RTP/RTCP协议,通过ICE技术选择最合适的网络传输方式实现数据传输,支持SSL、TLS安全通道。
8系统功能要求
8.1系统组成
政务通由以下几部分组成:
a)支撑平台:构建统一通信系统,融合即时通信、短信、文件传输、音视频等多种互联网通信技
术。构建基础性的统一身份管理与认证系统,为已经建设或新建的应用系统提供统一的用户管
理、身份认证服务、统一的访问控制、统一的后台管理;
b)集成应用系统:通过支撑平台,与政府各类政务和业务等应用系统集成。
c)客户端:构建PC、移动客户端,实现统一的信息门户;集成OA、邮件等各类应用系统,实现
单点登录、消息提醒,通信融合。
8.2多客户端要求
8.2.1PC客户端
支持Windows、Mac、Linux等PC操作系统。
8.2.2移动客户端
支持IOS、Android、WindonsPhone等移动操作系统。
8.3客户端基本功能要求
8.3.1互联互通
8
DB33/T939—2014
不同政务通系统客户端应可互相展现对方组织机构通信录,实时感知对方状态,能互相加为好友,
互相用即时消息、文件传输、音视频沟通。
8.3.2智能更新
客户端更新应支持强制更新,静默更新及提醒更新三种模式。
8.3.3用户登录
应支持登录名密码方式登录,加密保存登录信息,以方便下次登录。应支持数字证书,可直接证书
登录。应支持开机自动登录。客户端由于网络问题掉线,当网络恢复后支持自动重连登录。
8.3.4私聊和群聊
私聊应有类似于QQ的好友点对点聊天功能,可以通过组织通讯录、常用联系人跟其他人员进行点对
点聊天,同时应支持发起文件传输、截图、音视频、电话呼叫和会话。
群聊应有类似与QQ的群组聊天功能,支持文件共享。
8.3.5文件传输
应有文件传输功能,为节约服务器网络带宽,点对点文件传输应优先考虑P2P直传,P2P直传不通,
再进行服务器中转传输。
8.3.6短信
应有短信收发功能,实现计算机到手机,手机到计算机的短信互发。当手机回复短信给客户端时,
如果该客户端离线,提供短信发送到该客户端绑定手机功能,应同时支持与移动、电信、联通等不同运
行商的短信通讯网关。
8.3.7电话
应可接入电信、移动、联通等语音网关,实现电话一号通功能。
8.3.8历史消息
应有即时消息、短信、文件传输、群组和音视频等历史记录功能,为方便历史消息的浏览,需提供
分组和按时间排序的功能,并能导出备份和打印。
8.3.9组织通讯录
在客户端应可清晰看到多层次组织架构,是实时更新的电子通讯录。组织通讯录支持人员状态感知;
提供多种查询方式;支持从通讯录发起电话、即时消息、文件传输、短信、音视频。经常联系人员可加
入到常用联系人,方便下次联系。
8.3.10常用联系人
对经常联系的人员,应可加入常用联系人,支持人员状态感知,可对人员进行分组,支持从常用联
系人发起电话、即时消息、文件传输、短信、音视频。
8.3.11名片夹
应可对个人名片夹进行管理,并对人员进行分组,发短信,拨打电话,支持名片夹的导入导出。
9
DB33/T939—2014
8.3.12快速搜索栏
应有快捷搜索功能,可对组织通讯录、常用联系人和电话簿人员按用户姓名中文、拼音和拼音缩写
进行模糊查找。
8.3.13快捷图标和消息提醒
应可在客户端显示有管理后台自定义增加的标签页面。可在客户端托盘实现各类应用系统的消息提
醒,如新邮件提醒、OA待办件提醒等。
8.3.14通知
应支持对组织通讯录和常用联系人群发消息通知功能,并支持附件,支持对通知的转发和回复,可
统计收件人阅读通知数。
8.3.15微门户
应提供个人工作门户功能,支持单点登录第三方应用,支持邮件、通知、OA和其他应用系统的待办
件提醒。
8.3.16日程
应提供个人日程安排功能,可实现即时消息和短信日程提醒。
8.4管理端功能
8.4.1人员和组织管理
应提供对人员和组织增、删、修改等操作,要求对各个单位、部门、分支结构、直属机构都可以进
行多级管理,并能方便、灵活实现部门组织机构的重组、改名、撤消、人员变动等应用操作。
8.4.2统一认证
应支持统一的用户身份认证及管理服务,认证服务是用户访问的统一认证入口。
8.4.3单点登录
应在统一认证服务基础上,实现单点登录第三方应用功能。
8.4.4角色管理
应支持对角色管理和授权,一个角色可对多个用户授权。
8.4.5权限管理
通过权限定义,应实现权限与功能操作的关联,支持管理员可把权限分配给角色、组织、用户。
8.4.6即时消息管理
应支持对群、消息、文件、音视频等的管理功能。
8.4.7短信管理
应支持对常用短信、计费策略、手机优先级、短信发送队列表等短信相关功能管理功能。
10
DB33/T939—2014
8.4.8资源管理
应支持在客户端展现的快捷图标和消息提醒第三方接入应用系统进行管理。
8.4.9日志管理
整个系统的操作应有详细的日志记录,比如后台操作日志,客户端登录登出日志,接口调用日志,
消息包监测日志等。
8.4.10统计分析
提供完善的统计分析功能,应包括对组织、用户、收发消息、资源点击率等多维度的统计分析。
8.5二次开发和接口
8.5.1统一用户
以政务通系统人员数据为基础,可实现和各类系统人员个人资料的统一,包括姓名、登录名和密码
等。
8.5.2单点登录
在统一用户的基础上,应可通过政务通客户端单点登录各应用系统。
8.5.3消息提醒和信息门户
通过政务通数据交换接口,可把各类应用的最新信息在政务通客户端展现,实现微门户和消息提醒
功能。
8.5.4通信服务
各类应用系统可调用政务通服务接口,收发即时消息和短信;可调用客户端接口,发起即时消息、
短信、拨打电话、发送文件、音视频等操作。
8.6应交付的技术文档
系统建设完成后,应提供以下技术文档:
a)需求分析说明书;
b)概要设计说明书;
c)详细设计说明书;
d)测试报告;
e)操作使用说明书;
f)系统维护手册;
g)应急处理手册。
9互联互通要求
9.1技术架构
两个不同政务通系统之间的互联互通,主要是通过TCP和UDP套接字接入“互联互通中心”实现,架
构图如图2所示:
11
DB33/T939—2014
政
通道管理路由寻址消息收发消息加解密消息编解码
务
通
通信服务接口
A
TCP/UDP
互联
认证服务路由寻址消息收发通道管理
互通
中心
TCP/UDP
政通信服务接口
务
通通道管理路由寻址消息收发消息加解密消息编解码
B
图2互联互通架构示意图
9.2互联互通建设要求
为促进政务通的使用和推广,建立浙江全省政府组织机构通讯录,在网络环境可互通的情况下,要
求全省各级政府机关建设的不同政务通可展现对方的组织机构通信录,实时感知对方状态,互相加为常
用联系人,可加入同一个群组,实现即时消息、文件传输、音视频等多种方式沟通。
9.3互联互通接口
互联互通接口见本标准附录C。
10安全要求
应符合ISO/IEC10181-3、GB/T9387.2、GB/T15278、GB/T20988等标准的要求。
12
DB33/T939—2014
AA
附录A
(规范性附录)
组织身份模型示例
组织架构的根节点为“浙江省政府”,在根节点下,设立“省政府办公厅”、“省级部门”和“市、
县(市、区)”三个子节点;在子节点下,按照政府机构的组成与排序展示组织身份,图A.1给出了组
织模型中实体关系的示例。
13
DB33/T939—2014
图A.1组织架构示意图
14
DB33/T939—2014
BB
附录B
(规范性附录)
浙江省一级和二级域名规划
B.1浙江省一级和二级域名规划
B.1.1概述
对省级部门,市、县(市、区)政府部门的域名进行了规划,该域名作为用户登录名的组成部分,
主要用于解决不同部门用户的登录名重名问题。
B.1.2一级域名规划表
一级域名规划表见表B.1。
表B.1一级域名规划表
地市名称域名简称地市名称域名简称
省级zj杭州hz
宁波nb温州wz
嘉兴jx湖州huz
绍兴sx金华jh
推荐标准
- DB62/T 25-3045-2009 大空间智能型主动喷水灭火系统设计规程 2009-10-20
- DB15/T 467-2010 民族工艺品 皮革画制品 2010-03-31
- DB15/T 470-2010 膨润土防水毯衬砌渠道工程技术规程 2010-03-31
- DB62/T 1941-2010 兰州市农产品 富硒葡萄 2010-04-09
- DB15/T 469-2010 固化土衬砌渠道工程技术规程 2010-03-31
- DB62/T 25-3043-2009 砖砌体结构抗震设计规程 2009-10-20
- DB62/T 1940-2010 兰州市农产品 富硒高原夏菜 2010-04-09
- DB62/T 1939-2010 兰州市农产品 富硒白兰瓜 2010-04-09
- DB62/T 1942-2010 兰州市农产品 富硒苦水玫瑰 2010-04-09
- DB62/T 25-3041-2009 钢管混凝土结构技术规程 2009-03-03