综合管理服务平台培训资料(doc 47页)

综合管理服务平台培训资料(doc 47页)1.1. ESB 服务总线1.1.1. 概述各业务系统提供大量的服务接口，如何实现这些服务和接口的编排、调用、重组等，我们采用的是应用服务总线的模式。

通用服务总线采用可靠消息服务（不丢失，不复传）在应用系统之间通过基于消息的异步方式集成各应用系统。

1.1.2. 架构设计 DB 电子政务接口/服务综合监管接口/服务社会化服务接口/服务数据管理接口/服务服务总线动态路由实时服务异步服务服务注册服务查找安全控制异常处理格式转换格式校验系统监控发布订阅日志记录数据存取内容过滤系统管理组织机构接口/服务权限接口/服务流程表单接口/服务即时通讯接口/服务报表接口/服务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，对于这些应用可以不必开发新的接口，减少开发的工作量；同时提供应用程序接口，以开发客户化的连接件。

3〉Web Services应用适配器：1〉SAP2〉Siebel3〉Spirent4〉Ariba Buyer5〉BroadVision6〉Clarify7〉eMatrix8〉i29〉i2 ADW10〉Metasolv TBS11〉Nightfire12〉Oracle Applications13〉PeopleSoft14〉Portal Infranet15〉QAD16〉Retek17〉Telcordia Service Delivery18〉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)服务请求者在服务库中查找所需服务，根据返回的结果确定需要调用的应用服务。