可消费的类型系统：
这个实现能力指的是，让你的SOA生态系统中所有的组件有一个可消费的定义：服务、实体、流程、规则、实现、策略、绑定，以及其他服务组件。
定义了“公共实体”模式的公共信息模型将成为这个类型系统中一个必不可少的部分。在服务和流程中使用的消息和数据的模式同样也必须是这个类型系统的一部分。
如果你目前在管理过程中还未用到一个元数据存储库的话，这个能力将触发这个需求的出现。为了提高开发效率、可发现性和重用、版本管理、影响分析和了解组件的使用情况，像这样一个存储库是需要的。如，这将有可能了解到公共实体在服务和消息中被使用的位置。
这个存储库将会是对公共实体和对相关的消息及数据模式建模的自然来源。从一个单一来源生成所有契约模式制品将有益于模式的兼容性和服务的可组合性。关于建模契约模式制品的详情请参考那篇InfoQ文章。
版本管理支持：
契约需要不断演变以适应不断变化的业务需求，这将同时影响服务和模式。你会发现，随着你SOA系统的成长和变更，你会需要针对所有契约制品的版本管理策略：服务接口、消息和数据的模式、策略等。版本管理策略必须包括设计时和运行时两方面内容，同时应该通过SOA治理来强制执行。我推荐阅读InfoQ上的文章《契约的版本管理、兼容性和可组合性》，它将指导你如何实现这个高级能力。
注意，即便“版本管理支持”是SOAMM中的高级能力，但由于它跟服务生命周期管理关系紧密，因此强烈推荐尽早开始针对兼容性设计你的契约。拥有服务和模式兼容性策略并不要求具备全面的版本管理和SLM能力。当恰恰是因为同一服务的多个变种而导致服务数量增加，而成为了消费者，运营者和提供维护的痛楚之时，版本管理就显得必要了。从长远看，要是没有版本管理和SLM治理，随着活动服务版本数量的增多，你的服务目录会变得混乱不堪。
许多人为了避免版本管理而大量使用通配符，试图借此避免过渡到这个契约成熟度级别。我们绝对不推荐这种做法，因为它会产生不能很好表达语义的模糊契约，有损于服务的可发现性。但是，明智地使用无二义性的通配符，通过提供模式的兼容性，能够帮助最小化服务版本管理的工作。
版本管理能让你控制变更带来的影响；兼容性将帮助你减轻版本管理带来的负面影响。
动态成熟度级别
如今，SOA承诺的主要价值已经从服务的重用转变成了业务灵活性。动态成熟度级别指的是能够快速建模、组合和改变由你的服务目录所构建的流程，以响应业务需求的变更。
动态组合：
这个能力由推荐的契约设计策略支持（在SOAMM图中由虚线椭圆标出）。
你服务目录中的服务应该根据“服务的可组合性”原则来设计，并且要符合有一个服务模型和数据模型的推荐，以及其他推荐的设计指导方针和策略——通过SOA治理来执行。
一旦你拥有了合适的基础能力，你就应该通过实现组合服务和编配来响应业务需求。我认为，拥有受版本管理、基于兼容和联邦信息模型的服务与模式将促进服务的动态组合。
对于没有按照推荐的契约设计策略而设计的服务，试图组合它们会很困难。比如，随着流程的向前推进，需要为转换消息中的不同格式的数据付出额外努力。针对服务的可组合性进行设计将减少使用复杂企业服务总线（ESB）模式或者投资一个全面ESB平台的需要。这个动态实现能力为组合和执行业务流程提供了一个平台。
流程建模支持：
这个能力由推荐的契约设计策略支持（在SOAMM图中由虚线椭圆标出）。
这个动态实现能力指的是，支持把来自服务目录的服务建模成流程和工作流。它还包括对流程中决策规则的建模。这个能力提供了必要的工具，以允许组织中合适的角色定义和管理他们所负责的业务能力与流程。拥有一个具备兼容性数据模型的可组合服务目录将极大简化使用BPMN图或UML活动图的建模过程。
策略也能够被应用于建模后的流程。这样的例子有权限检查、保密性和完整性需求，以及了解业务流程执行情况（KPI）的业务活动监控（BAM）日志。注意，建模规则驱动的动态策略是一个单独的能力。
结论
正如这篇文章所描述的，契约的版本管理和可组合性方面涉及了SOA成熟度级别的全部内容。但是，这并不意味着需要采用一种一窝蜂的方式，一次就涉及所有不同的能力——先从基本级别的一小部分开始，随着服务数量的增长有目的地进步到标准化级别。这要跟SOA治理的需求保持一致；事实上，要想执行标准化的服务，就需要设计时的治理。
随着服务越来越广泛地受到欢迎并被众多消费者大量共享，你将需要实现一些高级成熟度级别的能力，如，专门负责服务生命周期管理的版本和部署管理。
随着成熟度的发展，你最终将达到动态成熟度级别，得以实现承诺的服务重用和业务灵活性——获得SOA传说中的好处。
文章来源于领测软件测试网 https://www.ltesting.net/
