政务信息整合平台方案.docx

政务信息整合平台方案.docx

《政务信息整合平台方案.docx》由会员分享，可在线阅读，更多相关《政务信息整合平台方案.docx（11页珍藏版）》请在冰豆网上搜索。

政务信息整合平台方案

一、目标

以政务信息整合平台为中心，实现各政务部门的信息资源的交换与共享。

各政务部门作为资源提供者，通过数据交换为平台提供符合标准规范的政务资源数据，同时，内部和外部的资源用户可以从平台获得标准格式的数据，或者完成数据操作。

此外，通过政务信息整合平台的实施，还将实现如下目标：

Ø通过平台的资源目录，实现对信息资源的统一管理，如统一安全管理等。

Ø通过平台组件的开发及复用，实现对通用业务功能的积累，避免重复开发。

Ø基于平台的基础架构，保障资源的高可用性，以及基于硬件资源的横向扩展。

二、体系架构

2.1功能组成

平台功能包括数据交换与共享、资源目录、资源监控三部分。

如下图所示：

数据交换与共享

实现政务系统内部各种异构应用系统间的数据整合，并对用户应用系统提供统一的标准化的实体数据。

例如：

人口数据、法人数据、空间地理数据、宏观经济数据等。

其中，数据交换将各资源提供者（各委办局）的异构数据的整合为统一的标准格式的数据；数据共享则以数据服务的形式向资源用户提供数据操作功能。

资源目录

在对资源数据进行统一编目的基础上，实现对信息资源的管理。

数据提供者可将共享数据的信息注册到资源目录中，使用户知道如何使用数据。

数据用户通过查询资源目录，可以知道有哪些信息资源，以及信息资源在哪里、由谁提供等。

资源管理部门可基于资源目录，对信息资源实行统一管理，如统一用户授权，即限定哪些用户可以使用哪些数据，以及允许对数据进行哪些操作等。

资源监控

为平台的运维部门提供平台运行期间的各种监测和控制手段，以保障平台的正常运行。

这些手段包括：

监测各项资源的访问情况、控制各项资源的访问量、生成各种统计报告等。

2.2平台组成

从介质上分，平台分为三个组成部分：

开发工具、运行环境、管理工具。

开发工具：

提供图形化的开发界面，用以完成平台所实现的业务逻辑开发和配置。

可以是离线开发方式或是在线开发方式。

运行环境：

提供业务逻辑的运行环境，为基于JVM的后台进程，没有界面。

管理工具：

提供对运行环境的运行期管理，提供Web方式的操作界面。

同时，提供部署功能，用以将开发工具的开发成果部署到运行环境中运行。

三、数据交换与共享：

3.1系统组成：

数据交换与共享分为共享库、ESB（企业服务总线）、DI（数据集成）三部分。

共享库：

用于集中存储共享数据。

在简单的情况下，可基于常见的关系型数据库，如Oracle、MySQL等。

在特定场合中，可采用NOSQL数据库、内存数据库、文件系统、云存储等。

、

DI（数据集成）：

用于实现应用系统数据库与共享库间的数据同步。

DI的核心是ETL引擎，通过执行ETL作业，完成两点间的数据同步。

这种数据同步可以是双向的：

Ø数据上行：

即将应用系统的数据变化（增/删/改）同步到更新到共享库。

Ø数据下行：

即将共享库的数据变化（增/删/改）同步到更新到应用系统。

每个ETL作业包含输入、转换、输出三部分功能：

Ø输入：

从源数据库中抽取数据记录。

Ø转换：

对数据记录进行各种加工处理，如：

过滤、去重、排序、行列转换、字段合并/拆分等。

Ø输出：

将数据记录更新到目数据库中，可能对应着插入、删除、更改操作。

在复杂的场景下，源和目数据库可以不止一个，此时ETL作业中包含多个输入或输出，并且转换过程也包含了数据流的合并或分支处理。

ETL作业基于组件化开发，利于业务功能的扩展和积累。

其中：

Ø输入/输出组件的开发，可以使数据交换适应不同类型的应用系统数据库和共享库。

这些组件可支持：

常见的关系型数据库，如Oracle、MySQL、SQLServer、DB2等；各种NOSQL数据库，如MongoDB等；各种文件，如文本文件、XML文件、JSON文件等；以及针对特定数据库的定制化组件。

Ø转换组件的开发，可以将特定的业务功能独立出来，以便重复使用。

这些组件包括：

过滤、去重、排序、映射、字段拆分/合并、字串处理、数学计算等，以及针对特定业务功能的定制化组件。

DI包含作业调度机制，使ETL作业按指定的规律运行，如：

按指定的时间一次性执行、每天的某个时刻执行、每间隔10分钟执行一次等。

ESB（企业服务总线）：

数据提供者将自己的共享数据以服务的形式注册到ESB上，再由ESB以标准的形式统一对外提供数据服务，实现数据共享。

各种数据提供者可以以不同的形式提供数据服务（如直接访问数据库或提供各种API接口），而经过ESB的转换，给用户提供的将是统一的标准的数据服务（如WebService）。

ESB提供的服务实现包括接入、编排、接出三部分：

Ø接入：

基于某种协议为数据用户提供数据服务，如：

WebService。

Ø服务编排：

对服务的请求和应答数据进行处理，如：

协议转换、数据转换、加密解密、权限校验等。

Ø接出：

基于某种协议访问数据提供者提供的数据服务，如：

WebService、JDBC。

在复杂的场景下，服务编排中可能要处理条件分支、循环等逻辑，而且访问的数据提供者可能不只一个。

ESB的服务实现基于组件化开发，利于业务功能的扩展和积累。

其中：

Ø接入/接出组件的开发，可以使平台以不同的方式访问数据提供者，也可以使平台以不同的方式为数据用户提供数据服务。

这些组件可支持：

WebService、HTTP、JMS、FTP、JDBC、Socket等，以及针对特定协议的定制化组件。

Ø服务编排组件的开发，可以将特定的业务功能独立出来，以便重复使用。

这些功能包括：

不同协议间的转换、不同数据格式间的转换、对数据的加密/解密处理、对用户身份的认证及权限校验等，以及针对特定业务功能的定制化组件。

针对数据提供者提供数据的方式不同，可以将数据共享方式分为如下3类：

模式1：

ESB直接访问应用系统的数据库。

即平台上不保存应用系统数据，而是当数据用户访问ESB的数据服务时，ESB直接（通过JDBC或其他数据库支持的接口）访问应用系统数据库，完成数据操作。

模式2：

此模式与模式1类似，不同的是ESB通过应用数据提供的数据服务接口完成数据操作，而不是直接访问应用系统数据库。

因此更更保证应用系统数据库的安全，但功能也受此接口的。

模式3：

ESB访问共享库中的数据。

因此在此模式下，对于上行数据，需事先通过DI将应用系统的共享数据同步到共享库中；对于下行数据，应事后通过DI将共享库中的数据变化同步到应用系统中。

此模式下，在数据用户调用数据服务时，由于ESB访问的是共享库中的缓存数据，而非直接访问应用系统数据库，从而减少了对应用系统的压力。

由于数据同步存在一定延时，对数据用户来说，查询到的数据可能不是实时数据，对数据的更改可能不会立即生效。

另外，由于不同数据提供者的数据集中存储在共享库中，更利于数据的综合处理，例如结合人口信息和法人信息进行查询。

3.2特性总结：

支持各种异构的应用系统数据源：

基于DI的输入/输出组件和ESB的接出组件，可以支持不同的应用系统以不同的方式提供共享数据，如基于常见的关系型数据库（如Oracle、MySQL、SQLServer、DB2等）、各种NOSQL数据库（如MongoDB等）、各种文件（如文本文件、XML文件、JSON文件等）、基于各种协议的API接口（如WebService、HTTP、JMS、FTP、JDBC、Socket等），以及针对特定数据库/协议接口做定制化开发。

对外统一的数据服务接口：

尽管各种数据提供者可以以不同的形式提供数据服务，但数据用户总是以统一的标准的数据服务（如WebService）完成数据操作，而不必关心数据提供者的差异。

支持复杂的数据清洗、转换处理：

通过DI的ETL流程和ESB的服务编排，可对数据提供者提供的原始数据进行加工处理。

例如原数据中的身份证号为15位，在平台的处理过程中可以被自动转换为18位。

某些综合性信息可能需基于多个部门的数据综合处理（如结合人口信息和法人信息），无法由一个部门提供。

在DI的ETL流程和ESB的服务编排中，可以访问不同的数据提供者，再经过流程的综合处理，得到综合性结果。

如果数据用户所需的数据，需基于数据提供者提供的原始数据做大量复杂的转换处理后才能得到，可基于模式3，周期性地对应用系统的数据进行预先处理，并将结果保存到共享库中。

用户调用数据服务时，ESB直接从共享库中取最新结果，从而使用户尽快得到响应。

四、资源目录

4.1目录结构

元数据

资源元数据描述某项信息资源的特性，以便对信息资源进行管理、查询、使用。

元数据标准可在设计阶段具体确定，通常包括如下内容：

Ø标识类信息：

用于全局唯一标识某项资源，如资源编码等。

Ø描述类信息：

对信息来源、用途、特性等进行描述，以便使用者参考。

如提供者的单位名称及负责人联系方式、数据的用途、数据的适用条件等。

Ø分类及关键字信息：

用于该项资源在资源目录中的定位，以及检索效果。

Ø安全管理信息：

描述数据适用的用户范围及权限，加密、校验方式等。

Ø接口信息：

描述为该项资源提供的数据服务的接口信息，包括接口协议、服务地址、输入输出参数等，以便用户通过该服务接口信息实现对数据服务的调用。

例如，对于WebService服务，可提供WSDL地址。

Ø维护状态信息：

标识该项资源的使用状态。

如正常使用还是暂停使用。

注：

可参考《GBT21063-2007政务信息资源目录体系国标》中的第3部分：

核心元数据）

目录组织

将各项资源元数据按一定的分类体系组织在一起（通常为分级树状结构），即形成资源目录。

基于元数据的分类、关键字及内容，可对目录中的元数据进行检索，从而获得符合条件的资源元数据。

进而根据资源元数据的内容，决定是否使用以及如何使用该项资源信息数据。

目录组织的具体方式可在设计阶段确定。

注：

可参考《GBT21063-2007政务信息资源目录体系国标》中的第4部分：

政务信息资源分类。

该标准从4个维度对信息资源进行了分类，分别是：

Ø主题分类：

体现了其内容的属性或特征；

Ø行业分类：

体现了政务部门职能的特点；

Ø服务分类：

体现了政务信息资源面向用户提供的功能服务的划分；

Ø资源形态分类：

体现了政务信息的存在形式。

其中主题分类是基础，其余三类作为辅助。

标准中还针对各项分类的分类编码分别制定了标准，并提供了分类示例列表。

4.2目录管理与使用

目录管理功能组成

元数据的注册、注销和修改：

对元数据的管理是目录管理的核心功能。

元数据的注册是指针对一项新的信息资源，生成对应的元数据并添加到资源目录中，从而使数据用户可以从目录中检索到该项元数据。

元数据的注销是指当元数据对应的信息资源不再使用时，从资源目录中删除元数据。

元数据的维护是指当元数据相关的信息资源特性发生变化时，相应更新目录中的元数据内容。

基础数据的管理：

考虑到管理的方便性，针对元数据中的一些公共基础类信息可以单独管理，在元数据中直接引用。

当这些基础类信息的变化时，更新基础数据，而不是更新元数据。

例如：

Ø提供者信息管理提供信息资源的政务部门描述信息，一个元数据必须对应一个提供者，可以直接应用该项信息。

Ø服务模型信息描述提供数据服务的接口协议规范。

一个元数据对外提供数据服务，必定基于某种协议（如WebService），对服务模型进行统一管理，有助于资源用户根据服务接口查找所需的数据服务。

Ø分类信息各分类的描述性信息。

出于对元数据检索的需要，一个元数据通常对应一个或多个分类，这些分类通常以统一编号的形式被元数据引用，分类的描述信息则单独统一管理。

元数据的查询：

依据一定的查询条件（元数据名称、分类及其他内容等），从资源目录中检索符合条件的元数据。

权限管理

用户管理：

记录用户详细信息，包括用户名、用户密码、电子邮箱等信息。

可以通过用户组、角色等实现对用户的多层分级管理。

注：

人员管理可以考虑和外部权限系统（如OA的权限系统）整合，而不在资源目录系统中保存用户信息。

权限管理：

根据用户、用户组、用户角色，掀动用户对目录的使用权限。

例如，可将用户分为三种角色：

资源提供者、资源使用者、目录管理者。

针对三类角色的授权为：

Ø资源提供者：

元数据的修改。

另外，对元数据的注册和注销，提供者可向管理者提出申请，并提供元数据内容或唯一标识。

对于基础类数据，资源提供者只有查询权限，而没有修改权限。

Ø资源用户：

查询元数据及各类基础信息。

Ø目录管理者：

各基础类信息的增加、删除、修改。

审核和批准资源提供者的元数据注册和注销请求。