综合管理服务平台.doc

1.1. ESB服务总线
1.1.1. 概述
各业务系统提供大量的服务接口,如何实现这些服务和接口的编排、调用、重组等,我们采用的是应用服务总线的模式.通用服务总线采用可靠消息服务（不丢失,不复传)在应用系统之间通过基于消息的异步方式集成各应用系统.
1.1.2. 架构设计
ESB服务总线架构图
ESB服务总线是综合管理服务平台的一个中心组件,它负责接入各种服务资源,通过采用统一服务接口使得各种服务或应用与服务之间可以相互方便访问,以星形结构替代了原来各服务之间的点对点结构，极大地优化了系统连接架构，降低了系统集成的复杂度。
1.1.3. 功能设计
ESB应用服务总线基于消息交换组件开发。采用消息交换组件提供的可靠消息服务（不丢失，不复传）在应用系统之间通过基于消息的异步方式集成各应用系统。针对不同系统所处理的消息格式各不相同的特点，ESB应用服务总线提供了专门的格式代码转换器在不同的消息格式之间按照预先定义好的转换规则进行自动的格式转换,然后将结果自动路由到目标应用系统。在消息转换的过程中ESB应用服务总线能够识别XML,C结构，JMS等多种消息格式；对消息的各种操作包括消息的来源、消息的目标应用、所期望的消息格式等通过定义各种操作规则(Rules)进行。
ESB应用服务总线可以作为一个消息代理来实现这些功能。
消息代理提供了消息传递层以及消息代理集线器，可被用于消息的处理、转换和分发，并能够将这些功能与发布/预订功能结合在一起.
Ø 应用程序格式转换和智能路由功能
作为各个应用的数据吞吐机，提供多种数据格式服务，其中包括：用户自定义格式,用户可以为每一种应用定制自己的消息格式，通过这种消息格式来连接原有的旧的应用； XML格式；面向纪录的信息格式，如C的头文件，COBOL records等.对于这些消息格式,提供相应的剖析器进行解析，实现它们之间的格式转换。如对于用户的bit stream的输入信息可以输出为XML的格式，反之亦然.从而无缝地连接现有的应用，并可以采用XML的新标准开发新的应用.提供检查和过滤功能，根据所传输数据的内容做动态路由
Ø 强大的数据处理功能
作为各个应用的数据处理机,对经过BPI的数据进行各种处理操作，如计算、过滤等，使得数据在从BPI经过时便可以被进行相应地计算，从而发往目的应用系统；支持数据仓库，对各应用系统所传输的数据进行集中记录，便于以后的审计和分析。
Ø 对各种应用系统的接口功能
提供强大的连接性，既提供各种与现有商业应用连接的Adapter，可以将企业内部各种应用系统进行无缝连接,如SAP,Notes，Sibel，SWIFT，People Soft,I2等,支持各种标准数据格式或应用的接口，如XML， JDBC，对于这些应用可以不必开发新的接口，减少开发的工作量;同时提供应用程序接口以开发客户化的连接件。
Ø 对各种接入协议的支持
ESB应用服务总线支持各种接入协议，其中包括TCP/IP Socket，MQ，SOAP,HTTP,SCADA等。
适配器技术选择
适配器完成的功能是实现应用系统与EAI HUB之间的连接接口，主要包括数据与通讯两个层面。在适配器设计与选型方面，EAI技术提供的方案有多种形式,根据不同的情况作不同的选择。根据应用对外提供的接口的形式不同，下面对常用的适配器类型进行分析。
Ø 基于数据库的接口与适配器
应用系统对外提供的接口是应用数据库，适配器通过对应用数据库的操作来实现EAI与应用间的交互.此类接口是应用系统可对外提供的最底层的接口类型，允许适配器直接访问应用的数据。针对此方式，尽管这也是常用方式之一，但其中有很多严重的不足.
使用数据作为应用的接口，意味着将数据的结构体设计暴露出来.当应用发生改变时，通常需要重新分析、甚至改变此数据接口.当应用系统的数据改变时，为了触发外部应用，通常需要使用基于应用数据库的外部触发器或使用低效的循环查询策略,这不是一个”干净”的解决方案,外部应用对维护数据的完整性也将负有责任，为此需要理解需要集成的应用系统的结构。总之，其结果将是一个难以维护的交错系统.
Ø 基于API的接口与适配器
应用软件，通常提供内置于软件库的API，作为与应用系统交互的接口.相对数据库接口而言,此类接口是一个更为”干净”的解决方案.其问题是相对某种平台，如操作系统、编程语言，此API库可能不存在，为解决此问题，需要开发底层的代码并进行长期的维护。同时当支撑其运行的产品进行升级时，通常需要对此API进行升级以保证其兼容。另外，基于API技术，当应用系统有事件发生时，一般难以提供自动通知功能，需要外部系统进行低效的循环查询。
Ø 基于组件的接口与适配器
基于J2EE与CORBA的分布式对象技术，使应用系统的接口有较好的可移植性。此类接口,可以屏蔽操作系统、编程语言的不同。此类接口属于紧耦合模式，为发展中的技术，由于应用系统本身需要提供组件接口,在实际应用中限制了其应用。
Ø 基于消息队列的接口与适配器
应用系统对外交互的接口为消息队列，同时提供消息/数据传输的可靠性保障。业界领先的消息中间件同时提供同步、异步两种通讯方式.使用消息队列，消息系统可以管理很多通讯细节。此种接口方式为典型松耦合模式，是EAI技术普遍使用的方式之一，可以实现接口的重用能力.
成熟的商业适配器
ESB应用服务总线支持的适配器
ESB应用服务总线提供了诸多的既有的适配器，包括技术适配器与应用适配器，部分列表如下.
技术适配器：
1〉 JDBC
2〉 JMS
3〉 MQ
4〉 E-mail
5〉 JText
6〉 Microsoft Exchange
7〉 Web Services

应用适配器：
1〉 SAP
2〉 Siebel
3〉 Spirent
4〉 Ariba Buyer
5〉 BroadVision
6〉 Clarify
7〉 eMatrix
8〉 i2
9〉 i2 ADW
10〉 Metasolv TBS
11〉 Nightfire
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. 总体框架描述
应用服务总体框架是国土资源综合管理服务平台项目的核心，总体框架由系统微内核、系统服务层组成。系统微内核应能提供最基础、最核心的功能,包括模块管理、生命周期、服务管理，为整个系统的稳定运行提供保障。系统服务层应能够提供各类标准化的、技术性的服务如时间服务、审计日志、持久服务、缓存服务、事件服务、事务服务、数据服务等。框架之上支持公共服务组件和业务服务组件，共同组成综合管理服务平台。
1.2.2. 总体框架组成
在本设计方案的总体结构图中，把系统划分为五层，而最底层的基础层提供了系统运行的环境,最上层的门户展现层提供的进入各个应用系统的入口。其中应用支撑平台是系统的支撑层。其中综合管理服务平台是系统的支撑层。支撑层包括的主要内容有：系统微内核、系统服务层.各层的主要功能分别描述如下.
1.2.2.1. 系统微内核
系统本身采用微内核架构，实现模块化、动态化、服务化。微内核做为整个系统的运行内核，仅提供最基础、最核心的功能，包括模块管理、生命周期、服务管理，为整个系统的稳定运行提供保障，整个系统的各个部分都做为模块直接或间接构建在微内核之上。
1.2.2.2. 系统服务层
系统服务层还包含各类标准化的、技术性的服务，而在应用服务层则提供功能性的服务。系统服务层提供的服务有:时间服务、审计日志、持久服务、缓存服务、事件服务、事务服务、数据服务等。
本次项目的主要研讨内容为应用服务层中的各个服务组件,因此系统服务层中的基础服务组件将不做为本方案阐述的重点。
1.2.2.3. 表现层描述
业务表现层是面对最终用户的接入口,利用综合门户等方式提供各种业务供客户使用，向下须与面向服务的业务层通过正确定义的服务接口实现兼容.采用的门户技术应该能够支持JSR168Portal规范，能够自由部署第三方的标准Portal。
1.2.3. 总体框架的地位和作用
1. 从技术复用到业务复用
当前的软件复用大多还是从技术角度出发的,例如J2EE领域的框架只是一个以库、类和接口形式提供的基础架构，最终构成应用的业务逻辑和表现/控制逻辑则要由建立在这个框架上的业务组件实现。而应用软件最终要解决的却是应用问题，或者说是业务问题，如果软件能够在更高层次的业务层面上进行大范围复用，那么对提高软件开发效率的作用将会更大。只有采用面向服务的设计思想，才能够在更高层次上实现业务复用。
2. 业务组件的支撑平台
由于上述的业务组件并不是一个可以独立运行的应用软件，所以需要为它们提供一个赖以生存的运行基础——核心底层机制特别是组件的管理,如组件的创建、组件的获得、组件的资源管理、组件的消亡等生命周期支持;以及组件之间相互通讯的渠道和方式。
3. 分布式部署的应用系统
如果应用系统只部署在一台机器上,随着系统功能的增加和负载的加大，只有不断提升机器的硬件配置.我们希望能够把系统按照功能进行划分，以分布式的方式进行部署，将不同的功能模块部署在不同的服务器上,服务器的压力能够有效的降低，使得系统可以以较低的成本继续保持高稳定性和高可用性。
以国土资源各类数据库为基础，以国土资源信息网络为依托，以标准、制度和安全体系为保障,以地政、矿政、地质环境等主要管理业务流程优化为主线，以支撑国土资源管理决策为核心，形成互联互通、贯穿上下的政务管理、决策支持和社会服务信息化体系。
1.2.4. 功能设计
1.2.4.1. 应用服务运行管理框架
应用服务运行管理框架简称应用服务框架，是应用服务的运行、监控、管理的框架。
应用服务框架提供了统一的服务库注册、存储、查询的应用服务元数据信息，提供了发布、调用应用服务的功能，可对应用服务及调用进行监控、管理，同时提供了本地和远程调用，可支持分布式应用和负载均衡.
在不同的应用服务框架之间，采用对等的分布式调用机制，可注册远程的服务库到本地.可通过应用服务框架之间的互操作调用,实现互联互通.
应用服务框架本身不提供访问控制的功能,但可借助访问控制服务模块实现对应用服务的认证、授权和访问控制。
应用服务框架作为软件基础设施,通过部署在上面的服务模块，以标准的协议对外提供服务，可实现更高层次的软件复用和业务复用,可将原有应用系统中可重用、可共享的功能单元服务化,利于应用系统整合.
应用服务框架提供高度可集成的能力，采用标准的Web服务协议组作为服务接口描述和调用规范，可屏蔽不同软件平台的差异，实现透明的互操作.
1.2.4.2. 服务模块
服务模块是进行部署的最小单位，是满足某些特定功能需求的一组相关应用服务的集合，可以是软件包的形式,也可以是第三方提供的应用服务集合的形式。服务模块可通过元数据描述文件（附录A：服务组件描述模式schema）描述并部署在应用服务框架上,也可通过应用服务框架提供的界面或API来部署，由应用服务框架实行统一的监控和管理。
1.2.4.3. 服务组件
服务组件是服务模块的基本组成元素和基本构建单位，是粒度最小的实现和发布单元，是相关的一组应用服务的具体实现，它的功能以应用服务的形式提供。服务组件具有可设置的属性，其属性是可以改变服务功能的数据。
服务模块由一个或多个服务组件及相关配置信息构成。
1.2.4.4. 元数据
1. 元数据描述方法
采用摘要表示的方法定义和描述元数据，摘要包括以下属性：中文名、英文名、数据类型、值域、约束、说明。
中文名：元数据的中文名称，中文名称在同一类元数据中是唯一的。
英文名：元数据的英文名称，英文名称在同一类元数据中是唯一的,比较时不区分大小写。可包含的字符为大小写的英文字母、数字,所有组成词汇为无缝连写.
元数据的数据类型。
值域：元数据可以取值的范围。
约束：元数据的约束性条件，包括是否非空、最大出现的次数、是否唯一。
说明：对元数据含义的进一步的解释及补充说明。
2. 应用服务及服务组件元数据
通过应用服务元数据对应用服务进行描述，发布、查找和调用应用服务时都需使用元数据信息。应用服务和服务组件都使用相同的元数据描述。本部分定义了核心元数据,即所有应用服务描述中共性的、必不可少的元数据。
1.2.4.5. 应用服务框架组成
应用服务工作原理图
1. 工作原理
应用服务框架提供了应用服务的发布、注册、查找、调用、监控、管理功能，其中涉及三个角色：服务提供者、服务请求者、服务库。应用服务工作原理如下：
1) 服务提供者开发符合应用服务技术要求的功能单元，将开发好的功能发布为应用服务，并将应用服务在服务库中注册。
2) 服务请求者在服务库中查找所需服务，根据返回的结果确定需要调用的应用服务。
3) 服务请求者根据需要调用的应用服务，获得应用服务的代理对象.
4) 服务请求者发起调用请求，对应用服务进行实际调用，并获得服务返回的结果.
5) 在整个提供服务的过程中，三个角色的基本功能如下：
6) 服务提供者:发布服务、进行注册。
7) 服务请求者：查找服务、调用服务。
8) 服务库：服务注册、服务查找、监控管理。
2. 总体框架
如上图所示，应用服务框架由服务库、发布模块、调用模块、管理模块和监控模块五部分组成.
服务库提供对应用服务元数据的注册、存储和查找功能，可以将服务模块、服务组件和应用服务注册在服务库中.
发布模块提供将功能单元服务化的功能,读取并解析注册描述文件，将描述在其中的接口发布为应用服务，并自动注册到服务库中。
调用模块封装对应用服务的调用过程，屏蔽技术实现细节,直接实现对应用服务的调用，可与应用服务框架部署在一起,也可单独部署在应用服务的调用端。调用模块可将远程应用服务框架注册到本地，能对远程服务库查找和调用，实现不同应用服务框架之间的分布式调用。
管理模块提供对服务模块、组件和应用服务的管理功能，通过访问控制服务模块实现对应用服务的授权和访问控制，并提供UI界面实现人机交互。
监控模块在记录应用服务调用日志的基础上提供审计、统计和分析功能,可监控和改变应用服务的运行状态.
1.2.4.6. 接口定义
应用服务运行框架接口分为服务组件管理接口、服务模块管理接口、应用服务管理接口、服务库管理接口、获取应用服务接口五大类
1.3. 资源目录建设
对全市国土资源系统信息资源进行梳理。建立全市国土资源系统信息资源目录规划，以便将全市国土资源系统可共享资源库进行集中有序组织,方便用户资源查找、数据检索和应用系统访问。
信息资源目录体系主要负责各级国土资源部门共享信息资源库的标准化描述和合理化组织.其中信息资源库的描述主要针对信息资源库的数据存储、访问方法和数据格式进行描述，是揭示信息资源库结构、指导用户使用的检索工具，是用户迅速、准确、有效地寻找信息的向导,是对信息资源实施安全保护的有效手段。
信息资源目录可根据市各级国土资源部门提供资源的情况，动态更新，及时反映共享数据资源接入的情况.是对信息资源实施安全保护的有效手段。其主要功能是对各级国土资源部门的信息资源库进行合理规范的组织及维护,标准化的描述信息资源库的访问方式、应用规则和相互关系。全市资源目录体系主要包括三大基础目录,详细描述如下：
1.3.1. 组织身份目录
建设全市国土资源系统统一的组织身份目录，实现全市国土资源系统组织身份的统一管理和各业务系统的身份整合。组织身份目录指全市国土资源系统身份及组织架构目录的结构设计、用户身份信息属性设计等.
全市国土资源系统统一身份库是以目录为基础建立的全面身份管理基础架构。通过元目录的技术,可以将各个独立的应用中的用户资源统一到一个元目录进行集中管理.这种方法提供了单点管理,大大地简化了用户身份的管理。
在身份总库中建立统一的全市国土资源系统业务系统目录结构。身份总库作为身份认证仓库，将用户的访问信息独立于应用程序来进行集中管理,建立单一的权威用户数据库作为所有数据的数据源。同时，该基础架构对组织的授权管理提供支持。身份管理基础架构为系统电子政务基础架构所提供的其他网络服务提供了基础.
总库中的组织机构信息应与各级国土资源部门的全部组织机构信息完全吻合，换句话说,就是将身份总库中的组织目录信息与各级国土资源部门身份库中的全部内容保持同步.
1.3.1.1. 建立组织模型规范及目录
制定全市组织模型规范，统一规范电子政务系统中的组织身份数据模型，主要包括政府部门机构、领导、人员、职位、岗位、职级、用户组、角色等实体对象，以及各实体对象之间的关系。
根据组织模型规范，梳理并建设全市组织身份目录。组织身份目录是通过对政府机构现状的调查来形成的。该模型对于组织机构及其相关的身份职责进行了完整的描述；组织身份目录的重点在于职能岗位及其相应的职责，组织身份目录可以认为是现状模型的体现，通过树状的层层细分，给出岗位和职责的映射。
组织身份目录模型图：
1.3.1.2. 提供组织身份目录规范的接口
提供规范的组织模型对外服务接口，所有注册在资源目录中的资源均可通过API接口获得,下图为平台为用户提供的接口文件列表：
1.3.2. 应用服务目录
建设全市国土资源系统统一的应用服务目录,为实现全市国土资源系统多业务系统应用整合奠定基础。网络管理员需要管理的应用系统很多。为了集中对各应用系统中的各个功能进行授权控制,更好的为portal提供完整的应用系统信息，我们在综合管理服务平台中提供应用系统管理服务。
在目录服务中建立一个指定的容器对象，将各应用系统以对象的形式存放在该容器中，各应用系统的子模块及子功能均可以作为对象以树的方式存放在相应的应用系统对象下.每一个对象拥有相应的功能模块的基本信息,如：名称、URL、开发商、版本等信息。
通过应用服务目录的管理可以实现以下的几点：
1． 为集中授权做好基础,通过将各应用系统的功能映射到目录服务相应的对象，就可以利用目录服务技术良好的安全控制机制。
2． 可以集中为应用系统提供有关其他系统的结构及URL信息。为单点登录和门户整合提供应用系统的管理支持。
1.3.3. 信息资源目录
建设全市国土资源系统统一的信息资源目录，为实现全市国土资源系统信息资源的统一描述与发现，为多部门信息资源的共享与整合提供资源环境基础。
信息资源目录体系主要负责全市国土资源系统共享信息资源库的标准化描述和合理化组织。其中信息资源库的描述主要针对信息资源库的数据存储、访问方法和数据格式进行描述，是揭示信息资源库结构、指导用户使用的检索工具,是用户迅速、准确、有效地寻找信息的向导，是对信息资源实施安全保护的有效手段，并服务于信息资源共享平台的资源查找和定位.
信息资源目录可根据全市各级国土资源部门提供资源的情况，动态更新及时反映共享数据资源接入的情况。它是面向信息资源共享平台和全市国土资源系统工作人员浏览和查询资源库信息的基础，是揭示信息资源库结构、指导用户使用的检索工具，是用户迅速、准确、有效地寻找信息的向导，是对信息资源实施安全保护的有效手段。其主要功能是对全市国土资源系统的信息资源库进行合理规范的组织及维护，标准化的描述信息资源库的访问方式、应用规则和相互关系。
信息资源目录体系采用目录服务技术和元数据标准相结合的方式进行实现。目录服务技术目前已经成为国际上非常流行和通用的技术，其快速的查询效率和强制性的安全管理特性为目录服务提供了良好的系统环境。国家有关资源库描述的元数据标准对资源库的描述已经初步规范化，采用相关成熟的元数据标准有利于对信息资源库的进行标准化描述和规范化定义.
1.3.3.1. 资源服务的注册维护
资源库注册维护功能是为信息提供单位对可供共享的数据资源库在整个信息资源目录体系中注册和元数据维护,以便其他单位能够及时准确地共享利用该资源库的数据。其注册维护的主要信息包括共享资源库访问的URL、联系人、负责人等，功能包括注册、修改和注销等。该功能只为全市信息中心平台管理员和各共享资源库提供单位的管理员提供。
1.3.3.2. 资源服务的目录组织
资源目录是将整个全市可共享资源库进行集中的有序组织，以方便用户资源查找、数据检索和应用系统访问。
信息资源目录由各提供单位在本部门组织节点下分级管理。为了全市综合管理服务平台管理员的集中管理和监控，资源目录对分布在市各部门组织目录不同节点的资源库信息进行集中展现,其实现界面参考如下:
1.3.3.3. 共享资源的注册发布
通过信息资源目录实现对共享资源库的数据检索、列表及详细信息查看等功能.这些功能可以通过授权控制进行访问控制。
1.4. 公共服务组件
公共服务组件应包括组织模型管理组件、身份服务组件、访问控制服务组件、各类业务流程服务组件、各类业务电子表单组件、单点登录组件、通用GIS引擎服务组件以及非结构化数据管理组件等功能。
1.4.1. 组织模型管理组件
组织模型管理组件实现对组织模型的管理服务，用来定义组织形式的模型，以职责、权限的形式定义成员、各个部门的作用与任务，同时提供灵活的结构以适应不同的部门或不同的组织结构。
本组件提供对组织模型的管理服务.
在本项目中根据组织模型规范,梳理并建设全市国土资源系统党政机关电子政务组织身份目录。组织身份目录是通过对政府机构现状调查来形成的。该模型对于政府组织机构及其相关身份职责进行了完整描述；组织身份目录重点在于职能岗位及其相应职责，组织身份目录可以认为是现状模型体现，通过树状层层细分，给出岗位和职责映射。
组织模型的地位和作用
电子政务组织模型就是对政府组织结构进行建模，是利用抽象的模型或者元素,构造出的一系列关系，用于表达政府组织机构中的实体间的层次和隶属。组织模型是用来定义政府的组织形式的模型，它以职责、权限的形式定义了政府成员、政府各个部门的作用与任务,同时提供灵活的结构以适应不同的政府部门或不同的组织结构.
组织模型是大部份电子政务应用系统构建的基础。几乎所有的电子政务应用系统都涉及到组织机构模型的建设,一个组织机构模型的好坏直接影响到基于它构建的其它应用系统。
组织机构模型对现实中的机构进行了抽象建模，提供了统一的概念和语义.
通过组织模型的建设能很好的解决电子政务应用中人员调动、权限变化、职位变迁、部门合并、分级授权管理等各种业务问题
组织模型提供了一个统一的抽象，对用户统一集中管理，可管理多级用户，支持用户分类分组、多种用户接口、用户权限安全等方面的管理。
组织模型为单点登录、统一授权提供基础，它为灵活授权、统一管理提供了基础.
组织模型支持各种业务应用
在当前的电子政务领域，通常一个部门或一个机构拥有多个应用系统，而这些应用系统往往由多个厂家承建，他们基于不同的组织机构模型建立的，虽然它们面对的是同一个机构、同一个部门。这些组织机构模型在实体的抽象、定义等各个方面都存在很大的差异,导致面对现实中同一个东西，在模型中表现出来的却千差万别。这样导致新的系统不能重用以前建设好的组织模型，它只能重新建设一个供它自己专用的新的组织模型。就这样,随着应用系统的增加，组织机构模型也随着增加。这样就带来了很多问题：
首先，是组织机构模型的重复建设,浪费财力物力。
其次，是越来越多的各式各样的组织模型，给管理维护带来了巨大的工作量的复杂性，增大了维护工作的出错率,影响系统的稳定性。
再次,是组织模型的分离导致了各个应用系统处于孤立状态，对各个应用系统进行协作带来了很多的困难。
目前，还没有对电子政务组织模型进行规范的相关标准,行业内各个厂家都是依据自己的需求进行组织机构的建模,都拥有自己的组织模型。对组织模型的抽象不全面、不规范。
建立一套建设组织模型的规范，行业内在建设组织模型时参考规范进行建设，这样的组织模型就更具有普遍性，我们就能尽可能的进行组织模型的复用，减少重复建设。降低组织模型的维护成本和编撰复杂度，提高系统的可用性和稳定性。同时，还能减少多个组织模型带来的其它方面的问题,如重复多次的认证、组织模型信息的共享等等，为上层其它应用系统的建设提供了方便和基础.
组织模型的数据存储
组织模型的实例数据支持数据库存储和目录存储两种方式,支持通用标准协议(LDAP）。
在本项目中根据组织模型规范,梳理并建设全市国土资源系统党政机关电子政务组织身份目录。组织身份目录是通过对政府机构现状调查来形成的。该模型对于政府组织机构及其相关身份职责进行了完整描述；组织身份目录重点在于职能岗位及其相应职责，组织身份目录可以认为是现状模型体现,通过树状层层细分,给出岗位和职责映射。
1.4.1.1. 组织模型实体定义
组织模型实体定义：包括机构、部门、人员、角色、用户组、岗位六大类。
实体的描述方法：对各实体的属性进行描述,实体的属性包括数据类型、值域、约束、示例、描述五方面的定义。
（1）数据类型：说明实体属性的数据类型，对实体属性的有效值域及允许的有效操作进行规定，如整型、实型、布尔型、字符型、日期型等.
（2）值域：说明实体属性可以取值的范围.
（3）约束:说明实体属性必须遵守的一些强制性规则，如不可取空值等。
（4)示例：对于每一个属性元素，都列举一个填写内容示例，如部门名字的取值示例：局信息中心。
(5）描述：对实体属性的意义进行简短的描述。
实体描述如下：
l 机构
机构是指在社会生活中，人们为实现某种职能所建立的、由人财物和信息等若干因素有序地联结起来的、相对稳定的社会实体单位的抽象，通常指机关、团体或其他工作单位及其内部组织，例如：潍坊市国土资源局
l 部门
部门是根据行政划分而实际存在的实体部门的抽象，例如:潍坊市国土资源局办公室.
l 人员
人员是部门内的实体人员及类似实体的抽象，例如：张三。人员的属性如下表：
l 角色
角色是指在处理特定业务时设定的具有特定工作范围或工作职责，用于解决特定业务问题的实体抽象,例如：办公室文件管理员.
l 用户组
用户组是为满足特定业务需求而组建的，不受机构或部门限制的人员集合的抽象,可以是临时的或长期的,如：信息化领导小组。
l 岗位
岗位是根据部门编制实际存在的工作岗位的实体抽象，如工商局局长。
1.4.1.2. 组织身份模型实体关系
如下图所示，组织身份模型实体关系是组织身份模型中各个实体之间的关联关系的统称。
机构和部门的关系：一对多关系，一个机构可以包含多个部门,一个部门只能被一个机构包含。
机构和人员的关系：一对多关系，一个机构可以包含多个人员,一个人员只能被一个机构包含.
机构和角色的关系：一对多关系，一个机构可以包含多个角色,一个角色只能被一个机构包含。
机构和岗位的关系：一对多关系，一个机构可以包含多个岗位，一个岗位只能被一个机构包含。
机构和组的关系:一对多关系，一个机构可以包含多个组，一个组只能被一个机构包含。
部门和部门的关系:一对多关系,一个部门可以包含多个子部门,一个子部门只能被一个部门包含。
部门和人员的关系：一对多关系,一个部门可以包含多个人员，一个人员只能被一个部门包含。
部门和角色的关系：一对多关系，一个部门可以包含多个角色,一个角色只能被一个部门包含。
部门和岗位的关系：一对多关系，一个部门可以包含多个岗位,一个岗位只能被一个部门包含。
部门和组的关系:一对多关系，一个部门可以包含多个组,一个组只能被一个部门包含。
组和组的关系：多对多关系，一个组可以包含多个组，一个组也可以被多个组包含。
组和人员的关系：多对多关系,一个组可以包含多个人，一个人也可以被多个组包含。
岗位和人员的关系：多对多关系，一个岗位可以由多个人员担任，一个人员也可以担任多个岗位。
角色和人员的关系：多对多关系，一个人员可以担当多种角色,一个角色也以由多个人员担当。
角色和角色的关系：一个角色可以包含多个子角色，一个子角色也可以被多个父角色包含.
1.4.2. 身份服务组件
身份服务组件实现用户身份进行认证,组件能够提供用户信息进行增加、删除、修改、验证等服务,同时能实现通过同步信息接口把变动数据同步给外部第三方系统。
身份服务接口包括四大类：身份认证接口、模型管理接口、模型信息接口、同步信息接口。
身份认证接口指对用户身份进行认证的接口。其中模型管理接口指实体及实体属性的管理接口。实体增、删、改操作，当然根据需要,还包括一些特殊的操作如：移除。模型信息接口指对模型信息进行读取的操作接口。同步信息接口指把模型的变动数据同步给外部系统的接口。
1.4.3. 访问控制服务组件
访问控制服务组件实现阻止未经允许的用户有意或无意地越权获取数据。实现管理员管理各自应用的用户和访问权限，具有不同的管理界面和管理实现方法。
1.4.3.1. 概述
访问控制是针对越权使用资源的防御措施。基本目标是为了限制访问主体（用户、进程、服务等）对访问客体（文件、系统等）的访问权限，使计算机系统在合法的范围内使用，决定用户能做什么,也决定代表用户的程序能做什么。
访问控制决定了谁能够访问系统，能访问系统的何种资源以及如何使用这些资源。访问控制能够阻止未经允许的用户有意或无意地越权获取数据。
l 访问控制基本概念
主体（Subject）：或称为发起者(Initiator)，是可以访问资源的实体,通常指用户或代表用户执行的程序。
客体（Object）:是需要保护的资源，又称作目标（target).
授权（Authorization)：是可以对资源执行的动作，例如读、写、执行或拒绝访问。
l 访问控制服务原理
访问控制模型示意图
通过建立统一的访问控制模型，提供统一的权限访问接口和管理接口，提供统计、日志、事件、审计、查询等功能，实现应用系统权限管理的一致性、易管理和易维护。
通过权限访问接口，为各应用系统提供统一的访问策略和权限控制。通过权限管理接口，使各应用系统能够创建自己的访问控制资源并进行权限分配。
1.4.3.2. 权限管理模型
根据电子政务体系对访问控制的要求，访问控制模型参考ConstrainedRBAC模型，并在此基础上进行扩展，增加Actor对象，即用户(User）和角色(Role）的集合；增加域(Domain）对象,即授权的作用范围；增加用户(User）和权限（Permission）的关系，即除对角色授权外，单个用户（User)可以直接授权。
基本概念定义：
操作者(Actor)：执行者、参与者。
包含用户（User）和角色（Role）的集合总称，可以是应用系统的代理（agent）,或其它任何能够发起请求的对象.可以反向包含自身，即树状结构。接口中引用的actorUID泛指用户（User）对象、角色（Role)对象和代理对象（agent）的UID值.
JY（User)
发起请求的主体，对应组织机构中得Person对象,或者一个应用代理程序（agent）。可以通过授权管理对用户直接进行授权。
角色(Role)一组具有相同属性或者业务需求的人员集合，是授权的主体，可以是组织模型中的机构、部门、用户组、角色、岗位等。
资源（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．权限过滤
通过设置相应的权限过滤规则，控制资源的权限继承，过滤当前资源节点从父节点继承获得的访问权限。
4．再授权
再授权是指权限拥有者将自己拥有的权限再分配给其他用户，这个授权过程称之为再授权过程.再授权中的权限具有包含关系,即只能授予自己拥有的权限。
5．权限回收：权限回收是指系统回收已经分配给用户的权限。根据不同的情况，通过权限继承得到的权限，如果父权限被回收，子权限必定被回收;通过再授权得到的权限，根据设置不同规则，可规定父权限被回收，保留或回收子权限。
6．权限排斥
权限的排斥主要是指当用户拥有权限A时，则不能同时再拥有权限B.通过定义权限排斥规则，通过静态方式或者动态方式计算权限排斥.
7．负权限：负权限是指操作者不应该拥有的权限。负权限通过权限计算叠加完成，计算时负权限优先。
8．权限等效：权限等效是指如果设置用户B等效于用户A，则用户B拥有用户A的所有权限。A称为被权限等效对象，B称为权限等效对象。权限等效具有时效性。
1.4.3.4. 访问控制接口
访问控制接口分为权限访问接口、管理接口、数据权限接口三类。
1.4.3.5. 数据权限
数据权限根据不同的业务需求,可以划分为行数据权限、数据范围权限、表权限、字段权限。其中行数据权限、数据范围权限可归为行权限,表权限、字段权限可归为列权限。为了对数据资源进行授权和控制，将数据映射为Resource，对数据的操作映射为Operation,整个授权过程与普通的Resource对象相同。
由此根据数据类型的不同，会产生相应的Resource对象：
1．DataRowResource，行数据资源,资源类型名称是dataRowResource，记录行数据的基本信息,由于数据动态产生，只有在数据产生时生成DateRowResource对象.
2．DataScopeResource，数据范围资源,资源类型名称是dataScopeResource，记录符合特定条件的行数据集合，由于包含多条动态数据，DateScopeResource对象只记录产生数据集合的条件，并不包含实体数据。
3．TableResource，表资源，资源类型名称是tableResource，映射数据库表对象.
4．TableColumnResource，字段资源资源类型名称是tableColumnResource，映射数据库表列字段.
1.4.4. 业务流程服务组件
业务流程服务组件实现对不同部门、不同的应用系统协同完成一个事件的调度管理.
1.4.4.1. 概述
业务流程服务示意图
如上图所示,业务流程服务的核心组件是流程服务器，流程服务器可以提供五类服务:流程模型服务、流程实例服务、应用调用服务、流程互操作服务和流程管理服务。流程模型服务：是对流程模型的管理服务。流程模型提供对业务流程的形式化描述，通过流程定义工具输入或输出定义好的流程模型，以及图形化展示。
流程实例服务：是操作并控制流程实例、活动实例运行和状态的服务。本类服务访问