SOA 契约成熟度模型

在 InfoQ 发布的《契约的版本管理、兼容性和可组合性》一文中，涉及了SOA 很多方面的内容，既涵盖了设计时和运行时的设计，又涵盖了治理。这篇文章则描述了那篇版本管理文章中推荐的契约设计策略与SOA 成熟度模型是如何关联起来的。这种关系为实现那篇InfoQ 文章中所描述的契约版本管理和可组合性全部特性提供了一个路线图。本文有意没有涉及策略相关的内容。

微软使用 SOA 成熟度模型（SOAMM）来评估客户的 SOA 现状，并在实现 SOA 所承诺交付的业务灵活性的过程中，把它作为一份路线图。SOAMM 的基础是 CMM，SOAMM 包含了成熟度依次递增的 4 个级别：

1. 基本的
2. 标准化的
3. 高级的
4. 动态的

SOAMM 包含了 36 个技术无关的能力，它可以让你知道，为了实现面向服务方法的价值，你的 IT 系统“哪些是可以实现的”和“哪些是必须实现的”。该模型是微软产品团队、技术布道者和我们的客户共同努力的结晶，是以我们的全球最佳实践为基础的。

这些能力被分成三个视角：

服务实现

这个模型视角描述了企业在构建和提供服务过程中，为实现高效的最佳实践和模式所需具备的能力。这些能力的获得将增强和优化企业业务服务和系统服务的设计和开发。

服务消费

这个模型视角描述了企业为有效采用和促进服务使用所需具备的能力。这个能力为支持和增强他人消费企业服务提供了基础。

服务管理

这个模型视角描述了企业为支持跨组织治理和服务运营所需具备的能力。

你当然可以为你的 SOA 项目选择 3 级或 4 级中的能力，但要是缺乏适当的 1 级和 2 级相关基础，你构建的系统有可能是站不住脚的——有朝一日，你的服务架构将被迫为了和推荐实践保持一致而进行重大调整和重写。

基本成熟度级别

研究表明，大约有 82% 的公司处于这个 SOA 成熟度级别。但不要因为你的成熟度级别处于“基本级”而感到沮丧，当你刚开始你的 SOA 工作或只有少量服务时，处于这个级别是完全合理的。

明确的契约：

这个消费能力的基础是四个经典 SOA 原则中的一个：“服务必须共享模式和契约，而不是实现”。服务的契约和模式（消息和数据）必须基于 SOA 系统意欲支持的业务能力和相关业务文档。契约永远都不应该仅仅是对于某种基于 RPC 的对象模型的简单封装，而应像那篇 InfoQ 文章中所描述的，使用面向服务的消息 ——其基础是使用逻辑数据模型的服务接口。

这个基本能力是一个起点，我推荐“使用标准化的契约设计策略和公共信息模型（参见‘设计模式’，‘统一契约’，‘公共实体’，‘可消费的类型系统’）”快速发展到这一点。

服务识别（筹划服务）：

这个消费能力是标准化成熟度级别“服务的可发现性”能力的简单变种，即一般是通过手工方式将服务元数据分发给潜在消费者。

正如我们在那篇 InfoQ 文章中已经讨论过的，服务的可发现性是服务组合的核心。服务元数据由两部分组成：机器可读元数据和其他相关信息，如服务描述和 SLA。这两种元数据都必须服从在那篇版本管理文章中描述的版本管理策略。

注意，面向服务建模的设计任务服务识别是“服务边界”能力的一部分。

服务边界：

这个消费能力的实际内容是，业务流程建模和领域驱动设计建模技术，将业务能力按服务分门别类，以达成服务的可发现性和重用。它的内涵是，促使潜在消费者通过契约元数据来辨别最符合它们需要的服务和能力。

已识别的服务边界（领域）应该跟服务模型和数据模型结合起来，使它们发展成标准化的服务契约（参见“企业治理”，“统一契约”，“公共实体”，“可消费的类型系统”）。

为了和Thomas Erl 的经典著作《服务设计的SOA 原则》中所描述的“服务松耦合”原则保持一致，这个能力的类别被划为消费而非实现。这个最佳实践的内涵是：避免服务接口和模式与底层实现和技术之间发生紧耦合。这一原则也强烈暗示了“契约优先”的设计方法是首选方法。

开发过程的效率：

所推荐的契约设计策略支持这个能力（在SOAMM 图中由虚线椭圆标出）。

设计、实现和演变服务的过程必须遵循定义良好的、由合适工具支持的软件开发生命周期（SDLC）。SDLC 模型必须从一开始引入，随着成熟度级别的提高，它将从其他SOA 能力定义的指导方针和策略中获益（参见“设计模式”）。

由于其他能力的演变会提高开发过程的效率，因而需要对这个基本能力进行重新考虑。比如，为提供所需业务能力而投入设计、实现和部署新服务操作的时间和精力，将因拥有标准化的契约设计指导方针、公共信息模型、服务抽象和松耦合的策略，以及定义良好的测试和部署过程而获益。

标准化成熟度级别

随着要满足的业务能力需求越来越多，服务数量也在不断增加，强烈推荐在你的SOA 架构和设计实践中包含标准化成熟度级别的能力。

企业治理：

你总应该有一个根据分类法划分服务的服务模型。除此之外，我还强烈推荐创建和使用你的模式所依赖的领域数据模型。如，被称为“公共信息模型（CIM）”的数据模型。参见“公共实体”。

除了设计时治理，服务版本管理相关的运行时治理将会在“部署管理”和“高级监视”能力部分中谈到。

统一契约：

这个消费能力就是“标准化的服务契约”原则。它通过契约制品的标准化统一设计策略对“明确的契约”基本能力进行了扩展。对于简化潜在消费者发现、辨别和使用服务来说，拥有标准化的契约至关重要。正如Thomas Erl 所推荐的，使用公共数据模型，这个能力跟“公共实体”实现能力紧密地关联到了一起。

服务的可发现性：

“服务的可发现性”是SOA 核心原则之一。正如我们在那篇InfoQ 文章中解释的，组合不仅仅取决于针对重用而设计的服务和模式，它们还必须能够被潜在消费者轻易发现。推荐使用存储库作为你的服务目录管理系统，它将给你提供SOA 治理的工具和注册发布机制。

服务的可发现性是SOA 治理的核心，它起到了控制契约及其版本数量的作用，这将使服务的开发和运营都从中受益。强烈推荐将契约元数据制品（如服务和模式）纳入版本管理和治理的范围。这是我们那篇InfoQ 文章的主要内容。

松耦合组合：

这个实现能力的命名并不妥当，因为它混合了相关的“服务松耦合”原则和“服务可组合性”原则。松耦合和“服务抽象”原则及“服务可重用性”原则一起都是可组合服务的核心驱动力。正如我们在那篇InfoQ 文章中数据模型部分指出的，在设计你的模式（以及你的服务）时，你必须为实现松耦合而奋斗，不要在契约中暴露任何底层逻辑或系统的实现细节。

针对可重用性而设计以及拥有版本管理和兼容性策略是实现可组合性的核心。要记住重用和可重用性的区别；避免针对未来才使用（重用）服务的广泛的潜在消费者进行投机性契约设计。相反，要把服务设计成组合服务和流程中的规范元素——可重用性。当然，要是多个消费者能够共享所提供的服务，这也是有好处的。

设计模式：

这个实现能力跟基本的“开发过程效率”能力密切相关。，这些策略和指导方针随着你的成熟度发展到使用诸如“统一契约”，“公共实体”，“可消费的类型系统 ”这些原则而被识别出，它们必须被作为SOA 治理设计策略的一部分被定义和执行。使用公共设计模式是和“标准化的服务契约”SOA 原则保持一致的核心驱动力。

公共实体：

这个实现能力指的是，让在整个企业业务流程中使用的数据拥有公共的格式。这个企业数据模型还有一大堆其他的名字，最为人熟知的是公共信息模型（CIM）。它是EAI 领域中规范数据模型（CDM）在SOA 领域的对应物，CDM 一词是由Gregor Hohpe 和Bobby Woolf 在他们的经典书籍《企业集成模式》中定义的。

注意，不要把“使用CIM”解释成是对在所有系统中使用“唯一正确的模式”的建议。相反，应该基于领域驱动设计的方法使用几个联邦的CIM 模型。

正如我们在那篇InfoQ 文章中描述的，数据模型是创建和维护在服务和业务流程中无处不在的模式的基础。消息和数据的模式都是基于数据模型的——消息模式是一个或多个数据模式的投影。数据模式必须针对重用而设计，而消息模式则要针对它们的操作来设计。这个建模概念是高级成熟度级别“可消费的类型系统”能力的一部分。

高级成熟度级别

任何软件系统中都存在的一个真理是：唯一不变的是变化。变更业务需求将迫使你的服务演变，这应该驱使你在你的SOA 架构和设计实践中包含服务生命周期管理（SLM）。

部署管理：

服务生命周期管理是SOA 治理的核心部分。SLM 包括设计时和运行时两个方面。SLM 和版本管理一起成为了管理“部署管理”能力的核心。除了让现有服务退役之外，你的SDLC 过程还需要有一个关于如何部署新服务和新服务版本的清晰模型。

“部署管理”必须跟“企业治理”能力相结合，这将给服务目录管理员在SLM 的软方面（如将服务生命周期的变更告诉给受影响的消费者）提供帮助。

在那篇InfoQ 文章中，我们推荐让“活动服务版本”策略成为这个能力的一部分，并与所选的作为服务虚拟化机制一部分的企业服务总线模式结合起来。关于服务虚拟化的详情请参见那篇InfoQ 文章。

高级监视：

这个能力支持推荐的契约生命周期策略（在SOAMM 图中由虚线椭圆标出）。

作为服务生命周期管理模型的一部分，你应该监视所有服务个体，以便让服务目录管理员看到服务的使用情况。因此他们能够告知相关消费者正在使用过时或退役的服务，需要进行升级，这将简化服务目录管理员引入新版本的工作。

可消费的类型系统：

这个实现能力指的是，让你的SOA 生态系统中所有的组件有一个可消费的定义：服务、实体、流程、规则、实现、策略、绑定，以及其他服务组件。

定义了“公共实体”模式的公共信息模型将成为这个类型系统中一个必不可少的部分。在服务和流程中使用的消息和数据的模式同样也必须是这个类型系统的一部分。

如果你目前在管理过程中还未用到一个元数据存储库的话，这个能力将触发这个需求的出现。为了提高开发效率、可发现性和重用、版本管理、影响分析和了解组件的使用情况，像这样一个存储库是需要的。如，这将有可能了解到公共实体在服务和消息中被使用的位置。

这个存储库将会是对公共实体和对相关的消息及数据模式建模的自然来源。从一个单一来源生成所有契约模式制品将有益于模式的兼容性和服务的可组合性。关于建模契约模式制品的详情请参考那篇InfoQ 文章。

版本管理支持：

契约需要不断演变以适应不断变化的业务需求，这将同时影响服务和模式。你会发现，随着你SOA 系统的成长和变更，你会需要针对所有契约制品的版本管理策略：服务接口、消息和数据的模式、策略等。版本管理策略必须包括设计时和运行时两方面内容，同时应该通过SOA 治理来强制执行。我推荐阅读InfoQ 上的文章《契约的版本管理、兼容性和可组合性》，它将指导你如何实现这个高级能力。

注意，即便“版本管理支持”是SOAMM 中的高级能力，但由于它跟服务生命周期管理关系紧密，因此强烈推荐尽早开始针对兼容性设计你的契约。拥有服务和模式兼容性策略并不要求具备全面的版本管理和SLM 能力。当恰恰是因为同一服务的多个变种而导致服务数量增加，而成为了消费者，运营者和提供维护的痛楚之时，版本管理就显得必要了。从长远看，要是没有版本管理和SLM 治理，随着活动服务版本数量的增多，你的服务目录会变得混乱不堪。

许多人为了避免版本管理而大量使用通配符，试图借此避免过渡到这个契约成熟度级别。我们绝对不推荐这种做法，因为它会产生不能很好表达语义的模糊契约，有损于服务的可发现性。但是，明智地使用无二义性的通配符，通过提供模式的兼容性，能够帮助最小化服务版本管理的工作。

版本管理能让你控制变更带来的影响；兼容性将帮助你减轻版本管理带来的负面影响。

动态成熟度级别

如今，SOA 承诺的主要价值已经从服务的重用转变成了业务灵活性。动态成熟度级别指的是能够快速建模、组合和改变由你的服务目录所构建的流程，以响应业务需求的变更。

动态组合：

这个能力由推荐的契约设计策略支持（在SOAMM 图中由虚线椭圆标出）。

你服务目录中的服务应该根据“服务的可组合性”原则来设计，并且要符合有一个服务模型和数据模型的推荐，以及其他推荐的设计指导方针和策略——通过SOA 治理来执行。

一旦你拥有了合适的基础能力，你就应该通过实现组合服务和编配来响应业务需求。我认为，拥有受版本管理、基于兼容和联邦信息模型的服务与模式将促进服务的动态组合。

对于没有按照推荐的契约设计策略而设计的服务，试图组合它们会很困难。比如，随着流程的向前推进，需要为转换消息中的不同格式的数据付出额外努力。针对服务的可组合性进行设计将减少使用复杂企业服务总线（ESB）模式或者投资一个全面ESB 平台的需要。这个动态实现能力为组合和执行业务流程提供了一个平台。

流程建模支持：

这个能力由推荐的契约设计策略支持（在SOAMM 图中由虚线椭圆标出）。

这个动态实现能力指的是，支持把来自服务目录的服务建模成流程和工作流。它还包括对流程中决策规则的建模。这个能力提供了必要的工具，以允许组织中合适的角色定义和管理他们所负责的业务能力与流程。拥有一个具备兼容性数据模型的可组合服务目录将极大简化使用BPMN 图或UML 活动图的建模过程。

策略也能够被应用于建模后的流程。这样的例子有权限检查、保密性和完整性需求，以及了解业务流程执行情况（KPI）的业务活动监控（BAM）日志。注意，建模规则驱动的动态策略是一个单独的能力。

结论

正如这篇文章所描述的，契约的版本管理和可组合性方面涉及了SOA 成熟度级别的全部内容。但是，这并不意味着需要采用一种一窝蜂的方式，一次就涉及所有不同的能力——先从基本级别的一小部分开始，随着服务数量的增长有目的地进步到标准化级别。这要跟SOA 治理的需求保持一致；事实上，要想执行标准化的服务，就需要设计时的治理。

随着服务越来越广泛地受到欢迎并被众多消费者大量共享，你将需要实现一些高级成熟度级别的能力，如，专门负责服务生命周期管理的版本和部署管理。

随着成熟度的发展，你最终将达到动态成熟度级别，得以实现承诺的服务重用和业务灵活性——获得SOA 传说中的好处。

查看英文原文： SOA Contract Maturity Model 。

感谢黄璜对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。