综合管理服务平台.docx
- 文档编号:1723536
- 上传时间:2023-05-01
- 格式:DOCX
- 页数:60
- 大小:597.33KB
综合管理服务平台.docx
《综合管理服务平台.docx》由会员分享,可在线阅读,更多相关《综合管理服务平台.docx(60页珍藏版)》请在冰点文库上搜索。
综合管理服务平台
1.1.ESB服务总线
1.1.1.概述
各业务系统提供大量的服务接口,如何实现这些服务和接口的编排、调用、重组等,我们采用的是应用服务总线的模式。
通用服务总线采用可靠消息服务(不丢失,不复传)在应用系统之间通过基于消息的异步方式集成各应用系统。
1.1.2.架构设计
ESB服务总线架构图
它负责接入各种服务资
ESBI艮务总线是综合管理服务平台的一个中心组件,
源,通过采用统一服务接口使得各种服务或应用与服务之间可以相互方便访问,以星形结构替代了原来各服务之间的点对点结构,极大地优化了系统连接架构,降低了系统集成的复杂度。
1.1.3.功能设计
ESB应用服务总线基于消息交换组件开发。
采用消息交换组件提供的可靠消
息服务(不丢失,不复传)在应用系统之间通过基于消息的异步方式集成各应用系统。
针对不同系统所处理的消息格式各不相同的特点,ESB应用服务总线提供
了专门的格式代码转换器在不同的消息格式之间按照预先定义好的转换规则进行自动的格式转换,然后将结果自动路由到目标应用系统。
在消息转换的过程中
ESB应用服务总线能够识别XML,C结构,JMS等多种消息格式;对消息的各种操作包括消息的来源、消息的目标应用、所期望的消息格式等通过定义各种操作规则(Rules进行。
ESB应用服务总线可以作为一个消息代理来实现这些功能。
消息代理提供了消息传递层以及消息代理集线器,可被用于消息的处理、转换和分发,并能够将这些功能与发布/预订功能结合在一起。
应用程序格式转换和智能路由功能
作为各个应用的数据吞吐机,提供多种数据格式服务,其中包括:
用户自定义格式,用户可以为每一种应用定制自己的消息格式,通过这种消息格式来连接原有的旧的应用;XML格式;面向纪录的信息格式,如C的头文件,COBOLrecords
等。
对于这些消息格式,提供相应的剖析器进行解析,实现它们之间的格式转换。
如对于用户的bitstream的输入信息可以输出为XML的格式,反之亦然。
从而无
缝地连接现有的应用,并可以采用XML的新标准开发新的应用。
提供检查和过滤功能,根据所传输数据的内容做动态路由。
强大的数据处理功能
作为各个应用的数据处理机,对经过BPI的数据进行各种处理操作,如计算、过滤等,使得数据在从BPI经过时便可以被进行相应地计算,从而发往目的应用系统;支持数据仓库,对各应用系统所传输的数据进行集中记录,便于以后的审计和分析。
对各种应用系统的接口功能
提供强大的连接性,既提供各种与现有商业应用连接的Adapter,可以将企
业内部各种应用系统进行无缝连接,如SAPNotes,Sibel,SWIFTPeopleSoft,
I2等,支持各种标准数据格式或应用的接口,如XML,JDBC对于这些应用可以不必开发新的接口,减少开发的工作量;同时提供应用程序接口,以开发客户化的连接件。
对各种接入协议的支持
ESB应用服务总线支持各种接入协议,其中包括TCP/IPSocketMQ,SOAR
HTTPSCADA等。
适配器技术选择
适配器完成的功能是实现应用系统与EAIHUB之间的连接接口,主要包括数
据与通讯两个层面。
在适配器设计与选型方面,EAI技术提供的方案有多种形式,根据不同的情况作不同的选择。
根据应用对外提供的接口的形式不同,下面对常用的适配器类型进行分析。
基于数据库的接口与适配器
应用系统对外提供的接口是应用数据库,适配器通过对应用数据库的操作来实现EAI与应用间的交互。
此类接口是应用系统可对外提供的最底层的接口类型,允许适配器直接访问应用的数据。
针对此方式,尽管这也是常用方式之一,但其中有很多严重的不足。
使用数据作为应用的接口,意味着将数据的结构体设计暴露出来。
当应用发生改变时,通常需要重新分析、甚至改变此数据接口。
当应用系统的数据改变时,为了触发外部应用,通常需要使用基于应用数据库的外部触发器或使用低效的循环查询策略,这不是一个”干净”的解决方案,外部应用对维护数据的完整性也将负有责任,为此需要理解需要集成的应用系统的结构。
总之,其结果将是难以维护的交错系统。
基于API的接口与适配器
应用软件,通常提供内置于软件库的API,作为与应用系统交互的接口。
相
对数据库接口而言,此类接口是一个更为”干净”的解决方案。
其问题是相对某种平台,如操作系统、编程语言,此API库可能不存在,为解决此问题,需要开
发底层的代码并进行长期的维护。
同时当支撑其运行的产品进行升级时,通常需要对此API进行升级以保证其兼容。
另外,基于API技术,当应用系统有事件发
生时,一般难以提供自动通知功能,需要外部系统进行低效的循环查询。
基于组件的接口与适配器
基于J2EE与CORBAT分布式对象技术,使应用系统的接口有较好的可移植性。
此类接口,可以屏蔽操作系统、编程语言的不同。
此类接口属于紧耦合模式,
为发展中的技术,由于应用系统本身需要提供组件接口,在实际应用中限制了其应用。
基于消息队列的接口与适配器
应用系统对外交互的接口为消息队列,同时提供消息/数据传输的可靠性保
EAI技术
障。
业界领先的消息中间件同时提供同步、异步两种通讯方式。
使用消息队列,消息系统可以管理很多通讯细节。
此种接口方式为典型松耦合模式,是普遍使用的方式之一,可以实现接口的重用能力。
成熟的商业适配器
综合管理服务平台服务库
ESB应用服务总线支持的适配器
ESB应用服务总线提供了诸多的既有的适配器,包括技术适配器与应用适配
器,部分列表如下。
技术适配器:
1〉
JDBC
2〉
JMS
3〉
MQ
4〉
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,同时支持JavaC++,如果应用系统采用中间件技术是
J2EE应用服务器、CORBACICSTuxedo等,都可以很容易的完成适配器的开发。
1.2.应用服务运行框架
1.2.1.总体框架描述
应用服务总体框架是国土资源综合管理服务平台项目的核心,总体框架由系统微内核、系统服务层组成。
系统微内核应能提供最基础、最核心的功能,包括
模块管理、生命周期、服务管理,为整个系统的稳定运行提供保障。
系统服务层应能够提供各类标准化的、技术性的服务如时间服务、审计日志、持久服务、缓存服务、事件服务、事务服务、数据服务等。
框架之上支持公共服务组件和业务服务组件,共同组成综合管理服务平台。
1.2.2.总体框架组成
在本设计方案的总体结构图中,把系统划分为五层,而最底层的基础层提供
了系统运行的环境,最上层的门户展现层提供的进入各个应用系统的入口。
其中应用支撑平台是系统的支撑层。
其中综合管理服务平台是系统的支撑层。
支撑层
包括的主要内容有:
系统微内核、系统服务层。
各层的主要功能分别描述如下。
1.2.2.1.系统微内核
系统本身采用微内核架构,实现模块化、动态化、服务化。
微内核做为整个系统的运行内核,仅提供最基础、最核心的功能,包括模块管理、生命周期、服务管理,为整个系统的稳定运行提供保障,整个系统的各个部分都做为模块直接或间接构建在微内核之上。
1.2.2.2.系统服务层
系统服务层还包含各类标准化的、技术性的服务,而在应用服务层则提供功能性的服务。
系统服务层提供的服务有:
时间服务、审计日志、持久服务、缓存服务、事件服务、事务服务、数据服务等。
本次项目的主要研讨内容为应用服务层中的各个服务组件,因此系统服务层中的基础服务组件将不做为本方案阐述的重点。
1.2.2.3.表现层描述
业务表现层是面对最终用户的接入口,利用综合门户等方式提供各种业务供客户使用,向下须与面向服务的业务层通过正确定义的服务接口实现兼容。
采用的门户技术应该能够支持JSR168Porta规范,能够自由部署第三方的标准Portal。
1.2.3.总体框架的地位和作用
1.从技术复用到业务复用
当前的软件复用大多还是从技术角度出发的,例如J2EE领域的框架只是一
个以库、类和接口形式提供的基础架构,最终构成应用的业务逻辑和表现/控制
逻辑则要由建立在这个框架上的业务组件实现。
而应用软件最终要解决的却是应用问题,或者说是业务问题,如果软件能够在更高层次的业务层面上进行大范围复用,那么对提高软件开发效率的作用将会更大。
只有采用面向服务的设计思想,才能够在更高层次上实现业务复用。
2.业务组件的支撑平台
由于上述的业务组件并不是一个可以独立运行的应用软件,所以需要为它们提供一个赖以生存的运行基础——核心底层机制,特别是组件的管理,如组件的
创建、组件的获得、组件的资源管理、组件的消亡等生命周期支持;以及组件之间相互通讯的渠道和方式。
3.分布式部署的应用系统
如果应用系统只部署在一台机器上,随着系统功能的增加和负载的加大,只有不断提升机器的硬件配置。
我们希望能够把系统按照功能进行划分,以分布式的方式进行部署,将不同的功能模块部署在不同的服务器上,服务器的压力能够有效的降低,使得系统可以以较低的成本继续保持高稳定性和高可用性。
以国土资源信息网络为依托,以标准、制度
以国土资源各类数据库为基础,
和安全体系为保障,以地政、矿政、
以支撑国土资源管理决策为核心,
地质环境等主要管理业务流程优化为主线,形成互联互通、贯穿上下的政务管理、决策支持和社会服务信息化体系。
1.2.4.功能设计
1.2.4.1.应用服务运行管理框架
应用服务运行管理框架简称应用服务框架,是应用服务的运行、监控、管理的框架。
应用服务框架提供了统一的服务库注册、存储、查询的应用服务元数据信息,提供了发布、调用应用服务的功能,可对应用服务及调用进行监控、管理,同时提供了本地和远程调用,可支持分布式应用和负载均衡。
在不同的应用服务框架之间,采用对等的分布式调用机制,可注册远程的服务库到本地。
可通过应用服务框架之间的互操作调用,实现互联互通。
应用服务框架本身不提供访问控制的功能,但可借助访问控制服务模块实现对应用服务的认证、授权和访问控制。
应用服务框架作为软件基础设施,通过部署在上面的服务模块,以标准的协议对外提供服务,可实现更高层次的软件复用和业务复用,可将原有应用系统中
可重用、可共享的功能单元服务化,利于应用系统整合。
务接口描述和调用规范,可屏蔽不同软件平台的差异,实现透明的互操作。
1.2.4.2.服务模块
服务模块是进行部署的最小单位,是满足某些特定功能需求的一组相关应用服务的集合,可以是软件包的形式,也可以是第三方提供的应用服务集合的形式。
服务模块可通过元数据描述文件(附录A:
服务组件描述模式schema)描述并
部署在应用服务框架上,也可通过应用服务框架提供的界面或API来部署,由应用服务框架实行统一的监控和管理。
1.2.4.3.服务组件
服务组件是服务模块的基本组成元素和基本构建单位,是粒度最小的实现和发布单元,是相关的一组应用服务的具体实现,它的功能以应用服务的形式提供。
服务组件具有可设置的属性,其属性是可以改变服务功能的数据。
服务模块由一个或多个服务组件及相关配置信息构成。
1244元数据
1.元数据描述方法
采用摘要表示的方法定义和描述元数据,摘要包括以下属性:
中文名、英文名、数据类型、值域、约束、说明。
中文名:
元数据的中文名称,中文名称在同一类元数据中是唯一的。
英文名:
元数据的英文名称,英文名称在同一类元数据中是唯一的,比较时不区分大小写。
可包含的字符为大小写的英文字母、数字,所有组成词汇为无缝连写。
元数据的数据类型。
值域:
元数据可以取值的范围。
约束:
元数据的约束性条件,包括是否非空、最大出现的次数、是否唯一。
说明:
对元数据含义的进一步的解释及补充说明。
2.应用服务及服务组件元数据
通过应用服务元数据对应用服务进行描述,发布、查找和调用应用服务时都需使用元数据信息。
应用服务和服务组件都使用相同的元数据描述。
本部分定义了核心元数据,即所有应用服务描述中共性的、必不可少的元数据。
124.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.建立组织模型规范及目录
制定全市组织模型规范,统一规范电子政务系统中的组织身份数据模型,主要包括政府部门机构、领导、人员、职位、岗位、职级、用户组、角色等实体对象,以及各实体对象之间的关系。
根据组织模型规范,梳理并建设全市组织身份目录。
组织身份目录是通过对政府机构现状的调查来形成的。
该模型对于组织机构及其相关的身份职责进行了完整的描述;组织身份目录的重点在于职能岗位及其相应的职责,组织身份目录可以认为是现状模型的体现,通过树状的层层细分,给出岗位和职责的映射。
组织身份目录模型图:
groupperson
PK
grouppersonguid
personguidgroupguid
person
PK
personguid
ROLEPERSON
PK
ROLEPERSON
ROLEGUIDPERSONGUID
ROLE
PK
ROLEGUID
DEPARTMENTGUID
personMembers
PK
personMenbersguid
presonguiddepartment
ROLEDEP
PK
ROLEDEP
DEPGUIDROLEGUID
卄
positionperson
PK
positionpersonguid
personguidpositonguid
position
PK
positionguid
dutyguid
iI
d
group
PK
groupguid
departmentguid
1
department
PK
departmentguid
1
1312提供组织身份目录规范的接口
duty
PK
dutyguid
level
level
PK
guid
提供规范的组织模型对外服务接口,所有注册在资源目录中的资源均可通过
API接口获得,下图为平台为用户提供的接口文件列表:
Pfizkdges
{unra上jii;i&±kn詁rirejoFt-platfiznyijltf已・jJt-pIEltje
ri吕BoftrDlnftTrnn理理£rigea^ft.fjlatf=pxri&csoft『latfizym.acct
rLt_blaliiThiAudii»■
iT
Al1Classes
ACLfewesj
[iFJ
HpianJj匕L
血当aanftpcg弓JUT
APFD祇bPt心tVFize■APPI^yn";aLffAECE心肚血APPjTIMPAPKoiln
APPLgiPdtAPP冶!
mlHOeiMt
APPfjgjg
MT坯mLc賈PlkT陛曲J輕肚Irhcn・mt门r6日3亡心・1口~
£■•I!
•哪jrytrtiaflj
FflLCltS^s
rigggeft.•plajtfipmp
rLo^eeft.blatfar*.umess
riaeBpft.platfura.accesa.iJentily
■并1乩ttBSUBSmSfemEBBTCffTiaeflflft上platfor*.nyt:
占」rlghT
厂3graiiff,AlqTfnrw.fiudi・■,斗gj常Aff^^cntToll】ar
苗]1>1AtFflTs.„JfctfAftftt
rlFBtift,Audi«■nturfl^twLt芷uljur
ri炬»朴fl・si-tF胡r・.电nJrg
rlajgUufl.-Dial■njjaEuf
fi9Cg&ft,111 『iNBcft-pIntfuFB.■aGa^er-right Tigegoft・•pJatfimkaso rlseggft,tnatFoiw.u*11 O^rerviwPickiseClaSBTrteD砂館肌cdTo伽氐ItTOfT mn■BL 1.3.2.应用服务目录 建设全市国土资源系统统一的应用服务目录,为实现全市国土资源系统多业务系统应用整合奠定基础。 网络管理员需要管理的应用系统很多。 为了集中对各应用系统中的各个功能进行授权控制,更好的为portal提供完整的应用系统信息,我们在综合管理服务平台中提供应用系统管理服务。 在目录服务中建立一个指定的容器对象,将各应用系统以对象的形式存放在 该容器中,各应用系统的子模块及子功能均可以作为对象以树的方式存放在相应的应用系统对象下。 每一个对象拥有相应的功能模块的基本信息,如: 名称、 URL开发商、版本等信息。 通过应用服务目录的管理可以实现以下的几点: 1. 2. 为集中授权做好基础,通过将各应用系统的功能映射到目录服务相应的对象,就可以利用目录服务技术良好的安全控制机制。 可以集中为应用系统提供有关其他系统的结构及URL信息。 为单点登 录和门户整合提供应用系统的管理支持。 建设全市国土资源系统统一的信息资源目录,为实现全市国土资源系统信息资源的统一描述与发现,为多部门信息资源的共享与整合提供资源环境基础。 信息资源目录体系主要负责全市国土资源系统共享信息资源库的标准化描述和合理化组织。 其中信息资源库的描述主要针对信息资源库的数据存储、访问方法和数据格式进行描述,是揭示信息资源库结构、指导用户使用的检索工具,是用户迅速、准确、有效地寻找信息的向导,是对信息资源实施安全保护的有效手段,并服务于信息资源共享平台的资源查找和定位。 信息资源目录可根据全市各级国土资源部门提供资源的情况,动态更新,及时反映共享数据资源接入的情况。 它是面向信息资源共享平台和全市国土资源系统工作人员浏览和查询资源库信息的基础,是揭示信息资源库结构、指
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 综合 管理 服务 平台