重访SOA治理

作者 Boris Lublinsky 译者 胡键 发布于 2008年6月5日 上午6时5分

社区

Architecture,

SOA

主题

治理,

企业架构

标签

服务设计,

IBM,

IBM Rational,

SOA Appliance,

SOA实施

尽管SOA项目实施呈增长趋势，但是多数项目依旧在走向失败。事情常常变得如此糟糕——最近有篇文章的名字非常贴切《SOA，还是DOA》，其中DOA代表“死亡之旅（Dead on Arrival）”。改善这种状况的办法之一就是正确地实施SOA治理。

Rescent Muhammed Yaseen Muriankara的文章——SOA治理框架和解决方案架构——定义了治理的3个基本层次。企业治理是：

建立权利下放的责任、授权和沟通链路；建立使人们能履行他们角色和职责的度量、策略和控制机制。

企业治理的子集是IT治理

与组织的信息技术处理和那些处理支持业务目标的方式相关的治理方面。

最后，SOA治理被定义为：

一种规范化的IT治理，在服务组件、服务和业务过程生命周期的上下文中放置关键IT治理决策。SOA治理的关键目标就是对这种生命周期进行有效地管理。

该文给出了IBM实施SOA治理的方法论和模型——SOA治理和管理方法（SOA Governance and Management Method，SGMM）。该方法论使用IBM Rational® Method Composer进行文档化，该工具已提供了下载。

SGMM围绕服务生命周期进行构建，涵盖以下内容：

服务定义

SOA治理的最基本方面，负责服务的创建。必须识别服务、描述它们的功能、界定它们的行为和设计它们的接口。

服务测试

SOA增加了测试单个功能的机会，也提高了对它按意图工作的预期。但是，SOA还引入了重新测试相同功能的机会，该过程不断地被每个不信任其使用服务的新消费者重复。同时，由于组合应用共享服务，单个有问题的服务会对一组貌似无关的应用产生负面影响，放大了那些编程错误的结果。

服务部署生命周期

服务并不是瞬间出现，然后就永远存在。与任何软件类似，它们需要被规划、设计、实现、部署、维护和最终退役。应用生命周期可以被公开并影响组织的很多部分，但是服务的生命周期影响更大，因为多个应用会依赖于一个服务。

服务版本控制

服务版本控制可以让那些对现有服务满意的用户无需修改继续使用服务，同时允许服务为满足新需求进行演化。当前的服务接口和行为被作为一个版本保留，同时更新的服务被作为另一个版本而引入。

服务归属

一个服务应该反映它的业务。通常这意味着改变服务以适应业务，但是在某些情况下，可能需要改变业务以适应服务。当无法这样做时，多个部门间需要增加合作层级以分担开发公共服务的担子。实际上，这个合作团体可由跨组织的常务委员会组成，它拥有服务并管理它们。

服务安全

SOA创建了易于重用的服务，即使是那些本不该使用它们的消费者亦可轻易地重用它们。即便在授权用户中，也不是所有用户应该访问服务存取的全部数据。就保密性、完整性和不可否认性来说，一些服务消费者比相同服务的其他消费者有更高的要求。

服务监控

一个组合应用可以同时消费多个服务，它的可靠性与它依赖服务的可靠性相当。因为多个组合应用可以共享一个服务，单个服务的失效会影响多个应用。为了描述消费者可依赖的可靠性和效率，必须定义SLA。为了确保服务提供者满足它们定义的SLA，必须对服务提供者进行监控。

本文不仅仅只描述了SOA治理方法论，而且还介绍了一组支持和（至少是部分的）自动化大多数治理过程的工具（治理平台）。

启动一个项目必需的最小自动化能力包括：

一个集中的注册中心和仓库，用来寻找和发布服务相关部件和元数据。以下功能必须依赖它：

• 寻找合适的经授权的服务。
• 避免重复劳动。
• 鼓励重用。
• 识别服务在SOA生命周期内的现状。
• 给服务的订阅者提供可视化能力。
• 寻找相关服务和服务变更的影响。
• 通知服务变更完成。

一种为服务关联和强制可应用策略的机制。这些策略使用治理框架进行定义。

一种可定制的生命周期感知系统，在生命周期内阶段变更时触发验证，以便使一个阶段一个阶段的治理验证可自动化。

理想情况下，注册中心应该是被SOA运行时优化的，这样就可在运行时通过动态路由来丰富注册中心中存放的元数据。

文章本身和其后的参考列表对于涉足SOA实施（尤其是SOA治理）的每一个人来说都是一份非常好的阅读材料。

查看英文原文：SOA Governance Revisited

• 更早的 >