国土资源
综合管理服务平台
建
设
方
案
目录
1. ESB服务总线 (7)
1.1. 概述 (7)
1.2. 架构设计 (7)
1.3. 功能设计 (8)
2. 应用服务运行框架 (14)
2.1. 总体框架描述 (14)
2.2. 总体框架组成 (14)
2.2.1. 系统微内核 (15)
2.2.2. 系统服务层 (15)
2.2.3. 表现层描述 (15)
2.3. 总体框架的地位和作用 (16)
2.4. 功能设计 (17)
2.4.1. 应用服务运行管理框架 (17)
2.4.2. 服务模块 (18)
2.4.3. 服务组件 (18)
2.4.4. 元数据 (18)
2.4.5. 应用服务框架组成 (20)
2.4.6. 接口定义 (22)
3. 资源目录建设 (22)
3.1. 组织身份目录 (23)
3.1.1. 建立组织模型规范及目录 (24)
3.1.2. 提供组织身份目录规范的接口 (25)
3.2. 应用服务目录 (26)
3.3. 信息资源目录 (27)
3.3.1. 资源服务的注册维护 (28)
3.3.2. 资源服务的目录组织 (28)
3.3.3. 共享资源的注册发布 (29)
4. 公共服务组件 (29)
4.1. 组织模型管理组件 (29)
4.1.1. 组织模型实体定义 (33)
4.1.2. 组织身份模型实体关系 (34)
4.2. 身份服务组件 (36)
4.3. 访问控制服务组件 (36)
4.3.1. 概述 (37)
4.3.2. 权限管理模型 (38)
4.3.3. 访问控制规则 (39)
4.3.4. 访问控制接口 (40)
4.3.5. 数据权限 (40)
4.4. 业务流程服务组件 (41)
4.4.1. 概述 (42)
4.4.2. 流程模型服务 (43)
4.4.3. 流程实例服务 (43)
4.4.4. 应用调用服务 (43)
4.4.5. 流程互操作服务 (44)
4.46 流程管理服务 (44)
4.4.7. 业务电子表单组件 (44)
4.4.8. 概述 (45)
4.4.9. 服务组成部分 (45)
4.4.10. 业务电子表单接口 (46)
4.5. 单点登录组件 (46)
4.5.1. 概述 (46)
4.5.2. 功能设计 (48)
4.5.3. 单点登录接口 (49)
5. 平台标准规范建设 (49)
5.1. 应用服务框架规范 (50)
5.1.1. 范围 (50)
5.1.2. 规范性引用文档 (50)
5.1.3. 术语和定义 (51)
5.1.4. 元数据 (54)
5.1.5. 应用服务框架组成 (55)
5.1.6. 接口定义 (57)
5.2. 组织身份模型数据规范 (57)
5.2.1. 范围 (57)
5.2.2. 规范性引用文件 (57)
5.2.3. 术语和定义 (58)
5.2.4. 组织身份模型概述 (58)
5.2.5. 组织模型定义 (59)
5.3. 单点登录服务接口规范 (62)
5.3.1. 范围 (62)
5.3.2. 术语和定义 (63)
5.3.3. 作用 (63)
5.3.4. 单点登录服务逻辑 (64)
5.3.5. 接口定义 (65)
5.4. 访问控制服务接口规范 (65)
5.4.1. 范围 (65)
5.4.2. 规范性引用文档 (65)
5.4.3. 权限管理模型 (66)
5.4.4. 访问控制接口 (71)
5.4.5. 访问控制要求 (71)
5.5. 组织身份服务接口规范 (72)
5.5.1. 范围 (72)
5.5.2. 规范性引用文件 (72)
5.5.3. 作用 (73)
5.5.4. 接口定义 (73)
5.6. 组织身份命名规范 (73)
5.6.1. 姓名 (73)
5.6.2. 登录帐号 (74)
5.6.3. 其他信息 (75)
1. ESB 服务总线
1.1. 概述
各业务系统提供大量的服务接口， 如何实现这些服务和接口 的
编排、调用、重组等，我们采用的是应用服务总线的模式。通 用服
务总线采用可靠消息服务（不丢失，不复传）在应用系统之 间通过
基于消息的异步方式集成各应用系统。
1.2. 架构设计
ESB 服务总线架构图ESB 服务总线是综合管理服务平台的一个中心组件，它负 责接
入各种服务资源，通过采用统一服务接口使得各种服务或应 用与服
务之间可以相互方便访问， 以星形结构替代了原来各服务 之间的点
对点结构，极大地优化了系统连接架构， 降低了系统集
成的复杂度。
动态路由
实时服务 异步服务 服务注册 服务查找 安全控制
异常处理 格式转换 格式校验 系统监控 发布订阅 日志记录 数据存取 内容过滤 系统管理
接口 /服务 *
接口 /服务
接口 /服务 组织机构 权限 流程表单 接口 /服务
即时通讯 报表
电子政务
综合监管 数据管理
接口 /服务 接口 /服务 社会化服 务 服务总线 接口 /服务
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
J2EE(/Portal)
.NET 客户机 第三方应用服
务器供应商 .NET 供应商 SOAP/HTTP TDS/MQ
文本/JMS SOAP/HTTP ESB 艮务总线 C/S 应用系CSV/MQ SWIFT/MQ
传统定制服务
的供应商
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等，都可以很容易的完成适配器的开发。
2. 应用服务运行框架
2.1. 总体框架描述
应用服务总体框架是国土资源综合管理服务平台项目的核
心，总体框架由系统微内核、系统服务层组成。系统微内核应能提供最基础、最核心的功能，包括模块管理、生命周期、服务管理，为整个系统的稳定运行提供保障。系统服务层应能够提供各
类标准化的、技术性的服务如时间服务、审计日志、持久服务、缓存服务、事件服务、事务服务、数据服务等。框架之上支持公共服务组件和业务服务组件，共同组成综合管理服务平台。
2.2. 总体框架组成
在本设计方案的总体结构图中，把系统划分为五层，而最底层的基础层提供了系统运行的环境，最上层的门户展现层提供的进入各个应用系统的入口。其中应用支撑平台是系统的支撑层。
其中综合管理服务平台是系统的支撑层。支撑层包括的主要内容有：系统微内核、系统服务层。各层的主要功能分别描述如下表现层'■系统管理
安
全
保
障
休
系
系统服务层
系统微内核
资源层
2.2.1.系统微内核
系统本身采用微内核架构，实现模块化、动态化、服务化。
微内核做为整个系统的运行内核，仅提供最基础、最核心的功能，包括模块管理、生命周期、服务管理，为整个系统的稳定运行提供保障，整个系统的各个部分都做为模块直接或间接构建在微内核之上。
2.2.2. 系统服务层
系统服务层还包含各类标准化的、技术性的服务，而在应用
服务层则提供功能性的服务。系统服务层提供的服务有：时间服务、审计日志、持久服务、缓存服务、事件服务、事务服务、数据服务等。
本次项目的主要研讨内容为应用服务层中的各个服务组件，因此系统服务层中的基础服务组件将不做为本方案阐述的重点。
2.2.
3. 表现层描述
业务表现层是面对最终用户的接入口，利用综合门户等方式
提供各种业务供客户使用，向下须与面向服务的业务层通过正确定义的服务接口实现兼容。采用的门户技术应该能够支持JSR168Portal
规范，能够自由部署第三方的标准Portal。
2.3. 总体框架的地位和作用
1. 从技术复用到业务复用
当前的软件复用大多还是从技术角度出发的，例如J2EE领
域的框架只是一个以库、类和接口形式提供的基础架构，最终构成应用的业务逻辑和表现/控制逻辑则要由建立在这个框架上的业务组件实现。而应用软件最终要解决的却是应用问题，或者说是业务问题，如果软件能够在更高层次的业务层面上进行大范围复用，那么对提高软件开发效率的作用将会更大。只有采用面向服务的设计思想，才能够在更高层次上实现业务复用。
2. 业务组件的支撑平台
由于上述的业务组件并不是一个可以独立运行的应用软件，所以需要为它们提供一个赖以生存的运行基础一一核心底层机制，特别是组件的管理，如组件的创建、组件的获得、组件的资源管理、组件的消亡等生命周期支持；以及组件之间相互通讯的
渠道和方式。
3. 分布式部署的应用系统
如果应用系统只部署在一台机器上，随着系统功能的增加和负载的加大，只有不断提升机器的硬件配置。我们希望能够把系统按照功能进行划分，以分布式的方式进行部署，将不同的功能模块部署在不同的服务器上，服务器的压力能够有效的降低，使得系统可以
以较低的成本继续保持高稳定性和高可用性。
以国土资源各类数据库为基础，以国土资源信息网络为依托，以标准、制度和安全体系为保障，以地政、矿政、地质环境等主要管理业务流程优化为主线，以支撑国土资源管理决策为核心，形成互联互通、贯穿上下的政务管理、决策支持和社会服务信息化体系。
24功能设计
241.应用服务运行管理框架
应用服务运行管理框架简称应用服务框架，是应用服务的运行、监控、管理的框架。
应用服务框架提供了统一的服务库注册、存储、查询的应用服务元数据信息，提供了发布、调用应用服务的功能，可对应用服务及调用进行监控、管理，同时提供了本地和远程调用，可支持分布式应用和负载均衡。
在不同的应用服务框架之间，采用对等的分布式调用机制，可注册远程的服务库到本地。可通过应用服务框架之间的互操作调用，实现互联互通。
应用服务框架本身不提供访问控制的功能，但可借助访问控制服务模块实现对应用服务的认证、授权和访问控制。
应用服务框架作为软件基础设施，通过部署在上面的服务模
块，以标准的协议对外提供服务，可实现更高层次的软件复用和业
务复用，可将原有应用系统中可重用、可共享的功能单元服务化，利于应用系统整合。
应用服务框架提供高度可集成的能力，采用标准的Web服务协议组作为服务接口描述和调用规范，可屏蔽不同软件平台的
差异，实现透明的互操作。
242.服务模块
服务模块是进行部署的最小单位，是满足某些特定功能需求
的一组相关应用服务的集合，可以是软件包的形式，也可以是第三方提供的应用服务集合的形式。服务模块可通过元数据描述文
件（附录A :服务组件描述模式schema ）描述并部署在应用服务框架上，也可通过应用服务框架提供的界面或API来部署，由应用服务框架实行统一的监控和管理。
2.4.
3. 服务组件
服务组件是服务模块的基本组成元素和基本构建单位，是粒度最小的实现和发布单元，是相关的一组应用服务的具体实现，它的功能以应用服务的形式提供。服务组件具有可设置的属性，其属性是可以改变服务功能的数据。
服务模块由一个或多个服务组件及相关配置信息构成。
244.元数据
1.元数据描述方法