《综合管理服务平台.pdf》由会员分享,可在线阅读,更多相关《综合管理服务平台.pdf(47页珍藏版)》请在三一文库上搜索。
1、精品文档 . 1.1.ESB服务总线 1.1.1.概述 各业务系统提供大量的服务接口,如何实现这些服务和接口的编排、调用、 重组等, 我们采用的是应用服务总线的模式。 通用服务总线采用可靠消息服务 (不 丢失,不复传)在应用系统之间通过基于消息的异步方式集成各应用系统。 1.1.2.架构设计 DB 电子政务 接口 / 服务 综合监管 接口 / 服务 社会化服 务 接口 /服务 数据管理 接口 / 服务 服务总线动态路由实时服务异步服务服务注册服务查找 安全控制异常处理格式转换格式校验系统监控 发布订阅日志记录数据存取内容过滤系统管理 组织机构 接口 / 服务 权限 接口 / 服务 流程表单 接
2、口 / 服务 即时通讯 接口 / 服务 报表 接口 / 服务 ESB服务总线架构图 ESB服务总线是综合管理服务平台的一个中心组件,它负责接入各种服务资 源,通过采用统一服务接口使得各种服务或应用与服务之间可以相互方便访问, 以星形结构替代了原来各服务之间的点对点结构,极大地优化了系统连接架构, 降低了系统集成的复杂度。 1.1.3.功能设计 ESB应用服务总线基于消息交换组件开发。采用消息交换组件提供的可靠消 精品文档 . 息服务(不丢失, 不复传) 在应用系统之间通过基于消息的异步方式集成各应用 系统。针对不同系统所处理的消息格式各不相同的特点,ESB应用服务总线提供 了专门的格式代码转换
3、器在不同的消息格式之间按照预先定义好的转换规则进 行自动的格式转换, 然后将结果自动路由到目标应用系统。在消息转换的过程中 ESB应用服务总线能够识别XML ,C结构,JMS等多种消息格式; 对消息的各种操 作包括消息的来源、 消息的目标应用、 所期望的消息格式等通过定义各种操作规 则(Rules) 进行。 ESB应用服务总线可以作为一个消息代理来实现这些功能。 消息代理提供了消息传递层以及消息代理集线器,可被用于消息的处理、 转 换和分发,并能够将这些功能与发布/ 预订功能结合在一起。 ?应用程序格式转换和智能路由功能 作为各个应用的数据吞吐机, 提供多种数据格式服务, 其中包括: 用户自定
4、 义格式,用户可以为每一种应用定制自己的消息格式,通过这种消息格式来连接 原有的旧的应用; XML格式; 面向纪录的信息格式, 如 C的头文件, COBOL records 等。对于这些消息格式, 提供相应的剖析器进行解析, 实现它们之间的格式转换。 如对于用户的 bit stream的输入信息可以输出为XML的格式,反之亦然。从而 无缝地连接现有的应用, 并可以采用 XML的新标准开发新的应用。 提供检查和过 滤功能,根据所传输数据的内容做动态路由。 ?强大的数据处理功能 作为各个应用的数据处理机, 对经过 BPI 的数据进行各种处理操作, 如计算、 过滤等,使得数据在从 BPI 经过时便可
5、以被进行相应地计算,从而发往目的应用 系统;支持数据仓库, 对各应用系统所传输的数据进行集中记录,便于以后的审 计和分析。 ?对各种应用系统的接口功能 提供强大的连接性,既提供各种与现有商业应用连接的Adapter ,可以将企 业内部各种应用系统进行无缝连接,如 SAP , Notes, Sibel , SWIFT , People Soft , I2 等,支持各种标准数据格式或应用的接口,如XML , JDBC ,对于这些应用可 以不必开发新的接口, 减少开发的工作量; 同时提供应用程序接口, 以开发客户 化的连接件。 精品文档 . ?对各种接入协议的支持 ESB应用服务总线支持各种接入协议
6、,其中包括TCP/IP Socket,MQ ,SOAP , HTTP ,SCADA 等。 适配器技术选择 适配器完成的功能是实现应用系统与EAI HUB 之间的连接接口, 主要包括数 据与通讯两个层面。 在适配器设计与选型方面, EAI 技术提供的方案有多种形式, 根据不同的情况作不同的选择。 根据应用对外提供的接口的形式不同,下面对常 用的适配器类型进行分析。 ?基于数据库的接口与适配器 应用系统对外提供的接口是应用数据库,适配器通过对应用数据库的操作来 实现 EAI 与应用间的交互。此类接口是应用系统可对外提供的最底层的接口类 型,允许适配器直接访问应用的数据。针对此方式,尽管这也是常用方
7、式之一, 但其中有很多严重的不足。 使用数据作为应用的接口, 意味着将数据的结构体设计暴露出来。当应用发 生改变时,通常需要重新分析、 甚至改变此数据接口。 当应用系统的数据改变时, 为了触发外部应用, 通常需要使用基于应用数据库的外部触发器或使用低效的循 环查询策略,这不是一个”干净”的解决方案,外部应用对维护数据的完整性也 将负有责任, 为此需要理解需要集成的应用系统的结构。总之,其结果将是一个 难以维护的交错系统。 ?基于 API 的接口与适配器 应用软件,通常提供内置于软件库的API,作为与应用系统交互的接口。相 对数据库接口而言,此类接口是一个更为”干净”的解决方案。其问题是相对某
8、种平台,如操作系统、编程语言,此API 库可能不存在,为解决此问题,需要开 发底层的代码并进行长期的维护。同时当支撑其运行的产品进行升级时,通常需 要对此 API 进行升级以保证其兼容。 另外,基于 API 技术,当应用系统有事件发 生时,一般难以提供自动通知功能,需要外部系统进行低效的循环查询。 ?基于组件的接口与适配器 基于 J2EE与 CORBA 的分布式对象技术,使应用系统的接口有较好的可移植 性。此类接口,可以屏蔽操作系统、 编程语言的不同。 此类接口属于紧耦合模式, 精品文档 . 为发展中的技术, 由于应用系统本身需要提供组件接口,在实际应用中限制了其 应用。 ?基于消息队列的接口
9、与适配器 应用系统对外交互的接口为消息队列,同时提供消息/ 数据传输的可靠性保 障。业界领先的消息中间件同时提供同步、异步两种通讯方式。使用消息队列, 消息系统可以管理很多通讯细节。此种接口方式为典型松耦合模式,是 EAI 技术 普遍使用的方式之一,可以实现接口的重用能力。 成熟的商业适配器 J2EE(/Portal) 综合管理服务平台服务库 .NET客户机 C/S应用系统 XML/MQ 客户机 文本 /MQ 客户机 ESB 服务总线 第三方应用服 务器供应商 .NET供应商 传统定制服务 的供应商 B/S应用系统 Socket SOAP/HTTP TDS/MQ CSV/MQ XML/MQ 文
10、本 /MQ 文本 /JMS SWIFT/MQ CSV/HTTP SOAP/HTTP 文本 /Socket ESB应用服务总线支持的适配器 ESB应用服务总线提供了诸多的既有的适配器,包括技术适配器与应用适配 器,部分列表如下。 技术适配器: 1JDBC 2JMS 3MQ 4E-mail 5JText 6Microsoft Exchange 7Web Services 精品文档 . 应用适配器: 1SAP 2Siebel 3Spirent 4Ariba Buyer 5BroadVision 6Clarify 7eMatrix 8i2 9i2 ADW 10 Metasolv TBS 11 Nigh
11、tfire 12 Oracle Applications 13 PeopleSoft 14 Portal Infranet 15 QAD 16 Retek 17 Telcordia Service Delivery 18 Vantive 适配器开发 如果需要开发自己的适配器,ESB应用服务总线提供了相关的开发工具。对 外提供的适配器开发API,同时支持 Java、C+ ,如果应用系统采用中间件技术 是 J2EE应用服务器、 CORBA、CICS 、Tuxedo等,都可以很容易的完成适配器的 开发。 1.2.应用服务运行框架 1.2.1.总体框架描述 应用服务总体框架是国土资源综合管理服务平台项
12、目的核心,总体框架由系 精品文档 . 统微内核、系统服务层组成。系统微内核应能提供最基础、最核心的功能,包括 模块管理、生命周期、服务管理,为整个系统的稳定运行提供保障。系统服务层 应能够提供各类标准化的、技术性的服务如时间服务、审计日志、持久服务、缓 存服务、事件服务、事务服务、数据服务等。框架之上支持公共服务组件和业务 服务组件,共同组成综合管理服务平台。 1.2.2.总体框架组成 在本设计方案的总体结构图中, 把系统划分为五层, 而最底层的基础层提供 了系统运行的环境, 最上层的门户展现层提供的进入各个应用系统的入口。其中 应用支撑平台是系统的支撑层。 其中综合管理服务平台是系统的支撑层
13、。支撑层 包括的主要内容有:系统微内核、系统服务层。各层的主要功能分别描述如下。 资源层 系统管理 系统微内核 系统服务层 安 全 保 障 体 系 表现层 支 撑 层 1.2.2.1.系统微内核 系统本身采用微内核架构,实现模块化、动态化、服务化。微内核做为整个 系统的运行内核,仅提供最基础、最核心的功能,包括模块管理、生命周期、服 务管理,为整个系统的稳定运行提供保障,整个系统的各个部分都做为模块直接 或间接构建在微内核之上。 1.2.2.2.系统服务层 系统服务层还包含各类标准化的、技术性的服务, 而在应用服务层则提供功 能性的服务。系统服务层提供的服务有:时间服务、审计日志、持久服务、缓
14、存 服务、事件服务、事务服务、数据服务等。 本次项目的主要研讨内容为应用服务层中的各个服务组件,因此系统服务层 精品文档 . 中的基础服务组件将不做为本方案阐述的重点。 1.2.2.3.表现层描述 业务表现层是面对最终用户的接入口,利用综合门户等方式提供各种业务供 客户使用,向下须与面向服务的业务层通过正确定义的服务接口实现兼容。采用 的门户技术应该能够支持JSR168Portal规范, 能够自由部署第三方的标准Portal。 1.2.3.总体框架的地位和作用 1. 从技术复用到业务复用 当前的软件复用大多还是从技术角度出发的,例如J2EE领域的框架只是一 个以库、类和接口形式提供的基础架构,
15、最终构成应用的业务逻辑和表现/控制 逻辑则要由建立在这个框架上的业务组件实现。而应用软件最终要解决的却是应 用问题,或者说是业务问题, 如果软件能够在更高层次的业务层面上进行大范围 复用, 那么对提高软件开发效率的作用将会更大。只有采用面向服务的设计思想, 才能够在更高层次上实现业务复用。 2. 业务组件的支撑平台 由于上述的业务组件并不是一个可以独立运行的应用软件,所以需要为它们 提供一个赖以生存的运行基础核心底层机制,特别是组件的管理, 如组件的 创建、组件的获得、组件的资源管理、组件的消亡等生命周期支持;以及组件之 间相互通讯的渠道和方式。 3. 分布式部署的应用系统 如果应用系统只部署
16、在一台机器上,随着系统功能的增加和负载的加大,只 有不断提升机器的硬件配置。 我们希望能够把系统按照功能进行划分,以分布式 的方式进行部署, 将不同的功能模块部署在不同的服务器上,服务器的压力能够 有效的降低,使得系统可以以较低的成本继续保持高稳定性和高可用性。 以国土资源各类数据库为基础,以国土资源信息网络为依托,以标准、制度 和安全体系为保障,以地政、矿政、地质环境等主要管理业务流程优化为主线, 以支撑国土资源管理决策为核心,形成互联互通、 贯穿上下的政务管理、 决策支 持和社会服务信息化体系。 精品文档 . 1.2.4.功能设计 1.2.4.1.应用服务运行管理框架 应用服务运行管理框架
17、简称应用服务框架,是应用服务的运行、 监控、管理 的框架。 应用服务框架提供了统一的服务库注册、 存储、 查询的应用服务元数据信息, 提供了发布、调用应用服务的功能,可对应用服务及调用进行监控、管理,同时 提供了本地和远程调用,可支持分布式应用和负载均衡。 在不同的应用服务框架之间, 采用对等的分布式调用机制, 可注册远程的服 务库到本地。可通过应用服务框架之间的互操作调用,实现互联互通。 应用服务框架本身不提供访问控制的功能,但可借助访问控制服务模块实现 对应用服务的认证、授权和访问控制。 应用服务框架作为软件基础设施,通过部署在上面的服务模块, 以标准的协 议对外提供服务, 可实现更高层次
18、的软件复用和业务复用,可将原有应用系统中 可重用、可共享的功能单元服务化,利于应用系统整合。 应用服务框架提供高度可集成的能力,采用标准的Web 服务协议组作为服 务接口描述和调用规范,可屏蔽不同软件平台的差异,实现透明的互操作。 1.2.4.2.服务模块 服务模块是进行部署的最小单位, 是满足某些特定功能需求的一组相关应用 服务的集合,可以是软件包的形式, 也可以是第三方提供的应用服务集合的形式。 服务模块可通过元数据描述文件(附录A:服务组件描述模式schema )描述并 部署在应用服务框架上,也可通过应用服务框架提供的界面或API 来部署,由 应用服务框架实行统一的监控和管理。 1.2.
19、4.3.服务组件 服务组件是服务模块的基本组成元素和基本构建单位,是粒度最小的实现和 发布单元,是相关的一组应用服务的具体实现, 它的功能以应用服务的形式提供。 服务组件具有可设置的属性,其属性是可以改变服务功能的数据。 服务模块由一个或多个服务组件及相关配置信息构成。 精品文档 . 1.2.4.4.元数据 1. 元数据描述方法 采用摘要表示的方法定义和描述元数据,摘要包括以下属性: 中文名、英文 名、数据类型、值域、约束、说明。 中文名:元数据的中文名称,中文名称在同一类元数据中是唯一的。 英文名:元数据的英文名称, 英文名称在同一类元数据中是唯一的,比较时 不区分大小写。 可包含的字符为大
20、小写的英文字母、数字,所有组成词汇为无缝 连写。 元数据的数据类型。 值域:元数据可以取值的范围。 约束:元数据的约束性条件,包括是否非空、最大出现的次数、是否唯一。 说明:对元数据含义的进一步的解释及补充说明。 2. 应用服务及服务组件元数据 通过应用服务元数据对应用服务进行描述,发布、查找和调用应用服务时都 需使用元数据信息。 应用服务和服务组件都使用相同的元数据描述。本部分定义 了核心元数据,即所有应用服务描述中共性的、必不可少的元数据。 1.2.4.5.应用服务框架组成 应用服务工作原理图 精品文档 . 1. 工作原理 应用服务框架提供了应用服务的发布、注册、查找、调用、监控、管理功能
21、, 其中涉及三个角色: 服务提供者、服务请求者、 服务库。应用服务工作原理如下: 1) 服务提供者开发符合应用服务技术要求的功能单元,将开发好的功能发 布为应用服务,并将应用服务在服务库中注册。 2) 服务请求者在服务库中查找所需服务,根据返回的结果确定需要调用的 应用服务。 3) 服务请求者根据需要调用的应用服务,获得应用服务的代理对象。 4) 服务请求者发起调用请求,对应用服务进行实际调用,并获得服务返回 的结果。 5) 在整个提供服务的过程中,三个角色的基本功能如下: 6) 服务提供者:发布服务、进行注册。 7) 服务请求者:查找服务、调用服务。 8) 服务库:服务注册、服务查找、监控管
22、理。 2. 总体框架 如上图所示,应用服务框架由服务库、发布模块、调用模块、管理模块和监 控模块五部分组成。 服务库提供对应用服务元数据的注册、存储和查找功能,可以将服务模块、 服务组件和应用服务注册在服务库中。 发布模块提供将功能单元服务化的功能,读取并解析注册描述文件,将描述 在其中的接口发布为应用服务,并自动注册到服务库中。 精品文档 . 调用模块封装对应用服务的调用过程,屏蔽技术实现细节, 直接实现对应用 服务的调用,可与应用服务框架部署在一起, 也可单独部署在应用服务的调用端。 调用模块可将远程应用服务框架注册到本地,能对远程服务库查找和调用, 实现 不同应用服务框架之间的分布式调用
23、。 管理模块提供对服务模块、 组件和应用服务的管理功能, 通过访问控制服务 模块实现对应用服务的授权和访问控制,并提供UI 界面实现人机交互。 监控模块在记录应用服务调用日志的基础上提供审计、统计和分析功能, 可 监控和改变应用服务的运行状态。 1.2.4.6.接口定义 应用服务运行框架接口分为服务组件管理接口、服务模块管理接口、 应用服 务管理接口、服务库管理接口、获取应用服务接口五大类 1.3.资源目录建设 对全市国土资源系统信息资源进行梳理。建立全市国土资源系统信息资源目 录规划,以便将全市国土资源系统可共享资源库进行集中有序组织,方便用户资 源查找、数据检索和应用系统访问。 信息资源目
24、录体系主要负责各级国土资源部门共享信息资源库的标准化描 述和合理化组织。 其中信息资源库的描述主要针对信息资源库的数据存储、访问 方法和数据格式进行描述,是揭示信息资源库结构、指导用户使用的检索工具, 是用户迅速、 准确、有效地寻找信息的向导, 是对信息资源实施安全保护的有效 手段。 信息资源目录可根据市各级国土资源部门提供资源的情况,动态更新,及时 反映共享数据资源接入的情况。 是对信息资源实施安全保护的有效手段。其主要 功能是对各级国土资源部门的信息资源库进行合理规范的组织及维护,标准化的 描述信息资源库的访问方式、 应用规则和相互关系。 全市资源目录体系主要包括 三大基础目录,详细描述如
25、下: 精品文档 . 1.3.1.组织身份目录 建设全市国土资源系统统一的组织身份目录,实现全市国土资源系统组织身 份的统一管理和各业务系统的身份整合。组织身份目录指全市国土资源系统身份 及组织架构目录的结构设计、用户身份信息属性设计等。 全市国土资源系统统一身份库是以目录为基础建立的全面身份管理基础架 构。通过元目录的技术, 可以将各个独立的应用中的用户资源统一到一个元目录 进行集中管理。这种方法提供了单点管理,大大地简化了用户身份的管理。 在身份总库中建立统一的全市国土资源系统业务系统目录结构。身份总库作 为身份认证仓库,将用户的访问信息独立于应用程序来进行集中管理, 建立单一 的权威用户数
26、据库作为所有数据的数据源。同时,该基础架构对组织的授权管理 提供支持。身份管理基础架构为系统电子政务基础架构所提供的其他网络服务提 供了基础。 总库中的组织机构信息应与各级国土资源部门的全部组织机构信息完全吻 合,换句话说,就是将身份总库中的组织目录信息与各级国土资源部门身份库中 的全部内容保持同步。 1.3.1.1.建立组织模型规范及目录 制定全市组织模型规范, 统一规范电子政务系统中的组织身份数据模型,主 要包括政府部门机构、领导、人员、职位、岗位、职级、用户组、角色等实体对 象,以及各实体对象之间的关系。 根据组织模型规范, 梳理并建设全市组织身份目录。组织身份目录是通过对 政府机构现状
27、的调查来形成的。 该模型对于组织机构及其相关的身份职责进行了 完整的描述; 组织身份目录的重点在于职能岗位及其相应的职责,组织身份目录 可以认为是现状模型的体现,通过树状的层层细分,给出岗位和职责的映射。 组织身份目录模型图: 精品文档 . department PKdepartmentguid personMembers PKpersonMenbersguid presonguid department person PKpersonguid duty PKdutyguid level position PKpositionguid dutyguid departmentgui d leve
28、l PKguid positionperson PKpositionpersonguid personguid positonguid group PKgroupguid departmentguid groupperson PKgrouppersonguid personguid groupguid ROLE PKROLEGUID DEPARTMENTGUID ROLEPERSON PKROLEPERSON ROLEGUID PERSONGUID ROLEDEP PKROLEDEP DEPGUID ROLEGUID 1.3.1.2.提供组织身份目录规范的接口 提供规范的组织模型对外服务接口,
29、 所有注册在资源目录中的资源均可通过 API 接口获得,下图为平台为用户提供的接口文件列表: 精品文档 . 1.3.2.应用服务目录 建设全市国土资源系统统一的应用服务目录,为实现全市国土资源系统多业 务系统应用整合奠定基础。 网络管理员需要管理的应用系统很多。为了集中对各 应用系统中的各个功能进行授权控制,更好的为portal提供完整的应用系统信 息,我们在综合管理服务平台中提供应用系统管理服务。 在目录服务中建立一个指定的容器对象,将各应用系统以对象的形式存放在 该容器中,各应用系统的子模块及子功能均可以作为对象以树的方式存放在相应 的应用系统对象下。 每一个对象拥有相应的功能模块的基本信
30、息,如:名称、 URL 、 开发商、版本等信息。 通过应用服务目录的管理可以实现以下的几点: 1 为集中授权做好基础, 通过将各应用系统的功能映射到目录服务相应的 对象,就可以利用目录服务技术良好的安全控制机制。 2 可以集中为应用系统提供有关其他系统的结构及URL信息。为单点登录 和门户整合提供应用系统的管理支持。 1.3.3.信息资源目录 建设全市国土资源系统统一的信息资源目录,为实现全市国土资源系统信息 资源的统一描述与发现,为多部门信息资源的共享与整合提供资源环境基础。 信息资源目录体系主要负责全市国土资源系统共享信息资源库的标准化描 述和合理化组织。 其中信息资源库的描述主要针对信息
31、资源库的数据存储、访问 方法和数据格式进行描述,是揭示信息资源库结构、指导用户使用的检索工具, 是用户迅速、 准确、有效地寻找信息的向导, 是对信息资源实施安全保护的有效 手段,并服务于信息资源共享平台的资源查找和定位。 信息资源目录可根据全市各级国土资源部门提供资源的情况,动态更新,及 时反映共享数据资源接入的情况。 它是面向信息资源共享平台和全市国土资源系 统工作人员浏览和查询资源库信息的基础,是揭示信息资源库结构、 指导用户使 精品文档 . 用的检索工具,是用户迅速、准确、有效地寻找信息的向导,是对信息资源实施 安全保护的有效手段。 其主要功能是对全市国土资源系统的信息资源库进行合理 规
32、范的组织及维护,标准化的描述信息资源库的访问方式、 应用规则和相互关系。 信息资源目录体系采用目录服务技术和元数据标准相结合的方式进行实现。 目录服务技术目前已经成为国际上非常流行和通用的技术,其快速的查询效率和 强制性的安全管理特性为目录服务提供了良好的系统环境。国家有关资源库描述 的元数据标准对资源库的描述已经初步规范化,采用相关成熟的元数据标准有利 于对信息资源库的进行标准化描述和规范化定义。 1.3.3.1.资源服务的注册维护 资源库注册维护功能是为信息提供单位对可供共享的数据资源库在整个信 息资源目录体系中注册和元数据维护,以便其他单位能够及时准确地共享利用该 资源库的数据。其注册维
33、护的主要信息包括共享资源库访问的URL、联系人、 负责人等, 功能包括注册、 修改和注销等。 该功能只为全市信息中心平台管理员 和各共享资源库提供单位的管理员提供。 1.3.3.2.资源服务的目录组织 资源目录是将整个全市可共享资源库进行集中的有序组织,以方便用户资源 查找、数据检索和应用系统访问。 信息资源目录由各提供单位在本部门组织节点下分级管理。为了全市综合管 理服务平台管理员的集中管理和监控,资源目录对分布在市各部门组织目录不同 节点的资源库信息进行集中展现,其实现界面参考如下: 精品文档 . 1.3.3.3.共享资源的注册发布 通过信息资源目录实现对共享资源库的数据检索、列表及详细信
34、息查看等功 能。这些功能可以通过授权控制进行访问控制。 1.4.公共服务组件 公共服务组件应包括组织模型管理组件、 身份服务组件、访问控制服务组件、 各类业务流程服务组件、 各类业务电子表单组件、 单点登录组件、 通用 GIS引擎 服务组件以及非结构化数据管理组件等功能。 1.4.1.组织模型管理组件 组织模型管理组件实现对组织模型的管理服务,用来定义组织形式的模型, 以职责、权限的形式定义成员、 各个部门的作用与任务, 同时提供灵活的结构以 适应不同的部门或不同的组织结构。 本组件提供对组织模型的管理服务。 在本项目中根据组织模型规范, 梳理并建设全市国土资源系统党政机关电子 政务组织身份目
35、录。 组织身份目录是通过对政府机构现状调查来形成的。该模型 对于政府组织机构及其相关身份职责进行了完整描述;组织身份目录重点在于职 能岗位及其相应职责, 组织身份目录可以认为是现状模型体现,通过树状层层细 精品文档 . 分,给出岗位和职责映射。 组织模型的地位和作用 电子政务组织模型就是对政府组织结构进行建模,是利用抽象的模型或者元 素,构造出的一系列关系, 用于表达 政府组织机构中的实体间的层次和隶属。组 织模型是用来定义政府的组织形式的模型,它以职责、权限的形式定义了政府成 员、政府各个部门的作用与任务, 同时提供灵活的结构以适应不同的政府部门或 不同的组织结构。 组织模型是大部份电子政务
36、应用系统构建的基础。几乎所有的电子政务应用 系统都涉及到组织机构模型的建设, 一个组织机构模型的好坏直接影响到基于它 构建的其它应用系统。 组织机构模型对现实中的机构进行了抽象建模,提供了统一的概念和语义。 通过组织模型的建设能很好的解决电子政务应用中人员调动、权限变化、职 位变迁、部门合并、分级授权管理等各种业务问题 组织模型提供了一个统一的抽象,对用户统一集中管理,可管理多级用户, 支持用户分类分组、多种用户接口、用户权限安全等方面的管理。 组织模型为单点登录、 统一授权提供基础, 它为灵活授权、 统一管理提供了 基础。 组织模型支持各种业务应用 在当前的电子政务领域, 通常一个部门或一个
37、机构拥有多个应用系统,而这 些应用系统往往由多个厂家承建,他们基于不同的组织机构模型建立的,虽然它 们面对的是同一个机构、 同一个部门。 这些组织机构模型在实体的抽象、定义等 精品文档 . 各个方面都存在很大的差异, 导致面对现实中同一个东西, 在模型中表现出来的 却千差万别。 这样导致新的系统不能重用以前建设好的组织模型,它只能重新建 设一个供它自己专用的新的组织模型。就这样,随着应用系统的增加, 组织机构 模型也随着增加。这样就带来了很多问题: 首先,是组织机构模型的重复建设,浪费财力物力。 其次,是越来越多的各式各样的组织模型,给管理维护带来了巨大的工作量 的复杂性,增大了维护工作的出错
38、率,影响系统的稳定性。 再次,是组织模型的分离导致了各个应用系统处于孤立状态,对各个应用系 统进行协作带来了很多的困难。 目前,还没有对电子政务组织模型进行规范的相关标准,行业内各个厂家都 是依据自己的需求进行组织机构的建模,都拥有自己的组织模型。 对组织模型的 抽象不全面、不规范。 建立一套建设组织模型的规范,行业内在建设组织模型时参考规范进行建 设,这样的组织模型就更具有普遍性,我们就能尽可能的进行组织模型的复用, 减少重复建设。 降低组织模型的维护成本和编撰复杂度,提高系统的可用性和稳 定性。同时,还能减少多个组织模型带来的其它方面的问题,如重复多次的认证、 组织模型信息的共享等等,为上
39、层其它应用系统的建设提供了方便和基础。 组织模型的数据存储 组织模型的实例数据支持数据库存储和目录存储两种方式,支持通用标准协 议(LDAP) 。 在本项目中根据组织模型规范, 梳理并建设全市国土资源系统党政机关电子 政务组织身份目录。 组织身份目录是通过对政府机构现状调查来形成的。该模型 对于政府组织机构及其相关身份职责进行了完整描述;组织身份目录重点在于职 能岗位及其相应职责, 组织身份目录可以认为是现状模型体现,通过树状层层细 分,给出岗位和职责映射。 1.4.1.1.组织模型实体定义 组织模型实体定义:包括机构、部门、人员、角色、用户组、岗位六大类。 实体的描述方法: 对各实体的属性进
40、行描述, 实体的属性包括数据类型、 值 域、约束、示例、描述五方面的定义。 精品文档 . (1)数据类型 : 说明实体属性的数据类型, 对实体属性的有效值域及允许的 有效操作进行规定,如整型、实型、布尔型、字符型、日期型等。 (2)值域:说明实体属性可以取值的范围。 (3)约束:说明实体属性必须遵守的一些强制性规则,如不可取空值等。 (4)示例:对于每一个属性元素,都列举一个填写内容示例,如部门名字 的取值示例:局信息中心。 (5)描述:对实体属性的意义进行简短的描述。 实体描述如下: 机构 机构是指在社会生活中, 人们为实现某种职能所建立的、 由人财物和信息等 若干因素有序地联结起来的、 相
41、对稳定的社会实体单位的抽象,通常指机关、 团 体或其他工作单位及其内部组织,例如:潍坊市国土资源局 部门 部门是根据行政划分而实际存在的实体部门的抽象,例如:潍坊市国土资源 局办公室。 人员 人员是部门内的实体人员及类似实体的抽象,例如:张三。人员的属性如下 表: 角色 角色是指在处理特定业务时设定的具有特定工作范围或工作职责,用于解决 特定业务问题的实体抽象,例如:办公室文件管理员。 用户组 用户组是为满足特定业务需求而组建的,不受机构或部门限制的人员集合的 抽象,可以是临时的或长期的,如:信息化领导小组。 岗位 岗位是根据部门编制实际存在的工作岗位的实体抽象,如工商局局长。 1.4.1.2
42、.组织身份模型实体关系 如下图所示,组织身份模型实体关系是组织身份模型中各个实体之间的关联 关系的统称。 精品文档 . 机构和部门的关系: 一对多关系, 一个机构可以包含多个部门,一个部门只 能被一个机构包含。 机构和人员的关系: 一对多关系, 一个机构可以包含多个人员,一个人员只 能被一个机构包含。 机构和角色的关系: 一对多关系, 一个机构可以包含多个角色,一个角色只 能被一个机构包含。 机构和岗位的关系: 一对多关系, 一个机构可以包含多个岗位,一个岗位只 能被一个机构包含。 机构和组的关系: 一对多关系, 一个机构可以包含多个组, 一个组只能被一 个机构包含。 部门和部门的关系: 一对
43、多关系, 一个部门可以包含多个子部门,一个子部 门只能被一个部门包含。 部门和人员的关系: 一对多关系, 一个部门可以包含多个人员,一个人员只 能被一个部门包含。 部门和角色的关系: 一对多关系, 一个部门可以包含多个角色,一个角色只 能被一个部门包含。 部门和岗位的关系: 一对多关系, 一个部门可以包含多个岗位,一个岗位只 能被一个部门包含。 部门和组的关系: 一对多关系, 一个部门可以包含多个组, 一个组只能被一 个部门包含。 组和组的关系: 多对多关系, 一个组可以包含多个组, 一个组也可以被多个 组包含。 组和人员的关系: 多对多关系, 一个组可以包含多个人, 一个人也可以被多 个组包
44、含。 岗位和人员的关系: 多对多关系, 一个岗位可以由多个人员担任,一个人员 也可以担任多个岗位。 角色和人员的关系:多对多关系,一个人员可以担当多种角色, 一个角色也 以由多个人员担当。 角色和角色的关系: 一个角色可以包含多个子角色,一个子角色也可以被多 精品文档 . 个父角色包含。 1.4.2.身份服务组件 身份服务组件实现用户身份进行认证,组件能够提供用户信息进行增加、删 除、修改、验证等服务, 同时能实现通过同步信息接口把变动数据同步给外部第 三方系统。 身份服务接口包括四大类:身份认证接口、模型管理接口、模型信息接口、 同步信息接口。 身份认证接口指对用户身份进行认证的接口。其中模
45、型管理接口指实体及实 体属性的管理接口。实体增、删、改操作,当然根据需要,还包括一些特殊的操 作如:移除。模型信息接口指对模型信息进行读取的操作接口。同步信息接口指 把模型的变动数据同步给外部系统的接口。 1.4.3.访问控制服务组件 访问控制服务组件实现阻止未经允许的用户有意或无意地越权获取数据。实 现管理员管理各自应用的用户和访问权限,具有不同的管理界面和管理实现方 法。 1.4.3.1.概述 访问控制是针对越权使用资源的防御措施。基本目标是为了限制访问主体 (用户、进程、服务等)对访问客体(文件、系统等)的访问权限,使计算机系 统在合法的范围内使用,决定用户能做什么,也决定代表用户的程序
46、能做什么。 访问控制决定了谁能够访问系统, 能访问系统的何种资源以及如何使用这些 资源。访问控制能够阻止未经允许的用户有意或无意地越权获取数据。 访问控制基本概念 主体( Subject ) :或称为发起者 (Initiator),是可以访问资源的实体,通 常指用户或代表用户执行的程序。 精品文档 . 客体( Object ) :是需要保护的资源,又称作目标(target)。 授权(Authorization):是可以对资源执行的动作,例如读、写、执行或拒 绝访问。 访问控制服务原理 访问控制模型示意图 通过建立统一的访问控制模型, 提供统一的权限访问接口和管理接口,提供 统计、日志、事件、审
47、计、查询等功能,实现应用系统权限管理的一致性、易管 理和易维护。 通过权限访问接口, 为各应用系统提供统一的访问策略和权限控制。通过权 限管理接口,使各应用系统能够创建自己的访问控制资源并进行权限分配。 1.4.3.2.权限管理模型 根据电子政务体系对访问控制的要求,访问控制模型参考ConstrainedRBAC 模型,并在此基础上进行扩展, 增加 Actor 对象,即用户(User)和角色(Role) 的集合;增加域( Domain)对象,即授权的作用范围;增加用户(User)和权限 (Permission )的关系,即除对角色授权外,单个用户(User)可以直接授权。 基本概念定义: 操作
48、者 (Actor) :执行者、参与者。 包含用户 (User) 和角色 (Role) 的集合总称,可以是应用系统的代理 (agent) , 或其它任何能够发起请求的对象。可以反向包含自身, 即树状结构。 接口中引用 精品文档 . 的 actorUID 泛指用户( User)对象、角色( Role)对象和代理对象( agent)的 UID值。 JY(User) 发起请求的主体,对应组织机构中得Person 对象,或者一个应用代理程序 (agent) 。可以通过授权管理对用户直接进行授权。 角色(Role) 一组具有相同属性或者业务需求的人员集合,是授权的主体, 可 以是组织模型中的机构、部门、用
49、户组、角色、岗位等。 资源(Resource) :对象( Object ) 。 资源或对象,被授权对象。可以反向包含自身,即树状结构。 操作(Operation):权限类型。 是访问控制可以执行的最小功能项,被Actor 调用或执行。 EIEIT(Permission):同义词: Privilege。 是一个许可,对在一个或多个Resource 上执行的 Operation 的许可。 会话(Session) : 每个 Session 是一个用户到多个Role 的映像,当一个 Actor 启动它所有角 色的一个子集的时候, 建立了一个 Session。 每个 Session 和单个的 Actor 关联, 并且 Actor 可以关联到一个或多个Session 。 域(DoiTflifl) : 描述作用范围,也叫作用域。通过分配不同的对象(Actor 、Resource、 Operation ) ,生成授权范围,授权是在域的范围内进行。 1.4.3.3.访问控制规则 1授权方式:正向授权,开始时假定主体没有任何权限,然后根据需要授 予权限。 2权限继承:权限的继承通过对象的父子关联实现,如果设置为可继承, 则执行者子对象自动继承父对象的权限,子资源自动继承父资源的权限。 精品文档 . 3权限过滤 通过设置相应的权限过滤规则
链接地址:https://www.31doc.com/p-5544465.html