用户名：
密码：
区域政府的电子政务系统一般都包括了多家开发商提供的多套不同系统，这些系统一般都有独立的用户管理、权限管理、流程管理、消息管理等支撑模块，这种模式给管理带来了一定的不便，同时也造成了不必要的浪费。理想的模式应该是基于一个统一的基础支撑平台来开发、部署多套电子政务应用系统。这个基础支撑平台为系统管理员提供了便利的统一管理平台，同时也为应用系统提供调用服务，不必再去重复开发已有的模块。根据这个要求，我们开发“电子政务SOA基础支撑平台”，整个平台基于WebService和SOA的架构来设计与开发。
这个支撑平台的主要功能需求包括以下几个方面：
对区域内所有机关单位的用户和组织架构进行管理。实现对组织单位、用户信息的统一管理、集中存储、集中维护、集中展示、快速定位；实现对于分布系统的用户和组织数据的同步；提供区域内用户管理和用户标识的统一规范和服务规范。
区域内各部门的应用系统不断增加，通过统一服务管理，可以实现各部门各种异构系统统一的系统注册、服务注册、授权控制等功能；并提供通用的系统注册和服务注册的规范。
各业务系统建设时都考虑了独立的权限管理功能，在进行区域内资源整合和共享的时候，采用统一权限管理将给我们提供必要的支持。通过统一权限管理，实现全局内各子系统、应用服务的访问授权控制。
为区域内的用户访问各电子政务子系统提供单点登录服务，只需记录一套账号信息，通过统一的身份认证，即可进入各相关被授权过的子系统
统一门户管理服务为区域电子政务提供后台支撑和管理，实现对前台门户的整合定制和配置管理，实现对门户结构、参数、皮肤样式的综合定制。
电子政务平台中有很多系统需要发布信息，在原有的机制下，信息重复发布、发布质量参差不齐、安全隐患多等情况普遍存在。通过统一的信息发布服务，将多个平台和应用系统的信息进行集中发布管理。
系统管理员要查看各子系统的运行情况、用户使用情况，并形成统计报表；在出现意外情况时，可以根据日志记录查找操作人员和操作情况。
在每个业务系统中都有待办事宜，用户需要进入到每个业务系统中进行处理，这样给用户带来了很多的不便。通过统一消息，为各应用系统提供服务，实现手机短信、电子邮件、语音通知、传真、即时消息、待办事宜的分发，提高办事效率。
为各应用系统中的工作流提供统一的表单定义、流程定义支撑。
为各部门之间的异构数据交换和共享提供支持。
电子政务系统的总体框架如下图所示：
♦ 支撑平台主要包括两个组成部分：管理工具、服务接口。管理工具是一套配置、监控支撑平台的Web管理系统和Windows服务。服务接口是平台提供给业务应用层调用的API，应用层不需要直接和底层服务打交道，从而简化了应用开发的难度，提高了公用模块的可服用程度。
♦ 支撑平台采用SOA的架构，所有的接口服务通过一个注册库进行管理，并通过统一的身份认证接口来检查调用方对每个服务接口的访问权限。
一个典型的SOA实现通常依赖于多个服务。调用这些服务需要知道位置（即服务端点的地址）和绑定（到达端点的传输机制）信息。最简单的方法就是在实现中将端点地址硬编码。但这造成了方案实现和服务位置的紧密耦合（位置耦合）。将端点地址放到配置文件中可以改善这种情况。因为这样地址的改变就不会引起代码的改动。但是，随着服务或服务消费者（或者说是配置文件）增多，这种方法会带来扩展性问题。
在SOA架构的设计中，我们规划有三个主要组成部分：服务注册与管理中心、服务提供方、服务调用方，这三者的关系如下图所示：
♦ 服务注册中心的基础是一个注册服务数据库。其包含系统中所有WebService服务的信息和一个注册中心WebService服务。数据库中记录了所有关于服务的位置、方法说明和调用权限等信息；注册中心服务封装了这个数据库并提供了一套访问这些信息的“标准”API。并约定了在此平台上发布的所有服务必须遵循的规范标准。
♦ 服务提供方根据注册中心的接口规范开发标准的WebService，并为其中的每个方法提供一个唯一的标识。
♦ 服务提供方调用注册中心的“服务添加接口”把开发好的服务注册到“服务注册中心”。
♦ 服务消费方（客户端）到注册中心查找和发现需要使用的服务。
♦ 服务消费方根据找到服务的调用规范，传入参数，取得服务的返回值。在调用服务的时候能够根据服务的WDSL地址和接口名称动态创建代理。
|
一级菜单 |
二级菜单 |
三级菜单 |
|
|
组织架构 |
部门管理 |
|
|
|
用户管理 |
|
|
|
|
角色管理 |
|
|
|
|
|
|
|
|
|
应用与服务 |
应用注册 |
|
登记单点登录的入口地址，参见原来框架后台中的同名模块。 |
|
服务类别 |
|
|
|
|
Web服务注册 |
|
|
|
|
数据库资源 |
|
|
|
|
共享文件源 |
|
|
|
|
客户端管理 |
|
|
|
| 服务授权 |
|
|
|
| 应用授权 |
|
|
|
|
服务监控 |
|
|
|
|
|
|
|
|
|
日志审计 |
登录日志 |
|
用户访问单点登录服务的详细日志 |
|
操作日志 |
|
用户对功能模块的操作日志；平台提供统一的WebService接口给应用系统，日志插入到中心库中。 |
|
|
服务调用日志 |
|
服务调用客户端对接口服务的调用日志记录 |
|
|
工作流 |
流程配置 |
|
把原先框架中的工作流管理模块提升到支撑平台中。 |
|
流程监控 |
|
||
|
|
|
||
|
表单服务（时间要求可稍缓）
|
数据表管理 |
|
创建数据表 |
|
表单管理 |
|
基于数据表生成表单，并提供在线调整表单的功能（结合华表和周剑锋做过的原型重新设计） |
|
|
|
|
|
|
信息交换平台是由各个部门的部门交换前置机以及中心交换前置机通过互联网络连接而构成的分布式系统。交换平台总体上采用前置机交换模式，即采用交换前置机将部门的业务系统与交换域隔离，保证部门业务系统的安全及业务独立性。
信息交换平台总体结构由信息交换网络、信息交换传输系统（信息交换总线）、中心交换前置机系统、部门交换前置机系统、信息交换桥接等部分组成，信息交换平台总体框架如下图所示。
前提条件：是建立统一的数据交换标准，并通过数据交换中间件（定制或购买），组建数据交换平台，数据交换格式为XML。
数据来源：首先由各地市建设相关的应用系统，并根据标准将相关数据汇总后统一传送至省级系统数据中心。
系统建设涉及多个不同政府部门的不同的业务系统之间的数据交换，这些系统的硬件平台、操作系统、数据库系统、软件开发环境各自不同，给系统之间的信息交换带来了一定的难度。
要进行数据交换的各个业务系统的数据库结构不同，在进行数据交换时，要进行数据结构和内容两个方面的转换，需要为系统提供一个灵活的数据转换机制。
不同业务系统之间的数据交换流程是不断地变化的，数据发送的目的地由数据发送方定义，数据系统要能够根据数据交换消息中的目的地信息，动态地进行消息路由。系统实施后，数据交换的流程并不是固定不变的。这就要求在建设过程中，为系统提供灵活修改数据交换流程的机制。
为了降低系统的总体维护成本，降低对专业技术人员的依赖，系统要能够支持中心部署、远程管理的功能，管理人员能够对诚信网系统提供管理服务支持。
