SOA治理和框架业务架构的构建

本文探讨了IBM和Oracle的SOA治理框架,分析了SOA治理的关键内容,包括服务全生命周期管理、能力提供及运维监控等方面,并详细阐述了SOA治理的策略与实践。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在前面我们谈到过IBM和Oracle的SOA治理框架和模型。SOA 治理是业务与 IT 治理的交集,注重服务生命周期以确保 SOA 的业务价值。SOA 治理是对服务生命周期的有效管理,而服务生命周期是 SOA 治理的关键目标。对于SOA治理重点解决三个问题,其一是需要做出什么决策?其二是由谁决策?其三是如何让决策落地?

对于Oracle的SOA治理,为了实现业务、企业架构 和 SOA 目标,必须在不同业务领域制定策略:体系结构、技术基础架构、信息、财务、组合、人员、项目(或项目的执行方式)和运营。其比较明显的特点是体现了EA企业架构,业务架构对SOA治理活动的影响和推动。

而IBM的SOA 治理和管理方法(SOA Governance and Management Method,SGMM)是一种端到端的定义方法,通过设计、实现和改进 SOA 治理来进行。IBM的治理生命周期将治理活动分为了计划,定义,使能和度量四个阶段,涉及到服务生命周期各个方面的内容,具体如下:

  • 服务定义,包括服务的范围、接口和边界
  • 服务部署生命周期
  • 服务版本治理,包括兼容性
  • 服务迁移, 包括弃用和退役
  • 服务注册中心,包括依赖关系
  • 服务消息模型,包括规范数据模型
  • 服务监视,包括进行问题确定
  • 服务所有权,包括合作组织
  • 服务测试,包括重复测试
  • 服务安全, 包括可接受的保护范围


对于Oracle和IBM的治理进行对比分析,不断发现存在的一些相同点。从方法上看都覆盖了传统的项目管理,SOA服务工程框架,ITIL运维管理三个方面的内容。从范围上看则包括了组织人员,业务技术和管理三个方面的内容。而从流程上面可以讲是覆盖了服务全生命周期,包括服务识别发现,定义设计,开发测试,上线的前生命周期,也包括了服务开通,运维,监控的后生命周期。

基于以上分析,可以看到SOA治理是一个覆盖服务全生命周期,涉及业务域,服务域和支撑过程域三个方面内容的完整治理框架和模型。如上图所描述一样,通过这种二维的结构,基本上可以看到SOA治理和管控所涉及的全部内容。基于该业务目标架构,SOA治理和管控又包括了如下关键内容:

服务全生命周期管理中心

SOA治理和管控一定要能够对服务全生命周期进行很好的管理,广义点的需要从企业业务目标和流程目标入手,到流程分析和需求分析,到服务识别和发现,到服务定义和设计,服务开发测试,服务上线的全过程有效的管理。对于服务识别和定义阶段,需要对业务域,服务目录,服务进行相应的元数据定义,以形成服务目录库。而服务目录库是后续服务使用和检索,服务设计开发测试的基本依据。

能力提供中心

SOA提供的服务本身就是一种能力,提能力提供中心的意义就在于要将服务转化为一种能力进行提供。达到业务组件化,组件能力化的目标。只要这样才能够更好的推进服务的重用,服务的编排和整合。

对于能力提供中心包括了两个方面的内容,一个是服务前生命周期的管理可以实现服务的入库,服务入库后即转变为服务的能力提供。那么对于需求方可以对服务资产库进行检索,查看自己需要使用的能力,然后进行服务申请,服务开通和使用。

运维监控中心

运维监控中心可以参考ITIL的标准进行构建,包括了事件管理,问题管理,变更管理,性能分析和监控,SLA管理,配置管理库等基本内容。运维监控中心是保证SOA平台能够高可用运行的基础。通过运维监控中心一方面是解决服务使用过程中遇到的问题,一方面是通过预警规则和策略的设置,能够及时的预警SOA平台存在的潜在问题,保证平台的高可用性。

 

 

适用范围

策略实例

治理过程

  • 服务治理角色包括:服务所有者,服务提供者,服务消费者,服务看管人,服务登记员,等等

  • 服务治理委员会包括来自业务,架构,交付以及系统运营等各小组的代表。治理小组的责任是:

    • 定义和维护治理措施和策略

    • 可能的情况下准予设计和实现的例外

    • 服从并向管理层报告

  • 治理策略和控制当由服务登记员,以及相应的评审委员会和架构主体一起监控并推行

开发阶段

  • 服务的设计与开发必须要有强有力的理由才能允许有对策略遵守的例外

  • 服务设计必须基于并考虑到所需求的业务任务的业务执行上下文。业务执行上下文应当能够概括在将来这些服务元素可能发生何种变化

  • 服务设计必须为那些服务潜在的使用者考虑到业务运作的推荐场景。如果这样的场景能得以确定,业务批准和终止就是需要的

  • 服务内部约束对于消费者应当是最小化或者完全隐藏的

  • 一个服务对于内部问题处理的弥补应当对消费者透明并绝不能将其内部执行约束暴露给消费者

  • 服务接口和服务主体(实现)必须遵循公司的安全策略

  • 服务所有者必须为每个发布的服务提供服务分类(业务,基础设施等等)以及范围定义(业务单元,企业,外部等等)

  • “避免去搭建那种对于三个服务可以工作得很好的示例流程,而不去考虑当有三百个时该如何去做”(SOA RA PRD 1)。

生产阶段

  • 所有的业务服务都被要求与它们所支持的每个消费者保持一份服务契约

  • 所有服务都被要求发布服务描述

  • 如果服务不需要服务契约,它的服务水平协议必须要在服务描述里发布

  • 所有的服务都被要求符合版本策略,给所有的消费者提供迁移到服务最新支持版本的机会。

  • 所有的服务描述必须在服务描述存储仓库里发布

  • 所有的运行时服务策略必须在服务策略存储仓库里发布

  • 运行时服务策略应参考其它的策略。策略应由策略执行点(PEP)拦截器来施行并由策略决策点(PDP)机制来保证

  • “…“… 考虑一下,显示少量的服务状态和活动,对于面对数打的服务并且每个服务还有着许多重叠或不同的活动这种危机情形下的操作员是否还会有效”(SOA RA PRD 1)

http://www.cioage.com/art/201210/99301.htm

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值