统一管理平台

统一管理平台（共10篇）

统一管理平台 篇1

0 引言

应用统一权限管理平台提高权限的集中管理, 进一步加快各业务系统之间的信息共享与融合, 可以使信息资源重复利用, 同时为业务功能组件化管理提供权限服务支撑, 提高业务应用及分析决策能力, 避免了在权限调整过程中存在用户权限放大的隐患。加快统一权限管理平台的建设, 以确保系统内人员、组织机构数据的一致性, 利用权限分析检测功能, 对人员权限进行全面监控与合规性检测, 通过安全、高效的数据同步技术、提高调整效率。

1 统一权限平台

统一权限平台架构。统一权限管理系统包括统一身份、统一认证管理、统一授权与安全审计四个核心功能模块, 实现人员身份管理、组织机构管理、授权管理、合规性管理、安全审计等模块功能, 实现统一管理、流程规范、过程受控、备案审查的目的。整体架构如图1所示:

2 统一权限平台技术支撑

2.1 分布式缓存

统一权限管理平台在系统缓存方面采用了memcached分布式缓存技术, 客户端的分布式设计成集群模式, 客户端集群由多个客户端节点组成, 应用程序在保存数据时先通过分布式算法获取到某一客户端节点, 客户端节点通过内部算法求出需存入的缓存服务器节点, 同时将存入对象放入异步同步线程池中, 同步给集群中的其它客户端节点。

具体如下:

(1) 数据缓存通过内存缓存、磁盘缓存作为存储介质, 通过同步、分片、路由实现灵活的集群、数据冗余。

(2) 系统数据缓服务提供统一的缓存访问接口API, 接口支持以RESTful方式访问。

(3) 数据缓存提供基于Web的配置、管理、监控界面。

(4) 平台通过提供LRU (Least Recently Used, 最近最少使用算法) 、LFU (Least Frequently Used , 最不经常使用算法) 和FIFO (First Input First Output, 先入先出算法) 等缓存策略及时清理过期缓存项目。

(5) 数据缓存套件服务于系统的其他所有模块, 数据访问层包含数据缓存服务的API。

2.2 SSO认证

统一权限管理平台主要采用单点登陆认证技术 (Single Sign On, SSO) , 通过使用单点登陆, 用户登陆门户后, 可直接访问相关业务平台, 在身份凭证有效期内, 也不需要再次进行认证, 提高了系统的易用性、安全性和稳定性。在系统服务器上, 通过部署SSO认证包, 实现即装即用, 具有很强的灵活性, 并且可以精确记录用户的日志等, 对后续业务系统扩展有良好的兼容性。

单点登陆的具体步骤如下: (1) 登陆系统平台后, 从登陆认证结果中获取相关用户id; (2) 由用户id映射不同应用系统的用户账号; (3) 最后用映射后的账号访问相应的业务系统。

3 统一权限平台与业务系统集成

统一权限与业务系统集成逻辑架构。由统一权限系统提供统一的登录认证模块, 访问业务系统若发现未登录则会跳转到统一权限的登录页面, 登录认证后返回用户访问的业务系统的页面。统一权限是相关权限数据在统一权限系统中维护, 正向同步到业务系统中, 常用同步范围如对用户、业务组织、业务角色分组、菜单的新增、删除、修改业务角色的权限分配、业务角色分配人员等。图2 为统一权限与业务系统集成逻辑架构:

4 结束语

本文针对统一权限系统从系统架构、技术支撑、与业务系统集成方式进行了介绍和分析。通过建设统一权限管理平台, 加强企业权限的集中、统一、精益和高效的管理, 进一步提升对企业内组织、人员、账号、权限的管控能力, 加强了对资源的共享。

摘要：随着互联网的迅猛发展以及internet技术的广泛应用, 加快企业信息化建设变得尤为迫切。目前, 国内信息化程度较高的行业纷纷启动并实施了统一权限管理系统的建设。本文通过建设的统一权限管理平台, 从而能够更加灵活、迅速的实现身份权限管理需求, 提升公司身份权限管控水平, 降低身份安全控制风险。

关键词：系统架构,统一权限,管理平台

统一数据交换平台的设计和实现 篇2

摘要:目前,数据共享困难已成为银行系统所面临的一个重要问题。本文指出统一数据交换平台能解决在分布式与多应用系统环境下的数据交换问题。文中根据组件化设计原则,以完成系统的总体设计、数据存储和加工设计。并应用NAS存储、使用NFS共享等技术部署对ETL技术进行了研究。

关键词:统一数据交换 存储 ETL

中图分类号:TP311.13文献标识码:A文章编号:1006-8937(2009)03-0064-02

在核心业务系统与外围系统之间批量交互数据是银行应用系统中最常见的任务之一,由于通常要受到多方面因素的制约,这是一个十分复杂而且耗费精力的工作。尽管目前银行正在进行综合业务系统大集中的改造,但并非所有银行的应用都会集中到唯一的核心业务系统上,而银行内还存在许多面向管理类的应用系统,这些围绕在核心业务系统的应用系统,我们称之为“外围系统”。

核心系统与外围系统的数据交换可以分为批量数据交换和实时数据交换两类。实时数据交换是双向的,一般由专门的中间件完成。批量数据交换也可能是双向的,但总体上是从核心系统流向外围系统的批量数据交换方式为主。从这一点来看核心系统是数据生产者,外围系统是数据消费者。外围系统之间也可以有批量数据交换和实时数据交换,因而互相扮演数据生产者和数据消费者的角色。

本文研究的是如何在中国建设银行总行实现统一的批量数据交换,从而建立统一数据交换平台(Unified Data Interchange Platform,以下简称UDI)。

1应用技术现状与研究

本文研究的重点之一是如何实现海量数据的加工,而且要在规定的时间窗口内完成指定的数据加工处理任务,否则,从业务角度看就是失败的。这一点的提出要求我们研究和应用先进的存储和计算技术,以及使用ETL技术对业务数据进行提取。

1.1网络存储的研究

早期的存储系统是计算机系统的一部分,大多以存储设备形式出现。随着网络的发展,数据的存储也逐渐由单机向多机方式和专用机发展,数据的共享与传递也逐渐从依赖主机系统向依赖网络系统发展。在大型企业应用和Internet发布系统中,安装数十台服务器已经很常见。但过于分散的数据资源,会给访问和管理带来困难。因此,数据存储问题备受关注。存储系统大致可以分成三种类型:

直接依附存储系统(Direct Attached Storage,DAS)又称为以服务器为中心的存储体系。其特征为存储设备是通用服务器的一部分。数据的输入/输出由服务器负责,数据访问与操作系统、文件系统和服务程序紧密相关。当用户数量增加或服务器正在提供服务时,响应会变慢。在网络带宽足够的情况下,服务器本身成为数据输入/输出的瓶颈。

网络依附存储系统(Network Attached Storage,NAS)这种存储方式多采用专用数据服务器。该服务器不再承担应用服务,称之为“瘦服务器”(Thin Server)。数据服务器通过局域网的接口与应用服务器连接。由于采用局域网上通用数据传输协议,如NFS,CIFS等,所以能够在异构的服务器间共享数据。NAS也是一种集中化数据存储形式,便于维护和管理。

存储区域网络(Storage Area Network)采用高速数据连接通道—光纤通道(Fiber Channel,FC)连接服务器和存储系统。从结构上看,服务器和数据存储系统相互独立。将设备连接到FC集线器或交换机上,便于扩展系统规模。FC的传输速率和可靠性极高,能够满足当前视/音频业务的需求。在SAN中,所有的存储设备和存储数据均可采用中心化管理,使得整个存储系统具有可伸缩性。并且,可以通过存储设备的集群方式而达到高可用度。

从软件角度看,NAS是应用与存储分离的系统,应用服务器通过局域网(LAN)访问文件存储系统,通常NAS以标准化访问协议(如NFS)提供服务;在SAN中,文件系统与存储系统完全分离,存储系统实际上成为运行应用程序服务器的设备,二者以高速FC连接。

1.2ETL技术的研究

企业的信息系统往往是一个由传统系统、不兼容数据源、数据库与应用所共同构成的复杂数据集合,各个部分之间不能彼此交流,这些数据的来源、格式不一样,导致了数据整合的难度,企业非常希望有一个全面的解决方案来解脱自己的困境,解决数据一致性与集成化问题,从而能够从所有传统环境与平台中采集数据,并利用一个单一解决方案对其进行高效的转换,这种解决方案就是ETL(Extraction,Transformation and Loading)。

从实际角度,ETL的使用包括数据抽取、数据传输、数据转换与清洗、数据加载、调度监控以及元数据管理等。

2 平台的总体设计

组件由一段执行码组成,通过对相应的控件资源的调用完成设定功能的执行模块。组件通过有序的组合,构成组件执行序列即流程,完成所要实现的功能。本节对UDI平台建设需要实现的功能进行分析,包括技术合规性检查、元数据管理、数据接入服务、数据组织和管理服务、数据提交服务、安全控管、系统监控管理等组件,并在此基础上依据组件设计的思想进行组合,提出统一数据交换平台的总体架构。

2.1 UDI的功能分析

2.1.1 技术合规性检查

按照UDI数据标准和目标系统的要求,针对数据格式所进行的检查,包括数据属性与值域检查、代码表引用检查、中文乱码和半个汉字等检查。

2.1.2 元数据管理

简单地说,元数据是“关于数据的数据”。包括业务性元数据,主要指数据的业务定义、计算公式、修改规则等;技术性元数据,主要指数据结构(数据表和字段)的定义和转换规则等;操作性元数据,主要指作业运行日志、数据保留期间、加载频率等。UDI系统重点是实现基于技术性元数据的元数据驱动服务以及对元数据的管理服务。

2.1.3 数据接入服务

负责源系统数据向UDI的接入,包括与源系统的连接、源系统数据的获取以及源系统数据向UDI标准数据的转换,特别要考虑系统面对大数据量和有限处理时间条件下的处理能力。UDI平台支持的转换规则如:格式与类型、数据翻译、数据连接、数据合并、数据排序、数据计算、码制转换等。

2.2 数据组织和管理服务

数据组织和管理是实现“目标系统通过UDI屏蔽对源系统的数据要求”的关键,UDI对进入其标准数据的源系统数据不做结构上的改变,对这些数据可以重新进行组织,这样可以满足目标系统对数据的多样性需求,并逐步形成UDI的数据标准和接口标准,统一UDI的数据管理流程和作业流程。

2.3 数据提交服务

负责由UDI标准数据向目标系统的数据转换和分发管理,包括按目标系统要求所进行的技术性转换以及对待提交数据的管理。

UDI作为批量数据交换平台基础设施,所以与源系统必须制定规范的数据交换协议标准,综合考虑源系统安全性,性能问题,传输效率等等原因,UDI系统与源系统之间不采用数据库直连标准,如ODBC等连接方式。

采用FTP协议作为源系统与UDI之间的数据交换协议,那么就得约定与源系统之间的数据准备就绪标准与检查方式,要求UDI平台支持数据就绪标记文件和时间约定方式。

2.4 安全控管

UDI总体安全控制分成:系统层安全性(如操作系统)、应用层安全性(如针对数据存储的安全加密措施,针对应用数据在网络传输过程中,采取的应用层加密控制等等)、网络层安全性(如采用防火墙,VPN等网络安全技术)。

2.5 监控管理

与管理流程相对应的对整个系统运行环境的管理,包括系统接入管理、转换配置管理、运行配置管理、日常作业管理和系统恢复管理等。

2.6 数据存储设计

2.6.1 存储方案的选择

基于NAS、SAN的存储系统都是完全独立的,不存在与服务器之间紧密的、依赖性的物理硬连接,都可以构造中心化的数据存储系统。二者都可通过冗余的硬件配置和软件支持做到安全可靠的保护数据,都具有良好的扩充能力和数据共享能力,都能实现中心化的数据管理。

在扩展能力方面,SAN通过多个FC交换机的级联,理论上可连接几十万个设备,要优于NAS。另外,NAS的系统访问能力受限于LAN的速率和服务质量,而SAN采用光纤技术,能提供高达1Gb/s的速率,数据访问速度优于NAS。

NAS的设计使得网络中的通用服务器可以从繁重的文件存储功能上解放出来。从具体的系统实施来讲,NAS有自己非常明显的优势。

首先,NAS结构简单,易于实现。只需将NAS文件服务器连接到LAN,进行简单的配置即可实现数据共享。而SAN至少要在每台服务器上安装一块HBA及其驱动程序,当服务器数量较多时,还要添加FC交换机,网络布线和系统配置都较复杂。术语“即插即用”对于SAN来说并不适用,至少还需要一段时间来达到。

其次,NAS易于实现多个局域网子网段的存储共享。

综上所述,结合银行实际情况,UDI的数据存储最终选择NAS存储方式。

2.6.2 存储方案的设计

UDI系统的数据共享主要分为UDI应用处理器之间的数据共享和ETL主辅节点之间的数据交换两种情形。其中ETL主辅节点的数据交换由ETL工具自身来实现。

服务所用的数据存储在集群文件系统中的磁盘设备组上。这种设置首先数据是高可用的,也就是说,因为磁盘是多主机的,如果当前主节点的路径出现问题,访问能换到可直接访问这些磁盘的另一节点。其次,因为数据在集群文件系统上,所以可以从任何集群节点上直接查看它,而不必过问此节点与存储设备是否有物理连接。可以像常规设备那样使用全局设备。UDI共享设计方案如图所示。

2.7 数据加工设计

应对数据源的数据提取可以有两种方案,一种是设定一种类型,比如关系数据库,作为统一的源类型,其他类型首先转换到关系数据库表中,然后再实施提取;另一种方案是直接选用数据提取的中间件产品,比如Ascential Datastage等。

如将数据装入数据库,再进行提取,文件在服务器上有转换、装载、抽取的环节。来自源系统的数据使用文件形式,数据量很大, UDI初始全量数据约820G,把文件Load到数据库中是需要时间的,同时,数据库通常会用到索引,Enable索引比较慢,因而效率要差一些。而采用中间件产品,如ETL工具,可以直接将接收到源文件进行提取,根据节点个数设置并行处理进程,提取后结果文件直接发送到目标系统,这样不用经过“数据落地”的中间环节,处理效率比较高。

UDI平台的数据逻辑加工处理最终采用Ascential公司的DataStage ETL工具进行规划设计,UDI平台一部分组件是基于ETL工具的进行开发(ETL工具开发语言 SCRIPT),另外一部分组件需要采用开发语言进行开发,统一规划成AIX下C/C++。管理数据库采用Informix数据库,任务调度和监控通过ODBC与数据库连接。

统一数据交换平台项目作为建行基础设施的建设,已成功投入运营。当前接入源系统有五个(DCCN、DCCS、CMIS、国际卡、证券等),接入目标系统有四个(BDB、ECIF、OCRM、IPSS等)。平台在功能上满足了建行核心系统与外围系统之间的批量数据交换需要。

参考文献:

[1] 周敬利,余胜生.网络存储原理与技术[M].北京:清华大学出版社,2005.

统一管理平台 篇3

关键词：水务数据,统一交换,共享平台,管理平台

0 引言

近年来上海水务部门陆续开展了大量信息化建设工作,实现了与国家防总、水利部、全市水务系统、气象、海洋和海事等多个部门互联的水务专网;建成了涵盖供水,排水,水利3大行业,用于防汛抗旱指挥、水资源管理、水环境治理、水务工程管理等不同业务目标的近50余套信息系统;累积了从1998年以来超过1TB数据量的多比例尺、多时相的数字地形图和遥感影像资料。这些系统的建成,为开展“智能水网”建设提供了必备网络条件和大量数据资料。而“智能水网”的建设离不开跨单位、部门、系统的数据交换和信息共享。

结合上海水务信息化发展实际情况,运用满足水务一体化管理工作需求的多目标、任务和层次的统一数据交换与共享管理技术,设计了水务数据统一交换管理平台,支持水务数据在多源、异构的不同系统间实现数据交换、信息流转。对水务数据实现有机整合、共享共用进行了有益研究和实践。

1 问题的提出

上海水务现有各单位信息系统及数据库建设受当时信息技术限制和建设理念局限,各系统存在系统架构多样,数据库结构不同,数据格式不同等问题:各系统由于建设年代不同,存在C/S与B/S架构并存,Java,.Net与其他工业组态软件并存,各应用系统独立开发,很难有效整合;数据库同时存在SQL Server,Oracle,SyBase,DB2等多种类型;数据表设计不同、数据多源异构、技术路线差异极大,难以实行高效的数据交换及共享;各系统应用目标单一、缺乏信息共享与联动,难以满足行业管理决策的支持需求。

同时,在水务数据统一交换管理平台未建设之前,各单位信息系统及数据库之间所采用的数据交换主要是传统的“点对点交换模式”,即应用系统之间数据库直连的紧耦合交换模式。由于这种数据交换模式需要对2端系统进行源码级开发,在对原有系统稳定性产生一定影响的同时,随着交换单位需求越来越多样,其数据交换复杂度也会与日俱增,数据交换将由一对一变成一对多甚至是多对多,相应的数据交换规则和程序开发量将呈几何倍数增长,最后形成蛛网状。这种交换模式既难以开发也难以维护,改动一点,可能导致数据交换甚至业务系统的瘫痪,将很难适应水务发展需求。

因此建设1套行之有效的能够满足全市水务行业需求的水务数据统一交换管理平台,解决“信息孤岛”现象,实现水务行业内各部门之间,以及与其它行业之间的数据共享和联动,形成数据及时有效的更新机制,成为当前水务部门亟待解决的课题。

2 方案的设计

水务数据统一交换管理平台设计目的是满足市水务局层面政府决策、综合管理工作对数据集成、数据挖掘和综合业务分析应用的需求。在市水务局已完成水务数据中心框架构建的基础上,建立1个统一的数据交换平台,简化规范行业条线应用对数据交换共享和管理的操作,协调信息资源的共享共用,满足供水,排水,水利3大行业间对数据综合调用的块状应用需求,实现面向应用的数据监控,集中管理和运行维护,提供高灵活、稳定、可用和易扩展性的功能支持。

水务数据统一交换管理平台位置示意如图1所示,连接了水务数据中心和应用系统、各行业基础数据库等,主要提供数据库连接和中间层服务。水务数据交换系统通过对各行业基础数据库进行数据抽取,异构处理和数据归并等方式,将数据传输、汇聚和存储到水务数据中心,并提供相关单位之间的数据交换和共享;为水务数据中心中面向专题应用的数据仓库提供数据统一访问和交换接口,为各类应用系统提供数据支持和应用服务支持。

根据上海水务综合管理中存在静态,实时和资源目录3大类数据的情况,我们设计了能够实现统一汇聚、规范整合、规范发布的基于数据总线技术的数据交换平台。在这种模式下,所有应用系统或行业基础数据库不直接连接中心数据库进行数据交换,而是连向数据交换平台,由交换平台统一维护各个信息系统之间的接口、协调信息资源、对各个信息系统做数据交换共享。随着参与的系统增加和数据量的不断加大,其可扩展和稳定性等方面的表现就越来越突出,更能适应信息系统规模的扩大和业务工作的不断发展。

水务数据交换平台结构示意如图2所示,虚线框内所示的水务数据统一交换管理平台主要由数据交换和管理2大部分组成。

2.1 数据交换部分

主要基于数据总线技术来实现对水务数据中心的基础、实时、政务、业务和元数据类数据与各单位信息系统之间的统一数据交换。在上海水务数据交换应用中,我们基于IBM Message Broker中间件平台,根据数据更新的不同要求进行了数据交换的二次开发和定制,有针对性地设计了水务数据实时和静态交换方式,并设计了用于获取水务数据中心中存储数据的信息资源检索接口。

2.1.1 实时数据交换

主要针对由实时采集信息系统生成的数据及部分以数据记录形式存储在数据库中并及时更新的政务类数据,采用统一的数据交换中间件平台进行实时数据交换。在不改变原有系统的情况下,支持数据在多源异构的系统和数据库之间交换,实现各类水务实时数据的无缝流转,实现对实时数据的集中、发布、路由、交换与同步,将经过汇聚,整合,规范后的水务核心数据集中存储到水务数据中心,并能为将来构建其它信息系统提供数据规范接口。

2.1.2 静态数据交换

针对数据更新频率不高且以文件或图片形式(如基础数字地形图、遥感影像数据、行政许可的附件资料等)保存的基础类和部分政务类数据,通过数据总线采用统一的文件数据定期拷贝形式进行数据交换。

2.1.3 信息资源检索接口

基于XML设计,用于水务数据监控管理部分与水务数据中心、数据统一交换平台之间协调通信,实现对水务数据中心存储的数据的编目、审核、目录检索、统计分析等功能,为数据需求单位,数据管理单位及时掌握水务数据的供需需求提供了索引指南和资源目录。通过创新信息资源编目、资源公开属性审核、目录交换管理、目录检索及其统计分析,实现信息资源目录的共享。

2.2 水务数据监控与管理部分

主要用于满足不同层面水务从业人员对数据的管理和应用需求,分接入、交换和应用层3个层面进行应用设计,水务数据统一交换管理平台数据管理功能架构如图3所示。

2.2.1 接入层

主要针对市水务局各局属单位和行业管理部门的信息技术专业人员进行设计。设计能够满足信息技术专业人员对各自单位信息系统及其数据库运行维护管理需求的一系列实用便捷的功能,实现对数据库运行状态、连接情况、交换状态、异常报警等监控管理;提供交换监控、数据管理、故障报警、异常预警等应用服务,为信息技术专业人员及时掌握信息系统及其数据库运行状态提供有效、实时的监控和管理手段,减轻对系统及数据库的运维工作量,缓解人工检查信息系统及数据库状态的劳动强度。

2.2.2 交换层

主要针对市水务局信息化主管部门负责数据中心运行的专业管理人员进行设计。设计能够提供对全局供水,排水,水利3大行业相关信息系统与水务数据中心之间数据汇集、路由、订阅与发布、整合与质量管控等交换全过程的可视化监控,管理和配置等应用服务;提供无关计算机技术、简化、便捷、可视化的交换配置工具,实现随需随用、灵活调整的数据交换策略,有效降低对数据中心管理人员计算机专业技能水平的要求;此外还提供对数据交换过程中所发现的传输延时、交换中断、数据异常等情况进行在线监控和预警,一旦发现异常情况,通过短信等即时通讯手段及时告知数据中心管理人员。

2.2.3 应用层

主要面向市水务局机关和相关行业管理单位的领导和业务人员,基于面向水务专题应用的数据挖掘技术,提供能够满足各种行业管理应用和政府管理应用的数据报表、统计分析、趋势预测、评价评估等功能。该决策层面针对水务行业从业人员多而水务信息化从业人员少的特点,功能设计应实现与信息技术的无关性,力求降低水务行业从业人员运用本平台的门槛。

3 关键技术

3.1 基于消息中间件的统一数据交换技术

为了解决以往局属各单位之间网状数据交换带来的管理混乱和资源浪费,我们采用了基于消息中间件的统一数据交换技术进行数据交换,并以数据服务的形式提供了对JSON,XML和Web Service数据服务的标准接口支持,在上海水务行业中规范了同构、异构系统间进行信息共享、数据交换的方法,形成了系统之间数据交换的标准,规范并统一了数据交换中数据采集、发布、交换、路由、同步等各环节。

1)数据采集:各单位实时数据通过该平台经由数据抓取、甄别、汇聚、规范和整合等过程以统一规范的格式汇集到水务核心数据库。

2)数据发布:各单位可以根据各自需要定制所需业务数据,该平台按照数据属性、目的地、归属单位等条件,进行相关组合,并根据这些定制信息进行数据发布。

3)数据交换:通过统一消息中间件建立数据订阅和发布的单位之间的信息隧道,支持同步和异步交换2种方式,实现各单位之间多源异构数据的业务逻辑、数值转换、数据统计和规范整合,使各信息系统之间的信息能够更方便地共享和交互。

4)信息路由:水务业务流程复杂,会涉及多个单位的协同。这些流程对协同办公要求都比较高。在这些流程里,在不同环节调用不同来源的、存放在不同数据库中的数据,就需要交换系统具备信息路由功能,在具体业务流程的运行中,配合相应的1个或多个系统,在不同的环节采集、提供、处理并发布各类定制信息,实现数据的交互流转。

5)数据同步:由于数据源众多且分散布设,当某单位采集的某个信息发生变化时,相关单位都需要尽早根据这个信息更新自己数据库中的数据。数据同步可以根据不同的业务数据的实时性需求,设置同步参数,保证关键业务数据的实时性,不会让关键数据被淹没在海量的数据流中。为了减少网络故障对数据同步的影响,数据交换系统能够在网络恢复后自动恢复同步,保证数据同步的及时稳定。

3.2 基于J2EE框架的数据监控与进程管理技术

运用基于J2EE框架的跨平台开发技术,降低了对多源异构系统开发数据监控和管理模块的复杂性,实现了对XML,WCF,J S O N等标准数据接口的支持,提供了对现有系统的无缝集成。由于采用了MVC系统开发模式,把业务逻辑代码从表现层中清晰的分离出来,避免了表现层与业务逻辑层的代码混叠,实现了数据监控与管理平台功能扩充的易扩展和可持续性,简化了开发与后期维护的复杂度,拥有高性能、可靠及可扩展性的优势,能够满足未来不断增加的水务数据交换的监控和管理需求。

同时,为了减轻该平台后期运维中所需要投入的大量人力成本,我们基于J2EE框架开发了针对数据交换进程的智能管理程序。在该进程管理程序中模拟系统运维人员对数据交换关键环节的状态判断,对各种数据交换事件的状态情况进行智能研判,及时修正并恢复数据交换作业,最大限度减轻了系统运维人员在数据交换环节中的运维工作量。

4 系统功能的实现

4.1 统一数据交换与共享

基于统一消息中间件构成的数据总线,实现了市水务局及其局属单位、区县水务局、太湖局、国家防总、气象局等其他行业单位共27家单位52套应用系统与水务数据中心之间的数据交换与共享。

防汛数据交换方面实现了潮位预报、报汛水情、实时雨情、风速风向、积水监测、台风信息、闸泵工况、下立交积水、水务热线灾情、防洪工程数据、太湖水情、气象信息等数据的订阅和发布。

水资源数据交换方面实现了水资源取供用排多个环节相关的原水水厂、供水管网、供水测压点、供水水质、供水水量等数据的订阅和发布。

4.2 集中数据监管

为满足水务数据统一交换、集中数据监管的应用需要,基于B/S架构,设计了水务数据统一交换和共享管理平台,完成了交换平台、数据中心等功能模块。

在交换平台模块中,实现了对数据源端,交换端,目的端3个关键环节的数据采集、数据发布、交换效率、故障统计、数据交换情况统计、数据完整性、数据奇异性预警等功能。

数据中心模块中,实现对数据中心涉及的数据库运行状态、数据库配置、用户权限管理、数据交换节点注册等集中管理功能。

4.3 智能交换监控

为减轻数据中心管理人员的运行维护工作强度,专门设计了具有智能监控系统交换进程的守护程序,用于在线智能判断数据交换平台的运行情况,一旦发现数据交换平台中某一交换进程停止响应或出现其它问题,守护进程会采取相应措施,自动终止有问题的交换进程,并重新启动该交换进程程序,最大限度地保证相关数据交换的顺利进行。

4.4 面向应用的数据服务

以防汛、水资源应用为试点,针对防汛业务专题进行数据挖掘,实现了雨量、水位、风速风向、道路积水、水闸工况、泵站运行情况等相关数据的图表显示,单因子统计查询,多因子趋势分析等功能;针对水资源业务专题,实现了对水量日报、水质日报、水厂监测、供水泵站监测、管网监测、骨干河道水质评价、水功能区达标评价、河道综合指数评价等功能。面向水务业务应用提供了统一标准的数据服务和应用接口。

5 应用效果

水务数据交换和监控管理平台的建设,简化了市水务局与局属各单位之间、与区县水务局之间、与行业相关单位之间多源,异构的数据交换与共享;有效推动了信息资源的整合、共享、交换与应用;避免了由于规范标准不一、数据接口不一所带来的行业之间,部门之间的信息孤岛现象;辅助政府部门大大降低了信息化建设运维成本。

通过对水务数据交换和监控管理平台设计,对提炼出科学合理,行之有效的适合水务一体化管理需求的水务数据中心建设规范、水务行业基础数据库及其管理系统建设导则、水务公共信息平台运行维护规程等标准规范,具有促进的意义。

6 结语

本文提出的水务数据交换和监控管理平台的建设,在上海水务系统中探索了基于统一数据交换的数据总线模式实现资源整合和信息共享的新路子,对提升水务行业基础管理,提高各部门各单位的工作协同,提升政府公共服务水平起到很好的辅助作用。

参考文献

[1]潘大四.基于XML的异构数据库数据集成的关键技术研究[D].重庆:重庆大学,2004:1-74.

[2]曹成,舒坚,蔡轲,等.一种基于ebXML的数据交换系统架构[J].江西:江西师范大学学报(自然科学版),2007(3):316-320.

[3]徐俊杰.基于XML的数据交换模型研究[D].黑龙江:哈尔滨工程大学,2006:1-62.

[4]李冬睿.基于XML与Web Service的电子政务数据交换模型的设计与实现[D].广西:广西师范大学,2008:23-47.

[5]杨剑.基于XML的异构数据交换系统的研究与实现[D].四川:西南交通大学,2005:19-74.

统一管理平台 篇4

关键词：统一认证信息化web服务

一、前言

随着企业信息建设进程的逐步深入，企业内部运行的应用系统也随之增加.传统上这些应用系统各自拥有一套用户及不同的身份认证方式，结果造成多套用户共存及用户信息冗余，用户多密码记忆及多点登陆.这严重影响了用户使用的效率，并对整个系统的安全带来了极大的隐患.所以，在企业信息化建设过程必须通过科学的集中认证技术，实现应用系统的用户集中管理和统一认证，彻底改变各自为政，管理松散的用户管理模式，充分发挥企业内部网络管理维护部门的管理职责，规范用户操作行为。

二、平台建设工具的确定

无论是何种应用环境，都将面对不同的平台、不同的系统和不同的编程环境，要能最大可能地支持所有的平台、系统和编程环境，同时又要确保服务的实现代价保持相对固定。目前看来，选择基于规范的.net Web服务解决方案将是最佳的选择。

三、平台架构

1.统一身份管理

平台在统一、可伸缩、健壮的基础架构上有效的实现了用户分组管理、用户账号管理、用户角色管理和用户自注册等统一的身份管理功能。

分组管理：分组管理用户可以按照企业内部的用户、部门组织结构并分别进行管理。

用户账号管理：用户账号管理统一管理用户的账号信息，包括创建，修改，删除，或停止账号。当对一个账号进行上述操作时，即可改变其访问行为。

角色管理：为配合平台基于角色的授权机制。在管理中心，可以根据组织机构自身的特点及其职能职权的划分，创建各种角色，对其进行定义，为角色分配用户，通过用户的ID与角色映射。同时统一账号管理系统提供了基于Web的自注册服务功能。自注册系统使用户可以自己注册基本信息及其在各应用系统上的账号信息。

2.统一授权

在统一认证平台上注册企业内所有需要保护的应用系统，并对所有用户进行统一的授权。采用基于角色的授权机制，按照企业内部的组织结构划分角色，并为用户绑定角色。对于不同的角色分配不同应用系统的访问权限。

对于B/S结构的应用系统，统一身份认证平台可以为其提供基于URL的细粒度访问权限。为用户或组设置其可以访问的哪个Web系统的哪些页面可以访问，哪些页面不可以访问。同时对C/S系统的访问进行统一授权，为不同的用户角色提供不同的访问策略。

统一认证系统平台列出每一个应用系统下所具有的用户情况。在每个系统下查询用户情况，以直观的方式显示每一个资源下有权访问的用户信息。为不同的角色定制不同的访问策略。访问策略包括可以访问的资源和访问控制规则。访问规则设置灵活，如按时间段，网络IP.或MAC地址等，也可以根据组织结构不同需求定制不同的访问策略。

将各个应用系统的授权管理界面集中的统一授权管理平台，系统管理员从统一授权管理系统登陆进去后，即可实现对各自的应用系统进行授权。

3.统一身份认证

对访问企业内所有应用系统资源（B/S或C/S结构）的用户进行统一的身份认证，使用了Web服务实现了子系统和统一认证系统之间的交互验证。当子系统将用户重定向到统一登录系统的时候，验证的交互过程开始（如图二），详细步骤如下：

（1）统一登录系统获取用户的Session ID和登录名。

（2）统一登录系统将Session ID和登录名插入到数据库，产生一个随机的数据库ID。

（3）将Session ID和数据库ID结合起来，进行MD5加密。

（4）使用MD5密文和数据库ID构建一个登录等待页面，返回给用户。

（5）用户将登录等待页面中的信息自动提交给子系统。

（6）子系统通过Web服务将MD5密文和数据库ID提交回统一登录系统。

（7）统一登录系统查询数据库，并进行验证。

（8）统一登录系统返回用户登录名，并删除数据库中的登录记录。

（9）子系统与用户建立认证关系。

4.统一审计

统一审计功能主要依靠记录最终用户和管理人员的访问过程，建立一套全面的、有效的回溯和追查机制。可以让系统管理员实时监测用户对企业各应用系统的访问状态，及时发现非法访问事件，对出现的问题进行事后追溯和责任追究提供实证。通过对系统运行状态实时监控审计，还增强了系统的可维护性。统一审计主要完成访问行为审计、审计信息查询、审计信息防窜改等几大功能。

四、平台特点

1.实现了对多个业务系统的用户统一身份认证、单点登录和访问控制；

2.实现了认证过程中用户账户信息的安全传输；

3.系统的部署实施简便，且有强大的管理功能；

4.系统易于扩展，增加新的业务系统不影响其他业务系统的正常运行；

5.用户操作使用方便，形式上易于接受。

五、结束语

统一认证平台，基本实现了以下功能：

资源整合：认证平台以资源整合为中心，通过平台的管理系统和数据库，统一用户资源和各增值业务系统，实现用户的统一管理和访问控制，实现各系统资源的统筹管理。

身份认证和单点登录：认证平台通过统一的用户账户对用户身份进行认证，在通过平台认证后，用户可直接访问各个业务系统，实现用户身份认证信息的共享，从而达到多业务系统的单点登录。

相信随着统一认证平台的出现会改变目前认证方式简单以及员工多次重复登陆等弊端，提高企业员工工作效率。

参考文献：

[1]白珣.基于IT治理的企业IT风险管理框架的研究[D]. 中国海洋大学 2008.

[2]贵颖祺.基于LINQ TO SQL三层架构设计与实现[J].现代企业教育2012（22）.

统一管理平台 篇5

目前国内外管理信息系统主要采用客户/服务器 (C/S) 模式和浏览器/服务器 (B/S) 模式进行开发。这两种模式各有自己的优势和不足, 在不同的环境下根据实际情况可能采用C/S模式或者采用B/S模式, 用户有时希望管理信息系统软件既能以C/S模式运行, 又能以B/S模式运行。对于软件开发人员来说要实现这样的目标往往实际要编写出两个完成同样功能的管理信息系统软件, 一个采用C/S模式, 而另一个采用B/S模式, 相当于一个应用软件两次开发、两次部署, 这很大程度增加开发工作的难度, 成本和时间等。为了解决管理信息系统软件能够同时以两种模式下运行, 充分利用这两种模式的优势, 在此提出一种基于C/S与B/S的管理信息系统统一构建平台, 采用这种构建平台可以实现管理信息系统“一次开发、一次部署、两种模式无差异运行”的目标。

2. 系统实现的原理及解决方案

该平台采用的是一种三层结构模型, 在这种模型中, 应用层需要支持两类不同的客户端表示层:浏览器和智能客户端, 这两种不同的客户端也需要虚拟机的支持, 浏览器可以直接访问Web服务层, 通过虚拟机来访问应用服务层, 智能客户端可以直接访问应用服务层或者通过虚拟机访问应用服务层。

浏览器提供管理信息系统的人机交互接口, 在该结构模型中, 用户不仅可以通过浏览器浏览网页, 动态加载所需页面, 而且也要通过浏览器使用在C/S模式下开发的业务窗体。应用服务层负责接收来自Web服务器、虚拟机和智能客户端的请求。如果这些请求需要访问数据库, 则应用服务层通过数据库网关访问数据库, 由数据库执行相应的数据操作后, 将操作结果返回给应用服务层, 再由应用服务层提交给Web服务器、虚拟机或智能客户端;如果请求不需要访问数据库, 则直接由应用服务层处理后将结果提交给Web服务器、虚拟机或智能客户端。Web服务层接受远程或本地浏览器的Http请求, 根据Http请求, 如果是访问静态网页, 则在Web服务器文件系统中查找相应的静态网页, 如果是访问动态网页, 则启动应用服务器, 从应用服务器提取所需要的数据或者通过应用服务期从数据库层提取相关数据后生成动态网页, 再将网页传送给提出请求的浏览器。数据库层为整个管理信息系统提供底层的数据支持, 它负责管理和存储数据库。在接收到应用服务层的数据请求后, 执行相应的数据操作如查找、更新等, 如果有返回结果, 则将结果返回给应用服务层。

3. 系统开发的关键技术

(1) 组件技术

如果既希望在浏览器端利用C/S模式下业务窗体的强大的图形界面功能和数据处理功能, 又希望浏览器能像处理网页那样处理业务窗体, 浏览器端能够显示和运行业务窗体。组件是指可重用可替换的有明确功能和接口的软件单元, 可以被用来构造其它软件, 能够独立开发、部署。把C/S模式下的每一个窗体都采用组件技术进行开发, 这样每一个窗体都能独立部署在应用服务器上供客户端使用, 这样可以像B/S模式下的页面一样保持窗体的相对独立性, 根据需要动态加载。

(2) 虚拟机技术

在C/S模式开发出来的窗体在客户端运行时有自己的运行环境要求, 这些窗体不能直接在浏览器上显示和运行。要想它们能在浏览器端也能显示和运行, 除了采用前面的技术之外, 还必须在浏览器端模拟这些窗体在C/S中在客户端的运行环境。为了达到这一目标, 可以采用当前流行的虚拟机技术在浏览器中模拟窗体在C/S中客户端的运行环境, 并通过虚拟机动态加载所需要的窗体。

(3) 智能客户端技术

和B/S或C/S相比, 智能客户端应用程序因功能级别的不同而呈现出多种形式。智能客户端应用程序通常具有形形色色的要求, 因此在设计和实现方面会有极大的差异。智能客户端应用程序最大限度地利用了代码和数据部署在客户端上并且在本地执行和访问。智能客户端可以通过网络消耗和使用不同的服务和数据。

(4) 应用服务层技术

在实际中根据需要在应用服务器除了部署窗体外, 也可能部署其它资源, 如文档资源等。应用服务器需要对这些资源进行有效的管理, 同时需要对登陆服务器的用户的身份进行验证, 控制用户对窗体等资源的访问权限。并且应用服务器能够通过多种业界认可的数据库接口方法 (ADO、BDE、CORBA等) 访问目前流行的各种关系型数据库, 每一种接口访问不同的数据库需要提供不同的参数, 为了便于开发人员或用户访问和管理数据库, 需要在应用服务器中提供设置数据库访问接口和其它管理数据库的功能。

4. 总结

管理信息系统统一构建平台开发之后, 利用这种平台来开发系统可以极大减少软件开发人员的开发工作量, 软件开发人员在开发过程中无需再处理用户权限的分配, 数据库的配置与不同数据库之间的数据集成等问题;同时在c/s模式下开发的业务窗体可以在浏览器中运行, 开发人员也就无需再b/s模式下开发业务窗体可以减轻开发人员的开发工作量。用户在使用采用这种平台的软件时, 软件的维护、安装和升级也比较简单, 业务窗体在浏览器中运行时几乎可以得到和C/S客户端中运行一样的运行效果。

摘要：基于C/S与B/S的管理信息系统统一平台的构建可以使每一个业务逻辑只需进行“一次开发, 一次部署”, 用户就可以在C/S模式下通过客户端使用或在B/S模式下通过浏览器运行, 做到“两种模式无差异运行”。该平台采用的是一种三层结构模型, 利用组件技术开发业务窗体, 虚拟机技术提供窗体运行环境, 在应用服务层实现综合管理应用服务器上各类基本信息资源。

关键词：C/S,B/S,管理信息系统

参考文献

[1]廖仁全.基于C/S与B/S混合结构的教务管理系统设计和开发[D].西南财经大学, 2005

统一管理平台 篇6

1 基于目录服务的统一管理认证平台体系架构

数字化校园中有许多种类多样、功能各异的应用系统,学校教师、学生、管理者等用户往往需要使用多个不同的应用系统,如果各系统独立使用和存储管理一份不同的身份信息,分别进行身份认证,同一个用户就需要记忆多个不同的密码和身份,当他在使用不同的系统时就需要进行多次的登录,这对用户和系统管理来说都非常不便。通过建设统一的管理认证平台,就是要将分散的用户和权限进行统一、集中的管理,实现学校用户身份的统一认证和单点登录,用户只需通过一次身份认证,就可以进入具有相应权限的所有应用系统。

在目前比较先进的统一管理认证平台技术方案中,其后台数据库都采用了高效的LDAP(Lightweight Directory Access Protocol)轻量目录访问协议。LDAP是一种跨平台和标准的协议,具有数据存取速度快、几乎可以存储所有类型的数据,跨越平台和系统,同步复制和分布式服务,完善的安全控制等特点,并且因采用Internet的标准而得到业界的广泛认可。通过运用LDAP技术,可以构建分布式目录结构,存储各种类型的数据,并提供基于这些目录的高效访问。根据数字化校园中用户数据量大,具有统一管理认证系统的应用需求,以及LDAP的技术特点,在构建学校统一管理认证系统时采用LDAP目录服务是理想的技术方案。利用LDAP清晰的目录结构存放学校的组织结构、人员信息、资源和权限信息,以及作为数字证书的存放库,对学校用户认证信息进行有效组织和管理。

利用LDAP技术建立数字化校园统一管理认证平台,要着眼于各类应用系统的统一身份认证,如既要方便新建系统使用身份认证系统,又要兼顾已有的老系统,使老系统做尽可能小的改动就可以使用身份认证子系统,最大限度实现数据整合。统一管理认证平台建设的核心理念,是利用目录服务数据库来集中存储用户和各应用系统的信息,从而实现对用户的统一管理、统一认证和统一授权,同时实现对各类应用系统的访问控制,进而提高整个系统的整体性、可管理性和安全性。基于目录服务的统一管理认证平台总体上由目录服务、统一用户管理服务、统一身份认证服务和统一授权管理服务四大模块组成。该管理认证平台的体系结构如图1所示。

2 统一用户管理服务

统一用户管理服务主要管理学校用户的电子身份,通过它可以对所有信息系统中的人员进行统一管理,这是统一身份认证和授权管理的前提。数字化校园统一用户管理服务的目标,是完成学校各应用系统的用户信息整合,实现学校用户身份信息的集中统一管理,建立与各应用系统的同步机制,简化用户及其账号的管理复杂程度,降低系统管理的安全风险。

具体来说,数字化校园统一用户管理服务主要实现以下功能:

1) 注册管理。用户注册是指用户在统一管理认证平台中注册用户帐号,通过该帐号,可以对所有使用统一管理认证平台的学校应用系统进行登录。注册管理包括新用户注册和用户修改注册信息两部分。注册管理模块的功能主要包括启动、注册向导、登录、注销等。

2) 部门管理。部门管理即对部门信息进行统一管理,可以修改部门信息,增加、删除子部门。同时,将需要维护的部门信息,如部门的顺序号、名称、ID等数据同步到其他信息系统中。

3) 人员管理。人员管理即对人员信息进行管理,可以增加、删除和修改人员的信息,可以重置人员密码。同时将需要维护的人员信息,如人员的顺序号、姓名、ID、职务级别、所属部门等数据同步到其他信息系统中。

4) 人员信息查询。人员信息查询采用目录树的方式展示部门与人员的隶属关系,可以在相应的部门列表中按多种条件查询人员信息。列表中的人员姓名上有链接,可以链入查询用户的详细信息。

5) 用户自助服务。每个数字化校园登录用户都可以修改自己的通用信息,如电话号码、房间号等,这些信息条目由系统管理员设置。

6) 系统维护。系统维护对用户进行分组管理,包括维护组的信息,增加新组以添加一个新的用户分类方式;可以选择和配置系统同步方式,包括实时同步、定时同步;可以进行属性配置等。

3 统一身份认证服务

统一身份认证服务实现对校内所有用户的数字化身份认证,是数字化校园的安全门户入口。统一身份认证服务提供平台的核心基础服务,该服务建立在基于目录服务的统一用户管理的基础之上,用户在访问校园门户网站或各类应用系统时,将首先被指向统一身份认证中心进行认证。在整个认证系统中,其服务的对象包括数字化校园中接入统一管理认证平台的所有应用系统,统一身份认证能够提供快速、高效和安全的服务,已有应用系统接入改造小,系统具有灵活的扩展性、高可用性。

3.1 统一身份认证的特点

1) 提供统一的身份认证服务。统一身份认证可以为多个不同种类、不同形式的应用提供统一的认证服务,不需要应用系统独立开发、设计认证系统,为各类应用提供了统一的接入形式。

2) 支持多种认证方式。学校的不同应用系统的安全级别不同,使用环境不同,用户的习惯和操作熟练程度不同,统一认证服务具有很强的适应性,可以针对这些不同的应用特点,提供相适应的认证手段。

3) 统一与个性相结合的认证策略。统一身份认证针对不同的认证方式,既提供了统一的策略控制,各个应用系统也可以根据自身的需要进行个性化的策略设置,根据应用或用户类型的需求,设置个性化的认证策略,提高应用系统的分级管理安全。

3.2 身份认证服务方式的选择

统一管理认证平台通过定义符合学校特点的身份数据规范,并将其应用于每个用户身份,以管理这些用户对资源的访问。在此基础上实现单点登录(SSO),保证用户一次登录即可按照授权访问相应权限的所有资源。统一身份认证服务的设计,可采用认证方式与登录方式分层的设计,同时可平滑扩展多种登录方式,支持多级登录处理认证机制。目前主要有以下几种登录认证方式:

1) LDAP认证。LDAP认证方式是基于目录服务的统一管理认证系统的主要认证方式。使用该认证方式,用户的身份信息与口令存储在指定的LDAP目录中。当一个用户登录时,通过其提供的用户名称、口令与该LDAP目录中记录的该用户名称、口令信息进行比对,如一致则认证成功,反之则认证失败。

2) 数字证书认证。数字证书(CA)是目前最常用的一种比较安全的身份认证技术。数字证书技术是在PKI体系基础上实现的,用户不但可以通过数字证书完成身份认证,还可以进一步进行安全加密、数字签名等操作。数字证书的存储方式非常灵活,数字证书可被直接存储在计算机中,也可存储在智能卡或USB Key中。

3) RADIUS认证。RADIUS认证是利用外部拨号认证系统的一种认证机制,如果学校用户通过了外部拨号认证系统的认证,系统则认为此用户认证通过。

4) 通行码认证。通行码是统一身份认证支持的一种特有认证方式,用户遗忘或者丢失其他认证信息时,可以向管理员申请一次性使用的通行码口令进行身份认证,主要满足安全应急服务。通行码具备时效性和一次性特点,当使用过或者超出使用时间范围,其认证效力自动失效,有效地保证了系统的安全性和可靠性。

上述各种认证方式在安全性、易用性和部署成本上各不相同,在实践中可以针对不同的用户群与不同的应用需要,对所采用的认证方式进行个性化的设置。如在单点登录系统中,可以根据角色、用户、服务指定不同的认证方式,也可以在认证时直接指定认证模块和个性化的认证选项。

3.3 统一身份认证服务的一般流程

在统一身份认证服务中,对用户进行统一认证服务的一般流程如下:

1) 学校用户通过统一信息门户登录到所要进入的应用系统;

2) 应用系统向统一认证服务系统提交请求进行认证的用户信息;

3) 统一认证服务系统对所申请的用户信息进行验证,确认所申请的用户信息的有效性,或否定用户信息的有效性;

4) 统一认证服务系统在用户信息申请通过认证后,将该用户所属组信息返回给应用系统;

5) 对通过认证的用户信息申请,应用系统根据用户所在组的级别,授予该用户相应的访问权限。

4 统一授权管理服务

统一授权管理服务是在统一用户管理实施的基础上进行的,在实现了各应用系统账号的统一管理之后,对系统用户的访问权限进行集中和统一管理。根据数字化校园安全策略,通常采用基于角色的访问控制技术,提供对学校多应用系统进行有效的访问控制和授权管理功能,提高系统管理的效率。统一授权管理服务主要包括以下功能:

1) 应用管理。即对应用系统的管理,实现对应用系统的添加、修改、删除和停用/启用操作等。

2) 角色管理。即对用户角色的管理,对用户角色的添加、修改、删除操作等。对角色进行归类,可以按所属部门归类,如教务处、学生处、科研处等;可以按用户的职务级别归类,如校领导、院领导、系领导、室领导等;可以按用户的职位归类,如教学岗、管理岗、服务岗等;可以按群组归类,如XXX教研组等。

3) 权限配置管理。即对用户访问资源的授权进行管理,通过对用户组和角色与应用系统的关联关系进行创建和维护,确定用户对应用系统访问的授权。授权管理分为两类:一类是实体级授权,指主账号代表的自然人可以访问哪些资源的授权,主要通过统一用户管理和统一认证、授权管理的整合完成。另一类是实体内授权,主要指包括基于角色的授权和细粒度权限授权,一般通过整合应用中的角色模块实现。

4) 分级授权管理。建立全校的分级授权机制,每一个部门、院系办公室都可以参与授权管理。学校管理员负责将权限分配到业务部门、院系,每一个部门、院系办公室需要配有一个信息员管理本部门的角色创建、用户授权工作。

统一管理平台 篇7

就现有中国移动几十种营销案业务而言,均处于独立分散阶段,但都存在一定的共性,例如形成用户专款按月划拨,按月赠送费用等等,不同的是专款的类型、返费的金额、返费的时间等的不同。如能够提取精炼出所有营销案的共性,并进行个性化定制,势必大大增强营销案的应变能力,缩短开发周期,进而大幅度降低开发和维护费用,在激烈的市场竞争中占据领先地位。

1 现有业务分析

1.1 营销案模式

电信运营商若仅仅依靠国家标准资费是无法满足客户日新月异的需求的,因此,商家往往通过降低资费标准,或是提高预存优惠等策略来争取客户并赢得市场,合理的营销案是实现目标的主要手段。首先,营销人员借助经营分析系统得到具有指导性的分析意见,再根据具体的市场情况和收支计划指定适合本地区的营销方案,其后通过简单的配置,或者通过支撑中心的开发,得到符合需求的营销案,并最终推向市场。

1.2 营销案目标

指定营销案的目标就是吸引新客户,稳定老客户,在整体盈利的基础上对用户展开合理促销。

2 营销案业务整合分析

2.1 现有业务模式

Tuxedo是bea公司推出的中间件产品[1],支持多种主机与数据库,其主要作用是在表示层和数据层之间搭建高效可靠的业务层。当前,中国移动的业务实现就多是依赖tuxedo中间件和oracle数据库,并主要由其来实现业务调配和数据管理。

依照集团要求的解耦规范,整个业务支撑系统分为CRM系统和账务系统,相应负责客户关系和账务关系的协调与整合。两个系统独立存在,却又联系紧密,是BOSS系统中两个重要的、互相依存的子系统。子系统中,通信和数据一致性主要通过三种方式保证,一是物化视图,二是增量同步,三是工单处理。营销案的业务实现主要集中于tuxedo中间件上,从原理上则是在tuxedo上部署了N个服务供前台调用,如图1所示。

2.2 营销案整合业务可行性

现有营销案主要分为二码合一和普通营销案两种类型。其中,二码合一是指用户缴纳一定量话费后赠送手机,预存的话费按月返还,但机卡不能分离;普通的营销案则不要求手机绑定,满足办理条件即可参与。预存话费可分为活动预存、专用预存等,活动预存不做限制,专用预存则按月划拨,有的营销案还会赠送用户一定额度的费用。无论哪种营销案,都遵循以下共同属性:

(1)预存金额。营销活动办理均需要预存一定金额,该金额作为基础预存存入用户的某一项专款中,专款有消费期限,其类别和期限则因活动而异;

(2)话费返还。一般营销案的特点是用户按月用掉一定量的话费,每个月有可消费或者可返还的额度限制,返还方式则有按月划拨和按月充值;

(3)营销周期。每一款营销案都有其生存周期,多为一年到两年,在营销案周期内,预存为可使用状态,周期外进行回收;

(4)拆包分析。根据营销案要求的不同,对于用户是否拆包有着严格的规定,拆包不返费是大多数运营商的做法;

(5)转款原则。客户办理营销案后会采取一定的转款原则生成专款,但具体的转款原则依客户的预存种类确定,例如在所有可转预存(灰色)中,指定银行类预存不可使用。其转款原则如图2所示。

上述共同属性均会根据不同的业务进行相应的个性配置:

(1)专款类别和数量。每种营销案都对应不同的专款,但也有的营销案对应相同的专款,并且允许专款可分为多种;

(2)赠送预存款。营销案不同,会配置不同的赠费原则,包括赠送的金额和周期;

(3)转款原则。每种营销案的转入、转出账本都有各自的要求。

综上所述,若要实现规范化管理,必须使所有的差别形成可配机制,并对配置人员做到简单化,对于表示层做到透明化,对于业务逻辑做到统一化,由此即将各种业务有机地结合起来。

3 营销案技术整合分析

3.1 数据可配分析

由于该统一管理平台是建立在现有系统和业务基础之上的,不需要对数据库层面进行重新设计。但是由于现有业务已经严重依赖当前数据结构,因此实现营销案统一管理平台的前提是不更改已有数据结构,尽可能复用[2]已经成型的业务模型,在此基础之上,可以采取扩充数据结构的方式实现营销案统一管理平台。在所有业务逻辑中,最具代表性的就是转款原则,以下将就转款顺序的统一化进行介绍。

营销案办理中,逻辑较为灵活的是转款的顺序,不同的营销案对于转款顺序有着各不相同的要求,例如统一预存赠礼,正常的转款顺序是基于用户可转账本并依次按照已配置完成的顺序进行转款,生成营销案定制的预存回馈底线专款和预存赠礼活动专款。实例如下:

在SPAYTYPE表中配置了专款类别pay_type、支付顺序order_code,及可转标识trans_flag等,配置详情如表1所示。

如果产生了一种必须从POS机缴纳的专项预存中办理营销案并生成专款的需求,则在此之前的转款顺序就无法继续使用,又由于该配置表的合理性,并且多数程序正在应用,无法仅为此次需求更改原有配置,此时就要寻找其他的方法解决该问题。

如图3所示,可以尝试在原有转款顺序的原则下建立一张新的配置表SMARKETCASECFG来实现指定单一账本转出转入、指定账本集合转出转入。

转款配置方案如下:

方案一:按照原有转款顺序,指定一个账本集合,该集合可以只包含一个元素,也可以包含若干个元素,还可以允许用户根据要求自行配置;

方案二:由于账本元素一般较多,配置中必须提供反向配置,例如该方案提供除了元素5,其余均按原有转款顺序排列的功能。对于不允许某几个账本参与活动的业务来说,此方案要较为实用;

方案三:现有业务的实现均以所指定的转款顺序的执行为背景,但是考虑到后期升级以及用户配置的灵活性,在不违背原则的基础上,就需要预留出按照用户指定顺序进行转款的接口[3],因此,配置表除实现a、b两种方案外,还需要提供用户自行配置转款顺序的功能。

另外,所有技术的实现必须以准确和高效为前提,增加配置表的同时也必须保证合理的索引[4]与字段设计,避免给原有业务增添不必要的负担。实现配置化主要为了降低维护难度[5],所以增加的全部配置表都必须考虑到日后的可维护性,提供并预留足够多的接口以实现高度可配置化的设定目标。

3.2 逻辑可配分析

若要满足业务逻辑的配置要求,将数据进行简单配置并不够,必须进行更深入的可配置开发。可以抽象地认为,业务逻辑的实现是SQL的顺序执行,因此如果能够做到将业务实现中的SQL形成可配机制,业务的可配性也就可以得到满足。

3.2.1 SQL可配类型分析

由于业务层面不涉及DDL等SQL语句,而是只针对DML语句进行开发应用,因此可配性质只需要考虑增、删、改内容即可。DML语言的特点主要分为3类:

(1)DML类型。即确定该语句执行的是insert、update还是delete,不同类型的语句有不同的特点,必须区分其特点进行SQL的重新拼装;

(2)insert和update需要指明插入和更新的字段和值。不同的表和不同的业务都需要不同的字段和值;

(3)DML共有的where条件。根据不同业务给定的要求进行合理绑定。

3.2.2 SQL可配方案分析

Oracle数据库中,利用all_tab_cols表来存储物理表以及视图的字段信息,主要包括属主、表名、字段名、字段类型等,在使用时,只需要提供表名,即可得到其中字段信息。原则上,只要给出增删改的类型、表名、需要更改的字段和值以及条件,即可以拼装完成业务需要的DML语句。对于形成的SQL语句再加以严格的异常处理机制,即可开发得到完善的业务处理程序。

需要注意的是,有些业务在对主表操作的同时,需要记录历史表或者变更表,用来对业务操作进行跟踪统计等,因此,函数中必须考虑主表操作后的其他操作。

插入操作、删除操作、更新操作、删除触发插入变更历史表操作、更新触发插入历史表操作基本可以概括现有系统的所有表操作逻辑,其中变更表和历史表均在配置表中实现配置,以此方法配置得到的SQL还有一个重要的问题就是,表中字段的类型需要进行有效的获取和转换,在all_tab_cols中有一个字段data_type标识字段的类型。但是在主表数据进入变更表和历史表的时候,通常变更表和历史表的字段数都大于主表,常见的字段主要是操作时间和操作动作记录,因此对于主表没有的字段应采取可配机制。而且在入表的时候则应提供合理的数据库函数操作,例如trim()、to_date()、nvl()等函数,以防止破坏数据一致性的要求。

对于字段进行数据一致性的操作可以扩展到正表、变更表等一系列表中。对于前台,SQL的可配置化是透明的,只在技术实现的时候进行配置。可采取后台维护的策略,前台只提供相应的数据配置,而不是逻辑配置。

3.3 数据和逻辑统一

基于上文提出的数据和逻辑配置方案,就可以完全做到业务层面的统一。将营销案的共同属性封装成函数,再将其个性化属性进行合理的数据配置和逻辑配置,由此即形成了一个统一、可配置的营销案执行平台。此平台将融合现有营销案,并以最大可能性为后续营销案的改动提供可配置接口,其模式如图4所示。

在此,将现有tuxedo层多对多的服务调用情况整合成多对一的架构,可使得开发周期缩短、维护成本降低、tuxedo压力也相应减少,同时又配合了多进程方式,因而将有效缓解现有营销案乱、散、慢的问题局面,并得到显著改善。

4 结束语

本文通过分析当前电信部门的营销案业务以及实现模式,发现现有营销案存在乱、散、慢的不合理局面,对于营销案种类繁杂、冗余代码较多、开发周期过长等特点提出了解决方案,并在营销案整合的软件构成中提出了一种可以大大提高营销案开发以及维护灵活度的SQL可配方案。最终,利用SQL可配置化和数据可配置化实现统一营销案平台,该平台建立在高度可配置化的基础之上,具有较强的健壮性和灵活性。同时也能够在很大程度上降低电信部门在营销案业务开发中的投入,提高电信部门的市场竞争力。

摘要：在电信行业的发展中,如何吸引新客户并挽留老客户,是运营商面临的首要问题,营销案则属于运营商的主要手段,通过赠送费用吸引新老客户参与,通过营销案的执行周期挽留老用户。随着社会不断的发展,运营商之间的竞争关系不断强化,营销案也逐渐多样化、个性化。原有的系统模型很难满足不断发展的营销案要求,亟需对营销案有一个整体、统一的规划和实施。建立一种统一的、高效的、可配置的平台弥补现有平台维护开销大、开发周期长、功能单一化的不足来满足营销案不断发展的要求已势在必行。

关键词：营销案,统一平台,可配置

参考文献

[1]徐春金.Tuxedo中间件开发与配置[M].北京:中国电力出版社,2003.

[2]PRESSMAN R S.Software engineering a practitioner's approa-c[M].北京:机械工业出版社,2011.

[3]SOMMERVILLE I.Software engineering[M].北京:机械工业出版社,2011.

[4]MORTON K,OSBORNE K,SAND R,et al.Oracle SQL高级编程[M].北京:人民邮电出版社,2011.

统一管理平台 篇8

关键词：科技业务,统一平台管理,广东省

“十一五”期间,我国电子政务向纵深发展,很多部门的电子政务建设从政务公开向业务网上办理过渡,一站式、全流程、协同办公、跨部门、信息整合、资源共享成为这一时期的重点研究内容。广东省是全国电子政务建设发展较快的省份之一,作为广东省级科技主管部门,广东省科技厅一直高度重视电子政务建设工作。2007年,广东省科技厅建设了本部门的科技业务管理系统,实现了部门内业务一站式全流程管理服务,有效提高了省级科技业务信息化管理水平。研究和设计广东省科技业务统一管理平台,目的是充分利用广东省科技业务综合管理系统已有的网络和设备资源,建设市县级科技业务管理系统,推进各市县科技业务信息化建设进程,加强省市县三级科技业务信息资源的整合、共享,全面提高广东省科技业务的信息化管理水平,提高全省各级科技管理部门的业务管理水平和服务能力,促进全省科技对社会经济发展的支撑和引领作用。

1 广东省科技业务信息化管理现状

广东省科技主管部门包括广东省科技厅、各地市科技主管部门、各县(区)科技主管部门三级,开展的科技业务则包括国家科技业务、省级科技业务、市级科技业务、县(区)级科技业务。各级科技主管部门的职能一方面是向上一级科技主管部门推荐业务并协同管理,一方面是为本地区的科技、经济和社会建设服务,制定科技政策、进行科技规划布局,对本地区科技项目进行资助管理等。目前,全省各级科技主管部门科技业务信息化管理的总体情况如表1所示。

从表1来看,广东省科技业务信息化管理的特点如下:

(1)全省科技业务信息化管理水平参差不齐。省级科技业务实现了“业务一站式”、“全流程信息化”、“业务处理自助式”管理,走在全国各省市的前列。部分经济实力较发达的地市,如深圳、广州等,其科技业务信息化管理水平较高;部分经济实力较薄弱的市、县(区),其科技业务信息化管理还比较落后,甚者只实现了单个业务C/S申报软件或只提供了Word格式申报书模板下载服务,根本没有后期业务的信息化管理服务。

(2)各科技业务管理系统基本上处于“信息孤岛”状态。各系统数据格式各异,信息不能整合,资源难以共享,严重阻碍了科技业务信息化进程,影响了各级科技主管部门的公共服务能力和业务管理水平。一方面,广大的科技工作者需要登录省、市、县(区)级科技主管部门各自的网站或系统查看有关业务动态或具体项目申报指南,而各级科技业务管理系统的资源不能共享则容易导致其错失或漏掉部分申报信息,失去参与的机会,同时在获取信息资源过程中需要反复登录不同网站或系统并重复录入相同信息,重复劳动多,工作效率低;另一方面,由于各网站和系统之间不能对接,无法满足科技主管部门彼此之间共享和协作的需求,制约了科技主管部门的业务管理水平提升。

2 广东省科技业务统一管理平台研究

在研究广东省科技业务统一管理平台之前,我们通过网上调查的方式全面了解了全国科技业务管理系统的建设和服务情况。调查结果显示,目前全国没有一个省建设了省市县三级科技业务统一管理平台。国内一些信息化发展较好的省级科技主管部门建设了本部门一站式全流程管理系统,部分落后的省级科技主管部门还在采用单机版软件进行项目申报。在这种情况下,研究和设计广东全省科技业务统一管理平台意义重大。

2.1 服务内容研究

进行广东省科技业务统一管理平台研究,我们的目标重点是提升政府在以下两个方面的能力:一是政府的公共服务能力,二是政府的行政管理效能。公共服务能力是政府为社会公众提供服务的能力。在本平台中,主要考虑方便企事业单位办理科技业务,包括申报机会集成、工作帐号集成、工作界面集成、单位和个人信息的共享共用服务等。行政管理效能是指政府内部工作效率的提高和管理决策能力的提升。在本平台中,主要考虑提高科技业务办理效率和管理决策能力,包括工作帐号集成、工作界面集成,统计分析集成、项目查重集成、专家库和专家评审服务共享共用、信用信息共享共用等。因此,在平台建设中的主要服务内容如下:

(1)申报机会。提供均等的申报机会,对于登录系统的企事业单位和个人,平台提供统一的申报机会服务,即将平台中所有科技主管部门的通知信息、申报信息、申报指南信息等统一发布在平台上,方便各企事业单位和个人查阅。

(2)单点登录服务。一次登录平台,不用退出,即可办理不同科技主管部门的在平台中的所有科技业务。

(3)共建共享数据信息。提供数据信息共建共享服务,一次性录入信息,在办理任何一级科技业务时都可以共享共用,无需重新录入;同时,提供一处修改处处更新服务,使每个功能下调用的数据信息保持一致。

(4)共享科技咨询专家。提供两方面服务:一是各级科技主管部门都能使用平台专家库中的专家,提高科技项目评审质量;二是专家工作集成服务,将系统中各级科技主管部门需要专家评审的项目集成在一起,方便专家处理,避免因工作分散而被遗漏的情况发生。

(5)共享科技信用信息。对权限范围内的各级科技主管部门用户开放各类相关单位和人员的信用评价信息以供参考,提高科技项目的立项质量。

(6)项目查重服务。实现科技项目在全平台查重服务,避免科研不端行为发生。

2.2 关键问题研究

广东全省有1个省级科技主管部门、21个地级市科技主管部门、100多个县(区)级科技主管部门,各主管部门业务有的几十种,有的几种,并且同一业务在不同的主管部门中其管理内容和流程略有差别,这些业务如果集中在一个平台、一个数据库进行管理,需要构建超大规模和异常复杂的业务模型、数据模型和流程模型,极易出现平台性能差和并发性等问题;同时,全省科技业务信息汇聚成海量的科技资源,如何从海量的资源中挖掘出各级科技主管部门需要的信息,并将其发布的相关信息安全地递送到相关用户界面,充分满足全省科技业务管理协作服务,这是目前电子政务迫切需要解决的问题。

由于传统的集中统一平台管理模式的局限性,无法解决全省科技业务统一管理的需求,因此,我们采用了应用分布式+数据共享集中式平台框架。在该平台框架下,将各级科技主管部门的业务管理系统布置在应用平台上,实现各业务系统完全自治,互不影响,即将一个大的系统分解成N个相同或类式的子系统进行管理,这能很好地解决系统性能差和并发性问题。由于这些子系统以广东省科技业务综合管理系统为原型进行开发,因此具有部署快、系统完善、成熟、稳定的特点。数据共享集中平台则主要实现科技管理协作服务,包括提供全省科技信息共享和业务协作服务接口,实现业务和共享协作的合理分工等。

(1)建立覆盖广东全省的省市县各级科技管理部门的科技业务综合管理网络节点。以广东省科技业务综合管理系统为原型,开发建设各级科技主管部门的业务管理系统,快速实现业务部署、业务内容修改、业务流程修改、主管部门增减、邮件短信服务、信息维护等功能。

(2)建设全省科技业务共建共享数据库。实现全省科技业务用户库、申报指南库、项目库、专家库、信用库的共建共享,包括广东省科技业务统一管理平台的框架组成,科技主管部门、各企事业单位和个人共享协作需求和有用有效的共享数据和协作功能,协作基础数据库的内容和标准,各级科技主管部门的业务管理系统与协作基础数据库的连通功能,以及所有服务实现的核心算法、系统功能等。

(3)实现省市县各级业务管理系统的互连。打破全省科技业务不同单位、不同信息系统之间的“信息孤岛”状态,实现全省科技主管部门之间业务协作,包括具体主管部门的受理项目在全省的查重、各企事业单位和个人在全省的信用和项目资助情况查询、部门间联合资助、上下级的配套资助、全省共用科技咨询专家等。

(4)为各企事业单位和个人 、科技咨询专家提供全省一站式服务。对平台内的所有企事业单位和个人提供一套帐号全平台服务,包括全省申报机会查询、一站式省市县科技业务处理;对科技咨询专家提供全省一站式网上评审管理和服务。

3 广东省科技业务统一管理平台设计

3.1 系统结构

3.1.1 总体框架。

广东省科技业务统一管理平台的总体框架分三个层次,包括协作科技业务管理层、协作交互服务层、协作基础数据层(见图1)。

·协作科技业务管理层主要实现以下服务:一是以广东省科技业务综合管理系统为原型,开发建设各级科技主管部门的业务管理系统,这些业务管理系统独立运行,实现本级科技主管部门所在地区科技业务的一站式全流程管理。二是通过协作交互服务,各企事业单位和个人可以在本单位所在的省市县业务管理系统无缝切换,处理相关业务。三是各级科技主管部门可以共建共享协作基础数据库的数据和信息。

·协作交互服务层主要为各类服务和接口,由协作基础数据库提供的各类服务接口,协作科技业务管理层调用接口把需共享的各数据同步到协作基础数据层;同时,协作科技业务管理层也调用各类服务接口查询协作基础数据层的各类数据库信息。

·协作基础数据层。处理、存储和管理各类协作基础数据,包括用户信息库、申报机会库、项目信息库、科技信用库、科技咨询专家库等,并对外提供接口和服务。

3.1.2 科技业务管理系统。

科技业务管理系统是以广东省科技业务综合管理系统为原型,结合各级科技主管部门实际需求开发的具体业务子系统,系统实现了具体科技主管部门的业务一站式全流程管理,该系统主要由三部分组成:业务层、中间层、数据存储层(见图2)。

·业务层为具体科技管理系统的功能模块,包括:单位注册管理,业务申报管理、评审管理,项目立项管理,合同签定以及项目拨款管理,项目跟踪管理,信息发布和系统维护管理等。

·中间层包括各类中间接口和组件构件库。主要接口有门户框架、统一认证接口,邮件短信接口,监察对接接口;构件库是一组业务功能构件,每个业务功能构件都实现为一个(自治、粗粒度、松散耦合的)服务。

·数据存储层是具体科技主管理部门、申报人、申报单位的个性数据和共性数据的元数据存储库。

3.1.3 协作基础数据层。

协作基础数据层为全省科技主管部门提供科技数据共享和协作服务。主要由数据层、业务服务层、表现层三部分组成(见图3)。

数据层主要存储并管理包括用户信息库、申报机会库、项目信息库、科技信用库、科技咨询专家库等五大类数据。

·业务服务层分信息收集和共享协作两大类服务。其中,信息收集服务主要包括用户统一注册服务、各类项目采集服务、申报机会采集服务、科技咨询专家共享设置服务、各类信用采集服务等;共享协作服务主要包括单点登录认证、各类项目查询查重、申报机会查询订阅、共享科技咨询专家评审服务、各类信用查询服务等。

·表现层为各项功能页面和对外服务接口。提供直接访问协作基础数据层功能页面服务,也可以在各科技业务管理系统通过接口建设共享数据或调用协作基础数据层页面,获取许可的共享数据。

3.2 系统功能及特点

根据全省科技主管部门一站式全流程科技业务管理需求,广东省科技业务统一管理平台设计了科技业务管理、基础数据库管理和统一用户管理三大功能。

科技业务管理功能提供了具体科技主管部门一站式全流程科技业务管理服务,实现系统各类用户对科技业务从计划编制到申报、评审、合同签订、过程管理、验收直至归档的全流程协同处理。

基础数据库管理功能实现了采集平台中各类共建共享信息,将信息提供给符合权限要求的用户,并为各类用户在整个平台的单点登录、项目查重、项目申报机会查询等系统服务提供统一的数据。

统一用户管理功能是在基础数据库的基础上,对整个平台上各业务子系统的用户实现以下数据的统一处理服务,包括申报机会、项目查重、专家共享、单点登录、信用共享等。

这三大功能的设计和建设,体现了广东省科技业务统一管理平台的以下特点:

(1)独立灵活的业务定制服务。各级主管部门可对系统进行二次开发,包括可以灵活定制本部门系统页面风格、具体业务的申报、管理流程,根据部门实际情况增开管理处室、特色业务,改变辖下单位在本系统中的主管部门等。各级科技主管部门除了需要投入一定的技术力量外,基本上不会发生其它费用,节约了行政成本,提高了业务信息化管理水平,提升了部门业务管理能力。

(2)完全的基础数据共享。系统中所有企事业单位和个人、科技咨询专家等用户的基本信息资源实现共享,各类业务信息资源自动归类管理,而所有数据信息来源于平台中的各系统、服务于平台中的各系统,但是不影响平台中任何系统的独立正常运作。

(3)统一的共享数据服务。在平台中,通过协作基础数据层的各项接口服务,实现整个平台数据资源共享服务,用户界面统一规范,操作简单易行。

(4)广泛的适用性。本平台虽然是为广东省市县三级科技业务信息化管理设计,但其灵活的表单和流程定制服务同样适用于其他政府部门网上业务的处理及应用,具有较为广泛的适用性。

4 关键技术研究

根据广东省科技业务统一管理平台的框架结构和设计,我们主要采用了远程通信、消息通信、共享信息、单点登录和个性化推荐算法等技术和服务来支持平台建设。

4.1 高效的远程通信技术

在实现各级科技主管部门之间数据共享和业务协作时,除了常用的EAI方案,我们增加了Web Service技术作为系统互连的方式,并研究出新的基于http的通信协议;同时,结合序列化和反序列化的方式进行远程通信协议,使不同的系统之间的传输效率比基于xml技术的webservice提高了约8倍,很好地解决了各个科技业务系统之间地理位置跨度大、Internet防火墙等问题。但是,该方案要求其他现有的业务系统改造时,也需要部署自己开发设计的通信协议程序包,非标准实现通信协议。

4.2 高可用性的消息通信技术

目前,市面上默认的各种开源MQ服务器基本不提供高可用性方面的支持,为了提高MQ服务器高可用性,我们针对平台主要做了如下改进,包括队列冗余寻址、提供MQ服务器故障自动检测、提供服务自动恢复、提供自动配置、设计应用程序寻址等,较好地解决了平台运行中动态寻找队列和接受队列消息的问题,实现了动态添加的成员系统在数据交换时的高可用性,并且避免了单一MQ服务节点发生故障后造成所有相关系统停止运行情况的发生。

4.3 基于元数据标准的共享信息技术

通过制定元数据标准(基于XML Schema)、利用缓存技术、采用批更新的方式,将项目/单位/人员信息中最基本的特征信息抽取出来,组成项目/单位/人员信息编目,存放在协作基础数据库中,以支持跨系统的查询/统计服务。元数据标准的制定统一了各成员系统中共享信息编目的格式,这些编目信息根据各成员系统设定的批更新策略,定期将变动的信息编目送至协作基础数据库。当编目信息较多时,则采用缓存技术,以增加吞吐量和减少响应时间,提高平台服务性能。该技术解决了成员系统数据安全性问题和共享信息更新问题,由于不能实时同步数据,因此有发生数据不一致的可能。

4.4 单点登录

用户第一次登录完成后,系统为其设置统一的用户标识,作为访问各相关系统的凭据,此后用户每次登录即可以访问平台中相关的许可功能,无需进行重复登录。单点登录是支持平台用户一次登录处处访问的关键。由于平台中各系统采用了不同的验证模式,因此,我们主要解决了支持多种验证模式的单点登录服务。

4.5 个性化推荐算法

通过数据挖掘和提取技术,进行分析、综合、归类、匹配,将符合平台相关用户的各种信息自动推荐给他们,提供更加友好、人性化的科技服务,避免了从海量信息中搜寻相关信息需要花费的大量时间和精力,提高了平台各用户的工作效率。

5 结论

本文对广东省科技业务统一管理平台的服务内容、关键技术进行了研究,主要成果如下:

(1)提出省市县三级科技业务统一管理平台,在国内科技管理领域首次实现省市县三级管理部门的科技业务共享和协作。(2)为各企事业单位和个人提供全省科技业务一站式全流程服务,有效提高全省科技主管部门的公共服务能力。

(3)实现全省科技资源优化和统筹,加强相关部门、行业以及地方的协调配合,建立健全科技业务协调机制,优化科技资源,减少配置分散或重复现象。

(4)实现全省科技业务信息化管理的集约化发展,最大限度地减少资源性、基础性项目的重复投入,有效提高社会资源的利用效率。

参考文献

[1]王长胜,张新红,于施洋.中国电子政务发展报告[M].北京:社会科学文献出版社,2007

[2]姚国章,吴倚天,林萍,等.中国电子政务案例[M].北京:北京大学出版社,2006

[3]蔡桂兰.广东省科技业务信息化管理现状及发展分析[J].科技管理研究,2010(10):161-163

[4]洪丹丹.统一身份认证服务器的研究与实现[J].中国教育信息化,2011(2):16-18

[5]罗晓斌,董守斌,徐浩,等.基于JMS的异步消息处理技术及应用[J].计算机工程,2002(12):121-122

[7]CHU SEONG-EUN,KANG DAE-WOOK,KIM JAE-NAM,etal.Efficient Implementations of Remote Method Invocation Consider-ing Object Consistency[J].Cheju Island:Hybrid Information Tech-nology,9-11 Nov.2006:634?641

[8]JOHNSON R,HOELLER J,DONALD K,et al.Spring FrameworkReference Documentation[EB/OL].Internet:http://static.spri-ngsource.org/spring/docs/3.0.x/spring-framework-reference/html/remoting.html,2011

统一管理平台 篇9

9月25日，财政部公布了《关于切实做好地方预决算公开工作的通知》（以下简称《通知》），《通知》规定，县级以上地方财政部门要建立预决算公开统一平台，从2017年起将本级政府预决算、部门预决算在平台上集中公开，方便社会公众查阅和监督。

《通知》称，监督检查发现，地方预决算公开还存在一些突出问题，主要是主动公开意识不强，主体责任履行不力，未公开部门预决算的单位较多，已公开的预决算不同程度存在不够细化、时间滞后、公开渠道不规范的问题。为解决上述问题，地方各级财政部门和各部门要进一步改进预决算编制，提高预决算的完整性、规范性、準确性，切实细化预决算内容，为公开预决算创造良好条件。县级以上地方财政部门要建立预决算公开统一平台，在现有公开渠道的基础上，进一步拓宽公开渠道，改进公开方式，从2017年起将本级政府预决算、部门预决算在平台上集中公开，以方便社会公众查阅和监督。

《通知》要求，各地要及早布置2017年预决算公开工作。对2017年预决算公开工作，地方各级财政部门和各部门要及早谋划，提前部署。要依法依规公开预决算，除涉及国家秘密外应公开事项，不得少公开、不公开，并将强化监督检查和认真落实追责制度，发现一起、曝光一起、纠正一起。

统一管理平台 篇10

目前电力系统中的故障录波器在应用中还存在着很多不足之处[3,4]。故障录波器的生产厂家多,型号多样,有时候即便用的是同一个生产厂家的产品,也由于其生产年份和型号不同,导致了录波数据格式和通信协议不统一的状况,这给事故后的故障分析和故障过程模拟再现带来了极大不便;各录波器传输方式和协议的不同,给利用网络方式实现故障录波器统一管理造成不便。另外,数据结构、软件接口的不统一,使得故障录波器厂家每出一种新的产品,就需要提供一套新的后台分析软件,这在造成重复工作的同时,也大大减弱了对故障录波器进行联合管理的实用性和有效性。

针对上述现象,在对当前大量故障录波装置进行广泛深入研究的基础上,针对目前管理软件上的不足,开发了故障录波数据统一管理分析平台,将数据文件转换为标准COMTRADE数据格式,在客户端实现对全网故障录波器远程录波、实时监测、文件传输、故障分析、谐波分析等功能。

1 平台架构

1.1 平台的模式结构

目前国内多数录波数据管理系统采用单机版的模式,这在一定程度上给管理带来不便。本文设计的故障录波统一管理分析平台采用客户端/服务器(C/S)的结构模式,在客户端能够实现更方便的管理。平台的C/S模式结构如图1所示。

平台C/S模式结构主要由客户端主机、通信服务器、数据库服务器和录波器终端构成。通信服务器实现与录波装置的通信,信息和数据存储在数据库服务器中,和服务器连接的其他主机为客户端。客户端主机通过与通信服务器和数据库服务器通信来实现对全网故障录波装置和文件的各种管理分析功能。

1.2 平台的整体架构

统一管理分析平台按照C/S模式,其具体的模块化结构如图2所示。

由图2中可以看出,通信服务器主要包括通信模块、文件解析模块和文件转换模块;数据库服务器则负责数据接收、解析及后续处理;客户端主机根据需要来与服务器间通信,实现波形再现、故障分析、谐波分析、报表打印等功能。

2 功能组件

管理分析平台采用模块化设计,由多个模块之间协调合作来满足所有的功能需求,具有良好的扩展性和可移植性,并且大大降低了程序内部的耦合性。平台各功能组件的基本功能如下。

2.1 客户端管理系统

采用MFC编写的软件用户界面主要由录波器窗口、结果显示窗口和状态显示窗口组成。管理人员首先在主界面的目录树中选择一台故障录波器,然后可以进行状态查询、参数设置、录波文件检索等。检索的结果可以直接在结果显示窗口中以列表的形式显示出来,并且用不同的图标来表示文件是在本地硬盘或是在远处主机上。在检索结果中选择文件,可以进一步执行波形再现功能,进行故障分析、谐波分析、功率与频率分析等。分析结果会在弹出的新界面上显示。不同线路的波形以红、黄、蓝3种颜色交替显示,既美观又容易识别。状态显示窗口用来实时显示各个故障录波器的工作状态、管理人员操作日志等,并可以形成文件保存到硬盘上。平台中的各种故障分析模块都可以用来供客户端管理系统随时调用。

2.2 通信和文件转换模块

考虑到目前实际应用中的故障录波器所支持的通信方式有串口、拨号和网络通信3种,而本系统旨在实现在客户终端对各个录波器进行统一的管理分析,那么,就需要平台的通信模块能够满足各种型号故障录波器的需要,对每种通信方式都制定一套数据传输的通信规约。在实际应用时,平台根据录波器通信方式的选择来灵活调用,建立连接并根据命令类型进行文件传输、远程校时、远程录波、实时监测等功能。

为了能够对各种型号录波器的录波数据文件进行统一的分析,使得录波器管理工作更加便利快捷,平台采用IEEE于1999年修订的标准COMTRADE数据格式。平台通过通信模块接收到文件之后,立即根据该故障录波器的型号选择相应的文件解析模块进行文件解析,然后再按照COMTRADE数据格式的要求实现数据文件的格式转换。

2.3 数据管理模块

平台管理如此多的故障录波器会涉及大量的数据,如何对这些数据进行合理的管理,也是直接关系到整个平台的有效性和工作效率。数据管理模块主要实现对各个故障录波器运行信息、参数文件和录波文件的存储、读取、添加、删除等功能。

为了保证在进行数据分析时所参考的录波器的参数文件是相符合的,每次在进行数据文件传输时,都要传送一次最新的参数文件。数据管理模块将转换后的数据文件按照地区、变电站、录波器的三级文件夹顺序有序存放,为每台录波器建立一个以该录波器名称命名的文件夹,然后再根据其不同批次的录波文件建立新的文件夹,里面除了存放转换后的数据文件,还有一起接收到的该录波器的参数文件。另外,每个录波器的其他相关信息(比如其IP地址,是否上传,连接状态,工作日志等)对整个平台的管理工作来说是相当重要的,且实时性要求较高。为管理好这部分信息,又建立了Access数据库来进行管理,包括操作日志和录波器的工作状态,根据录波器运行状况实时更新。

3 关键技术

为了建立统一管理分析平台,对全网故障录波器进行有效管理,该平台采用的关键技术主要有统一数据结构的建立、数据的统一管理和统一分析等。

3.1 统一数据结构的建立

考虑到该平台所管理的故障录波器数目多,而每个故障录波器中涉及的数据量都非常大,因此,构建一个较好的数据结构模式是关系到整个系统开发质量的关键。

统观整个平台的功能,其中涉及大量数据处理的操作主要分为2类:(1)故障录波器参数文件的解析和参数设置;(2)对录波数据文件的操作,包括故障分析、波形再现、谐波分析等。每种型号录波器参数不同,可根据型号分别制定一套数据结构。由于录波数据文件已经是转换为标准COMTRADE格式后的数据文件,所以各个型号故障录波器的数据文件可以用统一的分析模块来分析。这样,再制定一套统一的数据结构,用来与统一分析模块相对应。图3为平台的数据结构图。

每台故障录波器都对应有2套数据结构,一套是该型号录波器特有的数据结构(简称小结构),另一套是统一数据结构(即包含所有型号录波器特征的数据结构,简称大结构)。录波器参数文件解析后直接与其小结构相对应,同时,小结构还与录波器参数设置对话框对应。而大结构对应于平台中统一的波形再现、波形分析、故障分析等模块。大小结构之间可以实现互相赋值。这样整个平台的数据分2个层面,只要做好中间的传值工作,就能够更方便地实现平台的开发。

3.2 数据的统一管理

将各种型号录波器的数据文件格式统一起来,才能够更好地利用统一分析模块,实现数据的统一管理[5,6,7]。

平台采用的COMTRADE标准数据格式[8]中共有4类文件:头文件、配置文件、数据文件和信息文件。考虑到实际应用的需要,本平台省略了头文件和信息文件,将同一批次的录波数据文件转换为配置文件(.CFG)和数据文件(.DAT),且根据不同的批次和录波时间定义新的文件名称,存放在该录波器的同一批次文件夹内。

在数据转换中,需要根据数据文件内容定义新的数据结构,便于信息的转换(适用于所有型号录波器)。在配置文件中,为模拟量和数据量采集通道信息分别定义一个结构体:模拟量采集通道结构体str_AnaInfo中包含有模拟量通道序号、通道名称、相别、单位、放大倍数、偏移量、最大最小值等信息;开关量采集通道结构体str_DigInfo中包含有开关量通道序号、通道名称、相别、对应的电网设备名称等信息。另外再为数据文件定义一个数组,用来表示采样点序号、时间和采样数据。这样,录波文件经解析后直接实现统一格式的转换。

3.2 数据的统一分析

数据的统一分析是平台中比较重要的一部分,能直观地反映出整个平台功能实现的效果如何。由于此前已经对数据文件进行了标准格式的转换,就可以用统一的数据接口函数实现。

平台中用到了电力系统中的多种算法,又利用了MFC中所封装的大量绘图类的函数,来设计一个友好的图形用户界面(GUI)。

各分析功能的结果有独立的界面显示,可以很直观地看到故障发生时各通道的波形。各波形以多种颜色来区分表示,还可以进行有选择的放大、缩小等操作。

通过数据分析可以实现波形再现、故障分析、谐波矢量分析、功率与频率分析、阻抗圆图分析、阻抗轨迹、报表生成和打印等功能。

4 结束语

随着电力系统自动化水平日益提高,对调度端的管理水平也是一个很大的挑战。本文研究的数据统一管理分析平台可和多种型号故障录波器进行通信,较好地实现对多台录波器在线监测、录波文件传输、维护管理、录波文件、参数文件格式转换,以及录波文件的分析、打印等功能。平台采用模块化设计,不仅利于开发的实现,更使得日后的升级和维护都变得极为便利。

在数字化变电站迅速发展的今天,采用模块化设计和开放的程序接口,为以后向IEC 61850标准的衔接做了很好的铺垫。

本文设计的统一管理分析平台包含了国内某公司生产的各种型号故障录波器的通信规约、参数文件格式和录波数据文件格式。如果要向平台中添加新型号的故障录波器,只需要在该平台中添加与新录波器参数文件、数据文件相配套的文件解析和COMTRADE格式转换函数即可。目前,该平台已经在江浙一带的部分电力调度中心使用,并且运行状况良好。

参考文献

[1]周玉兰,许勇,王俊永,等.2000年全国电力系统继电保护与安全自动装置运行情况[J].电网技术,2001,25(8):63-66,75.

[2]任建文,周明,李庚银.电网故障信息综合分析及管理系统的研究[J].电网技术,2002,26(4):38-41.

[3]李媛,刘涤尘,杜新伟,等.电力故障波形再现及分析系统的开发[J].电网技术,2006,30(5):106-110.

[4]陈长德,张保会,魏春轩.故障录波数据集中分析与专家系统[J].中国电力,1999,32(9):40-43.

[5]郑敏,黄华林,吕鹏,等.故障录波数据通用分析与管理软件的设计[J].电网技术,2001,25(2):75-77.

[6]杜新伟,李媛,刘涤尘.电力故障录波数据综合处理系统[J].电力系统自动化,2006,30(12):75-78.

[7]张杰,涂东明,张克元.基于COMTRADE标准的故障录波的分析与再现[J].继电器,2000,28(11):20-22.