办公集成系统解决方案

XXX市

办公集成系

统建设方案

目录

第一章项目概述5

1.1建设背景5

1.2建设目标5

1.3建设原则7

13.1高点规划，适度超前7

13.2顶层设计，统筹统建7

1.3.3机制创新，技术领先7

1.3.4整合资源，协同共享8

1.3.5安全可靠，自主可控8

第二章总体设计8

2.1平台总体框架8

2.1.1管理架构8

2.1.2业务架构9

2.1.3系统架构10

2.2主要参考标准13

2.2.1技术架构13

2.2.2性能需求13

2.2.3非功能性需求15

2.2.4关键技术应用16

2.3数据安全设计32

2.3.1基于消息的安全数据交换设计32

2.3.2备份与恢复方案41

2.4非功能性设计43

2.4.1系统可靠性设计43

2.4.2系统可扩张性设计44

2.4.3系统易用性设计44

2.4.4系统可用性设计44

2.4.5系统可维护性设计45

2.4.6系统可管理性没计45

2.4.7系统安全性设计46

第三章建设内容46

3.1统一工作门户46

3.1.1登录入口46

3.1.2通用门户46

3.1.3工作门户48

3.1.4个人中心50

3.1.5委托授权50

3.1.6日程管理52

3.1.7通讯录管理52

3.1.8全文检索54

3.1.9系统管理56

3.2移动政务APP86

3.2.1登录认证87

3.2.2信息中心87

3.2.3待办事宜处理88

3.2.4流程中心88

3.2.5通讯录88

3.2.6公共文档89

3.2.7日程管理89

3.2.8会议管理89

3.2.9手写签批89

3.2.10地理定位90

3.2.11维护配置90

3.3即时通讯系统91

3.4公文管理系统92

3.4.1发文管理94

3.4.2收文管理104

3.4.3公文数据交换111

3.4.4签报管理115

3.4.5提议案管理117

3.5会议管理系统118

3.5.1会议中心119

3.5.2会议室管理119

3.6综合事务管理系统119

3.6.1人员外出管理119

3.6.2考勤管理123

3.6.3车辆管理126

3.7文档管理系统127

3.7.1文档登记127

3.7.2文档查看128

3.7.3文档借阅128

3.7.4文档管理类型维护128

3.7.5文档资料属性维护128

3.8信息采编系统129

3.8.1信息报送129

3.8.2信息处理130

3.8.3发布审批131

3.8.4刊型配置132

3.9重点工作督办系统133

3.9.1督办立项133

3.9.2督办任下达133

3.9.3督办任务办理133

3.9.4督办催办134

3.9.5任务变更申请134

3.9.6督办考评134

3.9.7督办分析报表134

3.9.8集成对接135

3.10应用支撑引擎135

3.10.1权限引擎136

3.10.2门户引擎137

3.10.3流程引擎137

3.10.4报表引擎138

3.10.5内容引擎139

3.10.6集成引擎139

3.10.7建模引擎140

第四章保障体系设计141

4.1标准规范体系141

4.1.1标准建设依据141

4.1.2标准建设内容143

4.1.3标准规范工作任务144

4.2安全信任体系145

4.2.1物理安全145

4.2.2网络安全146

4.2.3系统安全146

4.2.4应用安全和信息安全146

4.2.5安全管理147

第五章运维服务147

5.1服务形式及响应147

5.2服务内容148

第一章项目概述

1.1建设背景

2016年以来，XXX市行政办公系统信息化不强、手段落后，与重

大项目管理、全国信用信息共享平台、门户网站等对接不畅，信息发

布、数据更新不及时，服务效率不高，严重影响单位信息化建设；全

市重点项目从100个，发展到2019年的285个，增长近2倍，项目

调度主要采用电话、Excel.邮件、QQ群等传统方式，项目数据多、

制表繁琐、工作量大、效率不高。

为了改善机关办公信息化，按照“高水平、可持续、重实用”的

总体要求，不断强化内部资源整合和信息共享，需要建设标准统一、

结构合理、功能完善、安全稳定的办公系统；为了加强与全国投资项

目在线审批监管平台、国家重大建设项目库等系统进行数据对接，及

时了解和掌握全市重大项目的实施进展情况，跟踪解决问题，提升我

市重大项目服务监管水平和决策支撑能力，需要建设全方位监测重大

项目储备和实施，分析各项数据，服务全市的重大项目库系统。

1.2建设目标

L互联网门户网站。及时、高效、准确、主动公开我委相关信息,

便于社会公众咨询了解相关政策法规和工作动态；设置重大项目库和

全国信用信息共享平台（四川XXX）等系统入口，方便相关单位或个

人登录使用。

2.内网门户网站。及时发布全委相关工作动态、任务落实、会议

通知等信息，构建资料中心，加强内部交流，实现资料下载、通用查

询等功能。

3.无纸化工作平台。着眼长远，确保软件对国产化操作系统的兼

容性和适应性，覆盖我委公文处理、短信平台、资料中心、工作门户、

通知公告等办公业务，为工作人员提供统一规范的内部综合办公平

台，实现办公业务运行流转的无纸化管理。建设移动办公系统，实现

手机、平板电脑等移动端随时随地安全移动办公，提高办文、办事效

率。

4.信息对接。实现工作平台与互联网、内网门户网站、重大项目

库和全国信用信息共享平台（四川XXX）等系统无缝对接，及时、高

效交换相关数据，实现信息共享。

本次项目建设旨在构建一个整体联动、业务协同、一网办理的协

同办公体系，实现政府及各单位内部办公管理的标准化、协作化、精

准化、平台化、简便化。借助信息化手段落地领导管理思想，实现内

部流程显著优化，管理形式更加多元，服务渠道更%畅通，群众办事

满意度显著提升。

通过建设协同管理云平台打造应用共享中心，整合各类政务应

用系统，形成全市办公的统一入口。让公务人员无需在各个业务系统

间切换，通过电脑端个人工作桌面或手机APP,统一在协同管理云平

台上处理日常工作，逐步形成全市协同办公的“一张网”。

实现政务数据资源共享，推动各类办公业务相互衔接，协同联动,

信息互认，变“办事跑腿”为“信息跑路”，变”人员来回跑”为“业

务协同办”，持续提升政务办公的整体水平和效能。进而达到管理合

理、效率最高、服务最优的目标。最终形成科学合理、精干高效的现

代化数字政务协同办公体系。

1.3建设原则

按照“高标准、高水准”和“服务政府、方便群众”的建设目标,

XXX市办公集成系统项目建设应贯彻以下原则：

131高点规划，适度超前

在充分吸收、借鉴同类项目经验的基础上，高起点规划，业务、

技术等方面适度超前设计，体现技术创新、业务改革和服务创新，建

设一个合理化、标准化、精准化、产品化、平台化、协作化的电子政

务管理平台。

132顶层设计，统筹统建

遵循国家统一的业务技术标准和规范，加强统筹规划，科学设计

云平台架构，将各级各部门“办文、办会、办事”运行数据逐级接入,

实现“一张网”联动运行。

133机制创新，技术领先

立足当地的政务云中心和各类业务应用系统的建设成果，对各个

应用系统进行升级、改造，拓展新的应用和服务，创新运行机制，突

出自主创新，建设功能完备、技术领先的协同管理云平台。

134整合资源，协同共享

大力推进信息技术与政务业务相融合，坚持应用系统建设平台化

和信息资源使用开放化，打破区域限制、条块约束和部门壁垒，整合

利用各级各部门已有信息化资源，实现数据的汇聚和共享，最大程度

利企便民。

135安全可靠，自主可控

严格执行国家、省、市有关信息安全、保密等方面的标准规范和

管理规定，提高信息系统安全保障和高效运行能力。平台应完全适配

国产主流基础软硬件，并具备各种组合国产环境适配调优能力

第二章总体设计

2.1平台总体框架

2.1.1管理架构

构建“统一领导、上下衔接、运作高效、统筹有力、整体推进”

的一体化协同管理云平台的建设组织管理体系。实现业务办理下沉，

变“人跑腿”为“网上办工

覆盖多级一体的协同管理云平台

云端部署SEE_个平台

0多级一体■■■统一门户

管运分离统一应用

■数据关联文档材料

:全面监管一库管理

深度挖掘互认共享

2.1.2业务架构

以政府公务中“办文、办会、办事”的业务特性，精密围绕“融

合、共享、督办”为核心，构建一套科学、稳定、可持续的业务架构。

办文

文件

会场

办事办会

决定、纪要

公报、存档

突破传统的垂直运作、单部门内循环模式，以数据整合、应用集

成为目标，以用户为中心,以管理业务的协同为主线，以数据共享交

换为核心，构建“纵向到底、横向到边”的整体型“数字政府”业务

体系，聚焦各地各部门的管理业务，不断推动创新和改革。

2.1.3系统架构

按照“平台+应用+数据”的建设模式，在互联网+政务的时代背

景下，基于云计算、大数据、智能语音、移动互联等新一代信息技术,

构建“安全可控、自主可靠”的应用支撑平台。

XXX市办公集成系统总体架构全面贯彻国家电子政务总体框架，

满足国家相关标准和规范，可以概括为“123体系”暨：一个平台、

两个标准、三层架构。

XXX市办公集成系统的总体架构如下:

数字政务协同管理云平台总体框架

移动APP端PC电脑端|微信集成设备集成

统一信息门户

业务应用门户~||信息服务市

应

用

层

安

标

全

准

与

与

保

规

支组织权限流I呈引擎门户引擎应用中心用点登录

障

范

撑内容引擎移动引擎建模引擎云商店接口开发

体

体

引

应用支撑层开发服务层

系

系

擎

层|集成中心|口福维中心||日志中司|系统安全语宫中心CA认证

云平台支撑层

数

据

资

源

层

2.L3.1一个平台

一个XXX市办公集成系统，将各级公务事项纳入平台运行，作为

公务应用的唯一入口和出口，陆续纳入其他应用。

2.1.3.2两个体系

安全保障体系和标准规范体系是贯穿平台的两大体系，从系统运

行、安全管理、标准体系建设等方面为云平台保驾护航。

1、安全保障体系

建立统一的安全保障体系，从物理环境、网络、系统、信息和管

理等方面保证平台整体安全；以应用与实效为主导，管理与技术并重,

建立综合防范机制，保障云平台安全、高效、可靠的运行。

市协同管理云平台应根据业务需求和安全要求，合理划分安全

域，科学制定安全访问控制和边界控制策略，确保平台信息安全。

2、标准规范体系

标准规范体系主要包含了协同管理云平台标准服务接口以及平

台技术标准和管理规章制度等内容。

2.1.3.3三层架构

三层架构分别是应用层、支撑引擎层以及数据资源层。

应用层围绕“办文、办会、办事”的构建核心业务办理，同时构

建督查督办、绩效管理等各类管理业务的应用。

支撑引擎层提供平台的基础管理功能，为资源管理、应用管理提

供技术支撑，为新应用的创建提供基础服务组件。通过统一的权限、

门户、流程、报表、内容、集成以及建模等基础引擎，构建平台应用

支撑体系。

数据资源层汇聚整合了平台内的所有数据，让数据分类管理以及

检索分析。同时通过共享交换建设，与异构系统数据互联互通，有效

提升政务管理的质量和效率。

2.2主要参考标准

221技术架构

1、基于J2EE标准进行开发，采取数据集中的系统结构，由市人

民政府信息科服务器统一进行数据存储与管理，整体系统为B/S架

构，采用客户端浏览器一Web应用服务器一数据库服务器三层结构。

2、系统应具有良好的可移植性，在不同的操作平台均可以平滑

运行。

3、系统应具有良好的适应性和扩展性，系统架构采用平台+部件

方式进行搭建，以适应未来政府管理业务的扩展的需要。

4、系统需要提供统一灵活的报表生成工具，在定制标准报表的

基础上，满足个性化报表的需求。报表控件与表单使用的控件相同。

222性能需求

1、性能

吞吐量（全区每月交易量、数据量、高峰期每日交易量、数据量）

在保证性能的前提下，系统设计能够满足未来五年的高峰量。

2、先进性

系统设计合理、架构科学，具有一定的技术先进性、具有高度的

适应性和灵活性。在符合政府信息科技术要求的前提下，系统开发、

引入的技术构件等采用目前主流产品和成熟的技术，综合利用水平上

具有先进性。即在充分考虑上述要求的同时，尽量采用技术成熟、市

场占有率高、性能价格比高的产品，从而保证建成系统具有良好的稳

定性、可扩展性和安全性。

3、实用性

在满足业务功能需求的前提下，要适应业务角色特点，做到系统

界面简洁、友好，使用简单、实用、人性化。用户在登录、访问、下

载信息时，速度快，质量高。同时，接受访问的用户容量大，可扩展

性好，系统并发响应能力强，查询速度快，减少用户等待时间。

4、可靠性

系统设计中，应有适量冗余及其他保护措施，有完善的数据备份

和灾难恢复功能，能应对复杂网络环境对数据完整性破坏，避免垃圾

数据的产生。具有适当的容错机制，有效保证各项业务的正常运做，

保证系统7*24不间断的运行。系统能完备记录数据变化信息，保证

信息的完整性、一致性、真实性、可追溯性。

在满足业务功能需求的前提下，系统应保证在正常情况下和极端

情况下业务逻辑的正确性，保证信息的完整性、一致性。因为系统运

行环境复杂，必须提供强大的容错机制，才能保证系统应对各种环境

对数据完整性的破坏，避免垃圾数据和冗余数据的产生。

5、技术开放性

在系统架构、采用技术、选用平台等方面必须要有较好的开放性。

特别是在选择产品上，要符合开放性的要求，遵循国际标准化组织的

技术标准，对选定的产品既有自己的独特优势，又能与其他产品进行

组合，共同构成一个开放、易扩充、稳定、统一的系统。

6、可维护性

系统设计、开发、测试等过程应严格按照业界的标准进行，产品

文档齐全、规范，系统按照分层设计，软件构件化实现。软件构件化

开发要满足：系统结构分层、业务与实现分离、逻辑与数据分离、使

用开放技术标准。

223非功能性需求

1、开放性

系统设计、开发、测试等过程应严格按照业界的标准进行，产品

文档齐全、规范，系统按照分层设计，软件构件化实现。软件构件化

开发要满足：系统结构分层、业务与实现分离、逻辑与数据分离、使

用开放技术标准。

2、可扩展性

系统建设是一个分阶段、循序渐进、不断升级扩展的过程，系统

要适应对政府业务管理的要求，在设计上必须具有适应业务变化的能

力，如系统用户数量及业务量的增长、规则或代码的变化、业务单据

的变更、业务流程重组等，应尽可能地保证业务变化造成的影响局部

化。采用模块化、组件化和松耦合系统设计方法进行开发。

3、安全性

根据系统数据的存放和传输方式的变化系统建立安全、便捷、高

效的数据加密、校验机制，从而保障数据存储和传输的安全、完整、

及时。系统预留增加CA安全认证的技术接口，按照本项目的有关要

求，适时增加CA认证机制。

4、高性能

系统在满足了业务应用的功能需求的基础上，还在性能方面进行

了大量针对性的测试和优化，消除了许多性能瓶颈，大大提高了承载

能力，在大用户量集中访问的情况下依然能够运行顺畅，必要时，还

可以通过服务器集群的方式进一步扩展承载能力。这种强大的承载能

力对于一些大规模应用是非常有价值的。

224关键技术应用

2.2.4.1面向服务的分布式系统架构技术

适用于创建服务器应用程序和服务J2EE(Java2EntERPrise

Edition)是一种利用Java平台来简化诸多与多级政府部门解决方案

的开发、部署和管理相关的复杂问题的体系结构。J2EE技术还为这

些组件提供一整套政府部门服务，通过自动化的方式完成应用程序开

发中的诸多耗时且费力的艰难工作，为用户提供一种可创建广泛兼容

的政府部门解决方案而无需进行复杂编程的平台。利用这一优势可以

方便地开发出高质量的、适合政府部门使用的应用程序。

J2EE中提供了分布式计算环境中组件需要的所有服务，例如组

件生命周期的管理、数据库连接的管理、分布式事务的支持、组件的

命名服务等等，可以提供程序更加高效地运行于应用服务器中，支持

多种客户端的访问。

基于J2EE的分布式计算技术可以实现以下三个目标：

•集成性：集成性主要反映在对应用程序互操作能力的支持

上。它要求分布在不同机器平台和操作系统上、采用不同的语言

或者开发工具生成的各类商业应用必须能集成在一起，构成一个

统一的计算框架。这一集成框架必须建立在网络的基础之上，并

且具备对于遗留应用的集成能力；

•可用性：要求所采用的软件构件技术必须是成熟的技术，

相应的产品也必须是成熟的产品，在至关重要的应用中能够稳

定、安全、可靠地运行。另外，由于数据库在政府中扮演着重要

角色，软件构件技术应能与数据库技术紧密集成；

•可扩展性：集成框架必须是可扩展的，能够协调不同的设

计模式和实现策略，可以根据政府的需求进行裁剪，并能迅速反

应市场的变化和技术的发展趋势。通过保证当前应用的可重用

性，最大程度地保护政府的投资。

2.2.4.2构件技术

通过构件技术实现业务模型的设计和实现，并可重用。

构件（Component,也译为组件），可复用的软件组成成份，可被

用来构造其他软件。它可以是被封装的对象类、类树、一些功能模块、

软件框架（framwork）、软件构架（或体系结构Architectural）、文档、

分析件、设计模式（Pattern）等。构件分为构件类和构件实例，通过

给出构件类的参数，生成实例，通过实例的组装和控制来构造相应的

应用软件，这不仅大大提高了软件开发者的开发效率，也大大提高了

软件的质量。

构件应用层次图

构件按照应用层次多层抽象，根据业务需求组装。

•基础构件库：面向技术的，较低层的构件，解决具体的技

术问题，例如：日期类型的转换函数、下拉框等。

•业务构件库：面向单位某类业务的，具有业务的特性，但

可应用于多个业务类型中。

•行业构件库：根据单位原有业务管理系统的功能，将部分

可以重用的组件进行封装和改造，具有一定的业务的特性。

构件化的多层体系图

面向构件的实现多层体系，采用数据总线的技术，各层之间松散

耦合，如有变化影响较小，构件相对稳定，灵活多变又能保证系统稳

定性。

本项目设计中，将采用页面展现层、业务逻辑层、工作流层分别

进行设计开发，利用构件技术进行组装，提高软件开发的效率，提高

系统的扩展性。

2.2.4.3UI技术

面向用户的界面设计（UI设计），突出以人为本。

软件除了实用外，人们的着眼点更在于软件的易用性和美观性，

而易用与美观主要取决于人机界面的优劣。众所周知，在当今的硬件

与软件环境下，一个软件系统没有很好的界面设计就不能算是成功。

因为不管它内部有多么精巧的技术，只要用户不愿意使用它，它的优

越性就得不到发挥，它的价值和作用也无从谈起。于是一个不涉及技

术而着眼于易用和美观的行业越来越显得重要一一这就是软件UI设

计。

软件设计可分为两个部分：编码设计与UI设计。编码设计大家

都很熟悉，但是UI设计还是一个很陌生的词，即使一些专门从事网

站与多媒体设计的人也不完全理解UI的意思。UI的本意是用户界面,

是英文“User”和“Interface”的缩写。从字面上看是“用户”与

“界面”两个词组，但实际上还包括用户与界面之间的交互关系。

以用户为中心的关键原则：

•理解用户的任务需求：包括在整个产品生命周期中各方面

的需求

•设定量化的目标：建立基于用户或基于业务的标准。

•设计一个完备的用户体验过程：一个用户对一个产品的完

备的体验过程包括包装、销售、培训、硬拷贝文档、设置、安装、

屏幕、图形、帮助、其他性能支持、升级和卸载

・评测：让用户参与测试，借些判断是否达到了目标或是否

存在问题

•迭代：如果没有达到目标或存在问题，就要进行修改，并

使之重新生效。

•第一次不可能做得很完美，认识到这一点是非常重要的。

要知道需求可能会扩展和延伸到产品的设计和实现阶段。设计和

开发的实践与技术有很多，结合使用以用户为中心的设计原则

时，在软件系统开发上成功实现业务目标有很大帮助。

2.2.4.4工作流技术

工作流引擎是平台的核心模块，它负责解析工作流程，完成工作

流程执行，并提供运行的监测接口，能够对正在执行的任务进行监控。

工作流驱动引擎犹如计算机的CPU,是核心处理模块。

工作流引擎可以管理多个流程，每个流程都有自己唯一的流程编

号，它们由工作流管理容器统一管理，工作流管理容器还记录和该流

程对应的相关数据和状态，工作流容器支持多个流程并行运行，一个

流程可能会有多个实例(instance)在并行运行。平台可以通过修改

参数定义来调整工作流引擎支持的最大流程数量和运行实例的数量。

工作流的每个活动在工作流引擎中都可以看作是一个任务，工作

流引擎虽然支持多流程、多任务的并行处理，但是在单位时间片内，

平台实际处理的任务只能有一个，任务调度管理器所要完成的主要功

能就是如何指挥和调度所有等待运行的任务，使得他们能够达到并行

处理的目的。

工作流技术是建设流程类业务应用系统的核心技术。现代的工作

流系统应具备图形化工作流定义工具、工作流引擎、工作流监督和管

理工具、工作列表等必备模块，支持子工作流、应用集成、超时处理、

工作流变量等基本功能，具有较高的性能、可靠性、事务处理能力和

失效恢复能力，具备清晰的APT接口，既能够用于支持办公流程的开

发，也能够支持业务流程的开发和集成，形成各应用系统的流程支撑

平台。

工作流技术适应于电子政务平台框架下的具体电子政务应用系

统中各个政府职能部门之间的联办互动工作，公文流转，电子政务管

理云平台、信息传递等系统都要用到工作流技术。采用工作流引擎技

术将信任服务、授权服务和工作流等业务流程有机融合紧密结合在一

起，构成安全的工作流业务系统，为不同业务系统集成提供实现的技

术手段。

工作流指的是工作任务在多个人或单位之间的流转。在计算机网

络环境下，这种流转实际上将表现为信息或数据在多个人之间的传

送。它所要解决的主要问题是使在多个人员之间按照某种预定义的规

则传递文档、信息或任务的过程自动进行，从而实现某个政府的业务

目标。

针对建设电子政务管理云平台，系统要涉及到全局的应用系统和

办公人员的日常工作需要，如果能够应用良好，那么将大大增强办事

效率。

平台提供了强大的工作流引擎，不仅完全实现了各类收发文管

理，并将其应用拓展到其他办公和业务流程。帮助单位规范工作流

程，以公共资源管理配置平台为基础的工作流引擎，为用户提供基于

图形化流程定制工具，实现各种业务流程的灵活定制，从而生成各种

流程系统，如公文流转、请示报告、提案管理、采编发、督察督办、

电子会议、车辆管理等。

支持的几种常见流程模式：

直流：从一个处理节点到另一个处理节点；

分流：多个处理节点到一个处理节点或者一个处理节点到多个处

理节点；

条件流（简单条件流，复杂组合条件流以及逻辑判断条件流）；

子流：工作流中嵌套子工作流处理。

稳定性和适应性是流程平台最重要的因素。流程平台能够稳定地

运行于各种环境下。根据多年的客户实际使用经验，对流程中的各种

突发事件或是异常状态也能够进行有效的控制，不会因为流程中的某

个错误而导致文档流程失败。支持的流程异常处理。

回收：流程启动者可以要求对正在处理的流程进行撤销办理；

催力、（手动催办和自动催办）：用户能够对过期未完成的文档进行

催办通知以及处理；

移交：当前办理者可以把文档转给同一权限的人员办理；

重办：允许工作流中的某个办理人员提出重新办理已经处理过的

文档；

代办：当办理人员无法及时处理流程，系统将转给代办人员进行

处理；

跳转：由于业务流程模式的突然变动，允许具有相应权限的用户

对流程做出跳转处理，直接发送到某个节点上。

智能型流转模式：系统可以根据一定的条件跳过其中某个处理人

或是处理节点。

严格按照权限的逐级流转模式：严格按照权限的逐级流转方式能

够把行政级别，行政职务紧密结合。

特点

先进性

在技术上采用当今先进的Struts构架、运行于J2EE环境，将先

进和成熟的技术与现实的应用相结合，并具有高性能和高稳定性。

采用的事件驱动工作流引擎

通过事件驱动来运转工作流引擎，根据事件来源将事件概括为若

干类事件。当工作流运行过程中由用户、系统或外部、时间等触发事

件，通过事件检测器检测到已触发的事件，判断事件类型后，启动相

应的监听器来处理其业务，进而推进工作流程的流转。

流程定制通过浏览器实现

提供浏览器方式的工作流定义，用户可以直接在浏览器上进行工

作流程的定义，这样使得用户的操作更简单，实现零成本维护。

细致严密的权限控制

支持多种权限设置，可以将权限设置到字段级。

可扩展性

系统具有很好的扩展功能，采用流程定制模板的方法，方便地根

据用户需求配置系统模块，适应不同的需要，可以满足各种业务的需

要，为系统今后功能扩展、升级、推广应用创造了条件。

安全性

系统具有完善的认证和授权管理。任何人必须经过认证才能访问

系统，且只能访问其权限范围内的系统。

2.2.4.5XML技术

XML同HTML一样，都来自StandardGeneralizedMarkup

Language,即标准通用标记语言，简称SGMLoXML是一个精简的SGML,

它将SGML的丰富功能与HTML的易用性结合到了应用中。XML保留了

SGML的可扩展功能，允许定义数量不限的标记来描述文档中的资料,

允许嵌套的信息结构。XML的全名是extensibleMarkupLanguage（可

以扩展的标记语言），它的语法类似HTML,都是用标签来描述数

据.HTML的标签是固定的，只能使用不能修改；XML则不同，它没有

预先定义好的标签可以使用，而是依据设计上的需要，自行定义标

签.XML是一个元语言，根据不同的行业和语义，由它可以派生出许

许多多的协议和规范。不同的行业和领域都可以制订自己的XML规

范，用于横向和纵向的信息交流和数据传输，从而形成特定领域（如

政府、商业等）的标记语言，为该领域中的数据和信息交换提供统一

规则。

XML的数据内容与数据显示形式是完全分离的，XML文件为纯文

本文件不受平台限制，XML是一种完全面向数据语义的标志语言，容

易描述数据的语义及元素结构，不仅可以描述结构化数据，更可以非

结构化数据，非常适用于异构数据库之间的数据交换。目前，XML已

经成为数据交换的标准。

2.2.4.6文件服务

结构设计

服务层定义应用程序的边界和从客户层接口看的可用的操作集，

并协调应用程序对每个操作的响应。服务层定义文件管理的边界和从

应用层接口看的可用的操作集，并协调文件管理程序对每个操作的响

应。服务层被实现为薄的覆盖在领域模型上的门面集，不实现任何业

务逻辑，而是由领域模型实现所有业务逻辑。

领域层负责文件管理的核心领域模型，实现所有业务逻辑。

数据访问层负责数据库访问和文件访问。所有与访问数据库和文

件系统的功能都委托这个层实现。

持久层存储文件服务的信息。目录集、目录、文件属性都保存在

数据库；文件的实际内容存在服务器的文件系统上。

2.2.4.7全文检索

现有协同办公部件的搜索方式都是分散到各个部件内部，只限于

对本部件内容的搜索。现在要求有一个集中搜索的地方，输入以空格

分隔的搜索条件，可以搜索出电子政务管理云平台中所有符合条件的

记录，同时这些记录是经过权限系统过滤的。

全文检索的实现有两种方式：借用Lucene等第三方分词工具，

效率比较高，可以获得google类似的查询效果，但是必须要与权限

系统很好的结合，查询结果展现方面也要有一种全新的适合用户的展

现方式；第二种，利用oracle对字段的全文检索，无法获得google

的查询效果，查询效率较低，但是可以很好的与权限系统结合，查询

结果展示可以直接复用部件的列表展现页面。以下设计只针对第二种

情况。

设计原则

＞符合实施用户的传统习惯，上手方便。

＞提供简便的API接口。

＞在现有开发模式下，各个部件做尽量少的工作。

＞与权限系统很好结合。

设计目标

对审批流里面的信息，办理意见，文件正文，表单，业务数据,

业务单据等进行全文检索。

总体结构

全文检索对象循环调用各个部件的查询对象，传入查询条件，根

据返回的记录行数决定是否展现这个部件。

部件查询对象可以加载解析全文搜索条件，部件本身的搜索条

件，数据权限的条件等。可以查询记录行数以及分页的结果集。将部

件全文检索字段与全文检索条件结合，解析成查询条件。

业务部件注册本部件全文检索字段，创建全文检索。业务部件的

数据加载和查询都通过部件查询对象。

功能说明

全文检索查询功能

由查询条件的录入和部件的范围选择组成。多个查询条件用空格

分隔，查询的结果需要符合所有的查询条件；可以选择部件查询范围

或者整个系统进行查询。

查询结果展现

将查询后有记录的部件顺序展现，复用原部件的展现页面，各个

部件的组合查询部分也有一个针对本部件的全文检索输入框，用户可

以调整查询条件，进一步查询。

2.2.4.8权限组件

权限可简单表述为这样的逻辑表达式：判断“Who对What(Which)

进行How的操作”的逻辑表达式是否为真。针对不同的应用，需要根

据项目的实际情况和具体架构，在维护性、灵活性、完整性等多个方

案之间比较权衡，选择符合的方案。在这里的WHO可以定义为政府部

门用户范围内。WHAT(WEIGH)可以确定为政府业务范围中的内容。

HOW可以确定为政府系统中涉及到的业务处理。

权限管理与组织管理紧密相关，需要利用接口调用相关的部门、

职务、级别、岗位、角色和工作组等内容，使用基于角色的访问控制

方法(RBAC)进行权限控制操作。权限管理需要达到的目标大致可分

为三种：

/直观，因为系统最终会由最终用户来维护，权限分配的直观和

容易理解，显得比较重要，系统不辞劳苦的实现了组的继承，除

了功能的必须，更主要的就是因为它足够直观。

/简单，包括概念数量上的简单和意义上的简单还有功能上的简

单。想用一个权限系统解决所有的权限问题是不现实的。设计中

将常常变化的“定制”特点比较强的部分判断为业务逻辑，而将

常常相同的“通用”特点比较强的部分判断为权限逻辑就是基于

这样的思路。

/扩展，通常Role的设计方式意味着预先已经定好了一组权限,

这样的“预先设计”，常常会鼓励程序员hardcode这些权限相关

的部分，如果这么做的话，当需要重新定义Role时，扩展就会变

得极为困难。而采用可继承的Group概念在支持权限以组方式定

义的同时有效避免了重定义时在扩展上的困难。

在应用支撑平台中的权限管理组件中，可分为功能级权限管理和

数据级权限管理两大类。功能级权限管理组件包括用户管理、功能管

理和功能权限管理三部分。

需要再次强调的是，这里表述的权限管理仅是一个“不完全”的

权限系统，即它不提供所有关于权限的问题的解决方法。它提供一个

基础，并解决那些具有“共性”的（即仅考虑对象的类别，不考虑对

象的某个特定实例）部分。这个在这个基础之上，根据各业务系统自

身的“业务逻辑”的独特权限需求，编码实现剩余部分（具体到业务

操作）部分，才算完整。例如对非税收入管理这个业务系统整体授权,

而不是对该系统中某些独有的功能进行授权。回到权限的问题公式，

通用的设计仅解决了Who+What+How的问题，其他的权限问题留给业

务系统自行解决。

2.2.4.9表单设计器

表单是一种用于数据采集的页面，通过表单来获取用户的数据并

进行显示。表单管理提供一系列工具，进行表单的制作、逻辑关联、

数据处理，通过表单管理来完成表单的功能。表单页面中除了静态内

容，如：表格、文字、图片、FLASH外，可以添加表单域和表单操作。

表单域是用来接受用户录入的控件，主要包括输入框、下拉框、单选

框、复选框、大文本框等。表单操作是指能够进行数据操作的按钮、

链接等。通过表单域和表单操作的共同作用，来完成表单的数据采集

和展现功能。

表单的所有设置和版本都存放在子系统目录下与表单号相应的

文件夹下，文件夹下按版本号的目录分别存放。

表单包括二种类型：

数据库表单

直接跟数据库表进行绑定，用于对数据库表中的数据进行增加、

删除、修改等更新操作。通过数据库表单，将后台数据与前台用户进

行有机连接，完成数据的采集和更新功能。

流程表单

专门用于工作流管理系统中进行流转事项的记录和采集的表单。

与流程紧密关联，保存办理事项的详细内容。流程表单其实就是实际

的办事表格。

表单的设计包括以下方面：

＞富文本编辑管理：用于设计表单。在表单页面中除了包括一些

静态的HTML表格、图片、文字外，还可以动态地添加表单域和

表单操作。

＞式样管理：提供对表单CSS式样文件的管理。

＞后台脚本：表单进行逻辑操作的后台运行的脚本。

＞数据校验：通过后台进行数据校验。

2.3数据安全设计

231基于消息的安全数据交换设计

2.3.1.1设计原理

签名摘要+效

据文件+发送

方加密证书

等待发送的(1).用故据对发送方加对收到的京猿文

数据发送方私钥篇摘密证书进行件计篝摘要并和

要信息进行釜45脱密处理，对方发送来的摘

处理用得到的发要进行比较

(2).用消息

接收方公饵对发送方公朗对

送方数字ii书遗签名摘要进

行JD密行解密

图：安全数据交换设计原理

如上图所示，在进行数据传送的时候，调用方调用数据交换所提

供的接口，把数据以及传送的目的地传递到交换接口中。交换接口首

先利用摘要算法计算数据的摘要信息；把生成的摘要信息用发送方的

私钥进行签名处理，同时把发送方的数字证书通过接收方公钥进行加

密，形成加密后的数字证书；随后把附有签名摘要的数据文件通过消

息中间件发送出去；在数据进入传输网络之前，通过加密机或加密卡

（或者通过软件实现加密处理）对数据加密，形成密文。

在密文到达目的地之后，首先通过脱密处理，然后数据被接收方

消息中间件传送到暂存区保存；接收方系统使用自身私钥对发送方的

加密数字证书进行脱密，并检查脱密后的发送方数字证书的合法性；

如果证书合法，则用它对签名摘要进行解密，如果解密成功，取得解

密的摘要信息；系统重新计算发送数据的摘要，并把他与收到的脱密

摘要进行比较，如果一致则说明数据没有被篡改。

2.3.1.2框架设计

以上说明了本方案的设计原理，下面的图示中则对交换系统的构

成进行说明:

图：安全数据交换设计框架

系统框架由4部分组成，即：

(1)消息中间件，用于提供可靠的信息传输，建议采用商业消息

中间件；并提供自己的消息交换机制，来满足数据交换的需要；

(2)数据交换API,用户提供编程接口；

(3)数据交换实现，用于整合消息中间件、基于公钥基础设施的

保密模块的功能，支持数据交换API对外提供服务；

(4)基于公钥基础设施的保密模块，封装数字签名、时间戳、解

密等安全保密服务，支持安全的数据交换实现。

2.3.1.3对数据时效性的扩展支持

信息传输的时效性也是很重要的。对于成功的电子商务应用，要

求参与交易各方不能否认其行为。这其中需要在经过数字签名的交易

上打上一个可信赖的时间戳，从而解决一系列的实际和法律问题。由

于用户桌面时间很容易改变，由该时间产生的时间戳不可信赖，因此

需要一个权威第三方来提供可信赖的且不可抵赖的时间戳服务。

所谓的时间戳服务就是将经过CA签名的一个可信赖的日期和时

间与特定电子数据绑定在一起，为服务器端和客户端应用提供可信的

时间证明。

图：时间戳工作示意图

系统通过在基于公钥基础设施的保密模块上扩展时间戳服务，可

以在生成摘要的同时把他送到第三方的时间戳服务器来制作时间戳。

方案优点

(1)利用消息技术，实现信息的可靠传输，不用担心由于网络

不稳定而造成发送失败。

(2)利用数字签名、加密机来确保信息传送的不可抵赖性、安

全性、防篡改、防止数据截获。

(3)采用硬件加密设备，可以加快数据的加密过程，而不用使

用软件加密。同时，由于加密设备是对网上传输的所有数据进行加密,

更进一步提高了系统的安全性。

2.3.1.4数据离线交换模块

所谓的离线数据交换是指将数据按照规定的格式导出到存储介

质上，通过人工的方式把数据传递需要的地点，然后再导入到目标机

器上。这种方式实现比较简便，投资也小。

离线数据交换可以通过在公共功能导入、导出来达到。提供的离

线交换功能可以允许用户自行定义导入导出的数据格式，支持数据的

离线报送。它能导出xml、html、access等格式的数据文件。与加密

模块相配合还可以实现加密保护功能，以保护介质中数据的安全。

2.3.1.5数据验证、加密模块设计

2.3.L5.1需求分析

数据校验、数据加密模块具有密钥管理机制、校验算法管理机制，

能够根据应用需要更换系统密钥或校验算法。按照开放性封装技术形

成部分可提交第三方使用的加密、校验控件，提供跨平台的编程接口。

通过本次系统建设，要能够产生出一个供第三方使用的带有跨平

台接口的数据校验、数据加密模块。并且用户可以根据自己的需要选

择加密和校验算法。

从密钥是否是单一的还是成对的角度上，可以把加密算法分成对

称加密和非对称加密。所谓的对称加密，是指加密和解密用的密钥都

是一样的，被加密数据的安全性依赖于密码的安全性和算法的安全

性。这种加密算法一般用来对大批量数据进行的加密处理，通过保持

密钥的安全来保护数据本身的安全。

而非对称加密，则是指加密和解密用的密钥是不同的两个，可以

把一个叫做公钥，另一个叫做私钥。私钥属于用户的私有信息，不对

外公布，而公钥则作为公开信息公布给第三方。一般来说，公钥用来

对数据进行加密，而私钥则是用来对数据进行签名，表示发送人认同

发送的数据是自己发送的，具有不可抵赖的特性。但这种加密算法由

于计算速度偏慢并不太适应对大量数据进行加密处理。

对于本系统来说，它的校验和加密功能应该能够作到如下几点要

求：

(1)能够识别数据是真实的，确实代表了数据产生方的原始意

图。

(2)能够识别数据是完整的，没有经过其他人中途截获篡改。

(3)能够保证数据本身是的安全的，能够防止在数据中途截获

后在一段时间内不被攻破。

(4)数据能够在很短的时间内被处理完成，而不应该让用户等

待过长的时间。

因此，本系统要求的狡验和加密模块应该是对称算法和非对称算

法的结合，通过对称算法，实现数据的快速加密，通过非对称算法，

来实现数据的完整和真实。因此，需要使用公钥密码体制中的数字签

名和数字信封两种方式来满足要求。

2.3.1.5.2框架设计

模块的设计框架如下图所示:

私钥

客

户安全管理模块

端

安

全

客户端

控

件

密码算法库

图:校验、加密模块设计框架

整个模块分成三大部分，第一部分是客户端安全控件，它镶嵌在

用户的界面上来实现对数据的签名、加密、解密功能；第二部分是安

全管理模块，主要是对密钥和校验算法本身的管理，实现密钥或校验

算法的更换、启用、停用等功能；第三部分是密码算法库，用于封装

各种加密和摘要算法,如DES、3DES、MD5/SHA1,DSA,DESede/DES,

Diffie-Hellman等。

2.3.1.5.3数字签名和数字信封

数字信封(DigitalEnvelop)的功能类似于普通信封。普通信封

在法律的约束下保证只有收信人才能阅读信的内容；数字信封则采用

密码技术保证了只有规定的接收人才能阅读信息的内容。

数字信封中采用了单钥密码体制和公钥密码体制。信息发送者首

先利用随机产生的对称密码加密信息，再利用接收方的公钥加密对称

密码，被公钥加密后的对称密码被称之为数字信封。在传递信息时，

信息接收方要解密信息时，必须先用自己的私钥解密数字信封，得到

对称密码，才能利用对称密码解密所得到的信息。这样就保证了数据

传输不可抵赖性。

数字签名(DigitalSignature)是指用户用自己的私钥对原始数

据的哈希摘要进行加密所得的数据。信息接收者使用信息发送者的公

钥对附在原始信息后的数字签名进行解密后获得哈希摘要，并通过与

自己用收到的原始数据产生的哈希哈希摘要对照，便可确信原始信息

是否被篡改。这样就保证了消息来源的真实性和数据传输的完整性。

2.3.L5.4数字签名原理

在文件上手写签名长期以来被用作作者身份的证明，或表明签名

者同意文件的内容。实际上，签名体现了以下几个方面的保证：

签名是可信的。签名使文件的接收者相信签名者是慎重地在文件

上签名的。

签名是不可伪造的。签名证明是签字者而不是其他的人在文件上

签字。

签名不可重用。签名是文件的一部分，不可能将签名移动到不同

的文件上。

签名后的文件是不可变的。在文件签名以后，文件就不能改变。

签名是不可抵赖的。签名和文件是不可分离的，签名者事后不能

声称他没有签过这个文件。

而在计算机上进行数字签名并使这些保证能够继续有效则还存

在一些问题。

首先，计算机文件易于复制，即使某人的签名难以伪造，但是将

有效的签名从一个文件剪辑和粘贴到另一个文件是很容易的。这就使

这种签名失去了意义。

其次，文件在签名后也易于修改，并且不会留下任何修改的痕迹。

有几种公开密钥算法都能用作数字签名，这些公开密钥算法的特

点是不仅用公开密钥加密的消息可以用私钥解密和，而且反过来用私

人密钥加密的消息也可以用公开密钥解密。其基本协议很简单：

发送方用她的私钥对文件加密，从而对文件签名。

发送方将签名后的文件传给接收方。

接收方用发送方的公钥解密文件，从而验证签名。

在实际过程中，这种做法的准备效率太低了。从节省时间，数字

签名协议常常与单向散列函数一起使用。发送方并不对整个文件签

名，而是只对文件的散列值签名。

在下面的协议中，单向散列函数和数字签名算法是事先协商好

的。

发送方产生文件的单向散列值。

发送方用她的私人密钥对散列加密，以此表示对文件的签名。

发送方将文件和散列签名送给接收方。

接收方用发送方发送的文件产生文件的单向散列值，同时用发送

方的公钥对签名的散列解密。如果签名的散列值与自己产生的散列值

匹配，签名是有效的。

如下图:

发送接收

图：数字签名协议原理

由于两个不同的文件具有系统的160位散列值的概率为1/2160,

所以在这个协议中使用散列函数的签名与使用文件的签名是一样安

全的。

232备份与恢复方案

备份不仅是数据的保护，其最终目的是为了在系统遇到人为或自

然灾难时，能够通过备份内容对系统进行有效的灾难恢复。备份不是

单纯的拷贝，管理也是备份重要的组成部分。管理包括备份的可计划

性、磁带机的自动化操作、历史记录的保存以及日志记录等。为了实

现快速安全、便捷的备份，将考虑从以下方面进行:

2.3.2.6备份模式

结合这三种方式，灵活应用。比如：数据量少时，可以每次都用

全备份备份数据，这样，恢复时，只需要指定一个数据源即可。数据

量大时，如果经常全备份，效率会很低，可以结合全备份和增量备份

方式。比如每星期做一次全备份（如星期天），其他时间，每天做一个

增量备份（如星期一到星期六）。恢复时，只要依次恢复最多七个备份

介质即可。（如：上周日、星期一、星期二……直到破坏前一天的数据。

1、完全备份，每次备份定义的所有数据，优点是恢复快，缺点

是备份数据量大，数据多时可能做一次全备份需很长时间。

2、增量备份，备份自上一次备份（全量或增量）以来更新的所有

数据，其优点是每次备份的数据量少，缺点是恢复时需要全备份及多

份增量备份。

3、差量备份，备份自上一次全备份以来更新的所有数据。

2.3.2.7备份软件

采用各个专业厂商提供的全面的专业备份软件，如

HPOpenViewOmniBackII和CA的ARCservelT等。通过这些备份软件

达到使用方便、自动化程度高，还要有好的扩展性和灵活性。同时，

跨平台的网络数据备份软件能满足用户在数据保护、系统恢复和病毒

防护方面的支持。通过这些备份软件配合高性能的备份设备，能够使

损坏的系统迅速“起死回生

2.3.2.8集中备份的策略

建议采用集中统一的备份策略管理：即在一台专用的服务器上安

装备份软件如：VERITASNetbackupSANMasterServer,通过它来

集中管理、监控整个数据库和应用系统的备份工作，管理备份策略。

今后如果需要增加前置机或其它服务器（LAN环境），都可以通过网

络由主服务器进行备份。为实现多台磁带机的共享，通过在备份主服

务器上安装磁带存储资源共享（SSO）组件，按照磁带机的数量配置

DriveSupport,由主服务器负责控制磁带库机械手，从而实现了多

台服务器共享磁带机的协调备份，从根本上解决SAN模式下的共享备

份问题。

2.4非功能性设计

241系统可靠性设计

可靠性设计包括系统可靠性、数据库可靠性、数据采集可靠性、

网络和通讯可靠性。其中的内容如下。

系统可靠性包括：系统备份、故障处理、系统恢复。

数据库可靠性：时间点恢复，将数据库或事务日志恢复到约定的

时间点的状态，数据库损坏的恢复。

数据采集可靠性：数据采集中的合法性检查，数据采集中的有效

性检查，数据采集中的一致性检查。

网络和通讯可靠性：传输校验纠错，系统通过数据备份、远程灾

备等方面保证系统的可靠性要求。

242系统可扩张性设计

采用模块化、组件化和高内聚、低耦合系统设计，具有适应业务

变化的能力，如系统用户数量及业务量的增长、规则或代码的变化、

业务单据的变更、业务流程重组等，应尽可能地保证将业务变化造成

的影响局部化。当系统用户数量及业务量增长时，系统容量发生变化

时，应能通过在横向和纵向的各个层次的扩充，保证系统合理的响应

时间和负载能力。

2.43系统易用性设计

用户在进入系统的同时，能够非常方便快捷的发现自己想要进行

的操作内容，需要特殊处理或者最新内容通过特殊醒目的字体或图片

可以给用户醒目而美观的提示。同时系统还具有将用户常用操作首先

显示在系统首页的功能，这样每个用户都可以按照自己的操作习惯定

制功能模块摆放位置，还具有个性化的特点。

提供系统导航功能，提供完整易用的帮助系统，在任何一个环节

都可以通过查看相应的帮助文件，用户即使在完全不熟悉系统业务的

情况下，也可以按照帮助中的内容一步一步的完整的完成应有的操

作。

244系统可用性设计

整个管理运行过程在系统化程度较高的机制下运行，尽量减少人

为干预。系统要具有很强的数据处理能力，能保证高效率地实时处理。

详细记录每一笔业务数据，保证记录的准确性和完整性。系统既要能

适应微观管理层面业务需求的调整的要求，又要能较好地满足宏观管

理需求变化的需要。此外还要满足：

1、系统自动失效转移，避免单点故障而影响整个系统的正常运

行。

2、制定应急预演计划和灾难恢复计划。

3、高效的备份/恢复流程和技术，缩短由于数据库、硬件和应

用升级等所带来的停止服务时间。

245系统可维护性设计

系统设计上采用面向服务构架（S电子政务），要面向接口而不

是面向具体实现，系统能够被简单方便地修改和升级，包含可读性、

可修改性、可测试性等。工作流可定制，系统应采用参数化设计，必

须支持动态业务流程建模，可以根据实际情况对功能进行灵活调整而

无需修改程序。客户端必须减少系统修改和升级所带来的维护工作量

和复杂度。

2.4.6系统可管理性设计

提供统一的管理接口、监控接口和多层次的日志功能，实现系统

的可管理型。包括对构件的管理、系统排错和性能优化等。

247系统安全性设计

系统采取多层安全和防范措施，通过建立合理的安全体系，对用

户进行身份认证和授权，防止系统外非法用户的侵入和系统内用户的

非法探测和恶意泄密。系统开发应有统一门户理念（统一系统内用户

身份认证和权限管理，实现单点登录，统一对外信息交换，统一报表,

统一安全管理机制）。

系统设计保护用户身份的安全，实现功能权限和数据权限控制，

保证客户端与服务器以及服务器之间的数据传输安全、关键数据的存

储安全。

对于关键业务操作提供安全审计功能，提供数据完整性保证及行

为的不可抵赖性保障，系统关键应用应有日志记录功能，可以对操作

过程进行追踪和回溯。

第三章建设内容

3.1统一工作门户

3.1.1登录入口

用户通过系统登录入口输入用户名、密码或通过CA秘钥认证，

登录到XXX市办公集成系统。访问公共区和个人门户相关内容。同时

也可以使用手机APP扫描二维码登录。

3.1.2通用门户

通用门户通常来发布一些政务相关公共信息，通过公共门户可以

实现政府及下属单位以及区领导公共信息的共享。

根据信息内容不同可以分栏目发布，通常栏目有：

3.1.2.1政府动态

将来自于政府、各区政府及其他部门的信息发布到内部网上。如:

新华社电讯、领导讲话、宏观统计、政策动态等。

3.1.2.2内部信息

内部发布信息主要来源于：政府内信息：政府内发生的事件、通

告等。

3.1.2.3内部刊物

主要将内部刊物发布到内部网上，供阅览。如：政府信息、工作

简报、情况反映等。

3.1.2.4报刊杂志

将部分与政务相关的公开发行的报刊杂志及报刊杂志网络版的

内容，经过加工以后放到内部网络上，供职工参考。

3.1.2.5政策法