综合管理服务平台Word文件下载.docx
《综合管理服务平台Word文件下载.docx》由会员分享，可在线阅读，更多相关《综合管理服务平台Word文件下载.docx（49页珍藏版）》请在冰点文库上搜索。
支持数据仓库，对各应用系统所传输的数据进行集中记录，便于以后的审计和分析。
对各种应用系统的接口功能
提供强大的连接性，既提供各种与现有商业应用连接的Adapter，可以将企业内部各种应用系统进行无缝连接，如SAP，Notes，Sibel，SWIFT，PeopleSoft，I2等，支持各种标准数据格式或应用的接口，如XML，JDBC，对于这些应用可以不必开发新的接口，减少开发的工作量；
同时提供应用程序接口，以开发客户化的连接件。
对各种接入协议的支持
ESB应用服务总线支持各种接入协议，其中包括TCP/IPSocket，MQ，SOAP，HTTP，SCADA等。
适配器技术选择
适配器完成的功能是实现应用系统与EAIHUB之间的连接接口，主要包括数据与通讯两个层面。
在适配器设计与选型方面，EAI技术提供的方案有多种形式，根据不同的情况作不同的选择。
根据应用对外提供的接口的形式不同，下面对常用的适配器类型进行分析。
基于数据库的接口与适配器
应用系统对外提供的接口是应用数据库，适配器通过对应用数据库的操作来实现EAI与应用间的交互。
此类接口是应用系统可对外提供的最底层的接口类型，允许适配器直接访问应用的数据。
针对此方式，尽管这也是常用方式之一，但其中有很多严重的不足。
使用数据作为应用的接口，意味着将数据的结构体设计暴露出来。
当应用发生改变时，通常需要重新分析、甚至改变此数据接口。
当应用系统的数据改变时，为了触发外部应用，通常需要使用基于应用数据库的外部触发器或使用低效的循环查询策略，这不是一个”干净”的解决方案，外部应用对维护数据的完整性也将负有责任，为此需要理解需要集成的应用系统的结构。
总之，其结果将是一个难以维护的交错系统。
基于API的接口与适配器
应用软件，通常提供内置于软件库的API，作为与应用系统交互的接口。
相对数据库接口而言，此类接口是一个更为”干净”的解决方案。
其问题是相对某种平台，如操作系统、编程语言，此API库可能不存在，为解决此问题，需要开发底层的代码并进行长期的维护。
同时当支撑其运行的产品进行升级时，通常需要对此API进行升级以保证其兼容。
另外，基于API技术，当应用系统有事件发生时，一般难以提供自动通知功能，需要外部系统进行低效的循环查询。
基于组件的接口与适配器
基于J2EE与CORBA的分布式对象技术，使应用系统的接口有较好的可移植性。
此类接口，可以屏蔽操作系统、编程语言的不同。
此类接口属于紧耦合模式，为发展中的技术，由于应用系统本身需要提供组件接口，在实际应用中限制了其应用。
基于消息队列的接口与适配器
应用系统对外交互的接口为消息队列，同时提供消息/数据传输的可靠性保障。
业界领先的消息中间件同时提供同步、异步两种通讯方式。
使用消息队列，消息系统可以管理很多通讯细节。
此种接口方式为典型松耦合模式，是EAI技术普遍使用的方式之一，可以实现接口的重用能力。
成熟的商业适配器
ESB应用服务总线支持的适配器
ESB应用服务总线提供了诸多的既有的适配器，包括技术适配器与应用适配器，部分列表如下。
技术适配器：
1〉JDBC
2〉JMS
3〉MQ
4〉E-mail
5〉JText
6〉MicrosoftExchange
7〉WebServices
应用适配器：
1〉SAP
2〉Siebel
3〉Spirent
4〉AribaBuyer
5〉BroadVision
6〉Clarify
7〉eMatrix
8〉i2
9〉i2ADW
10〉MetasolvTBS
11〉Nightfire
12〉OracleApplications
13〉PeopleSoft
14〉PortalInfranet
15〉QAD
16〉Retek
17〉TelcordiaServiceDelivery
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.组织模型管理组件
组织模型管理组件实现对组织模型的管理服务，用来定义组织形式的模型，以职责、权限的形式定义成员、各个部门的作用与任务，同时提供灵活的结构以适应不同的部门或不同的组织结构。
本组件提供对组织模型的管理服务。
在本项目中根据组织模型规范，梳理并建设全市国土资源系统党政机关电子政务组织身份目录。
组织身份目录是通过对政府机构现状调查来形成的。
该模型对于政府组织机构及其相关身份职责进行了完整描述；
组织身份目录重点在于职能岗位及其相应职责，组织身份目录可以认为是现状模型体现，通过树状层层细分，给出岗位和职责映射。
组织模型的地位和作用
电子政务组织模型就是对政府组织结构进行建模，是利用抽象的模型或者元素，构造出的一系列关系，用于表达政府组织机构中的实体间的层次和隶属。
组织模型是用来定义政府的组织形式的模型，它以职责、权限的形式定义了政府成员、政府各个部门的作用与任务，同时提供灵活的结构以适应不同的政府部门或不同的组织结构。
组织模型是大部份电子政务应用系统构建的基础。
几乎所有的电子政务应用系统都涉及到组织机构模型的建设，一个组织机构模型的好坏直接影响到基于它构建的其它应用系统。
组织机构模型对现实中的机构进行了抽象建模，提供了统一的概念和语义。
通过组织模型的建设能很好的解决电子政务应用中人员调动、权限变化、职位变迁、部门合并、分级授权管理等各种业务问题
组织模型提供了一个统一的抽象，对用户统一集中管理，可管理多级用户，支持用户分类分组、多种用户接口、用户权限安全等方面的管理。
组织模型为单点登录、统一授权提供基础，它为灵活授权、统一管理提供了基础。
组织模型支持各种业务应用
在当前的电子政务领域，通常一个部门或一个机构拥有多个应用系统，而这些应用系统往往由多个厂家承建，他们基于不同的组织机构模型建立的，虽然它们面对的是同一个机构、同一个部门。
这些组织机构模型在实体的抽象、定义等各个方面都存在很大的差异，导致面对现实中同一个东西，在模型中表现出来的却千差万别。
这样导致新的系统不能重用以前建设好的组织模型，它只能重新建设一个供它自己专用的新的组织模型。
就这样，随着应用系统的增加，组织机构模型也随着增加。
这样就带来了很多问题：
首先，是组织机构模型的重复建设，浪费财力物力。
其次，是越来越多的各式各样的组织模型，给管理维护带来了巨大的工作量的复杂性，增大了维护工作的出错率，影响系统的稳定性。
再次，是组织模型的分离导致了各个应用系统处于孤立状态，对各个应用系统进行协作带来了很多的困难。
升级会员 