Thomas Erl 的《SOA 设计模式》中的 3 个模式

《SOA 设计模式》的 第一稿草拟了 60 个模式，这些模式经过了来自全球 100 多个 SOA 专家的审阅，草稿同时也发布在 soapatterns.org 上接受公众的审阅。SOA 社区也受邀贡献出他们在生产环境里使用并验证过的模式，社区的回应带来了 34 个新模式。最后的目录是 85 个独立的或复合的模式，加上 28 个候选模式，他们目前还继续接受来自 SOA 社区的进一步审阅。这些模式可以用作 SOA 设计实现 的原则。在本文中，我们为大家奉上 3 种服务目录的治理模式：规范表述、元数据集中和规范版本控制，三者都摘自 Thomas Erl 编著的《SOA 设计模式》的第 10 章。

在服务目录设计伊始，我们就可以通过某些步骤来降低最终付出的努力以及由于不得不管理服务目录而造成的影响。本章展现的一组模式为读者提供了基本的设计时解决方案，说具体点就是应谨记服务目录实现后的发展于脑海中。

规范表述（Canonical Expression，275）提炼了服务契约，从而使服务更容易被发现，它通常与元数据集中（Metadata Centralization，280）联合使用，元数据集中的核心是为了促使服务契约的发现而建立一个服务注册中心。二者被规范版本控制 （Canonical Versioning，286）进一步补充，而后者要求采用统一的，服务目录级的版本策略。

我们认为这三个模式是服务目录治理的基础，它们支持服务发现原则，并受其影响。服务发现原则要求以方便有效发现和解释的方式来规范服务的元数据信息。

注：本章描述的治理模式仅集中在基本的技术和设计相关的治理问题。该丛书系列中的《SOA 治理》（SOA Governance）将会带来更多技术和组织方面的最佳实践及模式集合。

规范表述

如何一致理解和解释服务契约？

问题

服务契约中可能使用不同的方式描述相似的能力，导致不一致性和误解的风险。

解决方法

通过命名规则标准化服务契约。

应用

命名规则作为正式分析和设计过程的一部分应用于服务契约。

影响

使用全局命名规则引入了需要被强制一致使用的企业级标准。

原则

标准化服务契约、服务发现

架构

企业、服务目录、服务

表 10.1
规范表述模式概述

问题

由不同时期的不同项目交付或扩展的服务契约自然是由开发或扩展它们的架构师和开发者所确定的。这种方式就会导致服务上下文以及由服务上下文语法所定义及描 述的服务个体功能的不同。有些可能采用详尽冗长的描述习惯，而其他可能采用简洁且技术性的格式风格。再者，用于描述常用及相似功能的实际词汇也不尽相同。

因为服务的定位是企业资源，所以完全有理由期望其他项目组发现和理解服务契约，从而理解服务应被如何使用。技术性服务契约描述的不一致性可能会引起不断的 （技术层面上的）误解风险，从而会阻碍发现的过程。大量这种不一致性的激增会进一步扭曲服务目录的形象，增加在不同服务契约之间查找以及设计复合服务的工 作成本。

解决方案

标准化的命名规则能够应用于所有服务契约的交付过程，从而保证服务上下文和服务功能的表达一致性（图 10.1）。

图 10.1
服务契约的表达在服务间保持一致。

应用

需要建立一组作为正式设计标准的命名及功能描述的命名规则。通过在公共分析和设计过程中强制使用这些规则来实现服务契约设计的一致性。

服务表达相关的标准的一个例子是 CRUD（增删改查），传统上，它用于给组件配备一组可预见的方法。尤其是实体服务，最符合这种模式的应用，因为它们经常需要这类数据处理功能并且要求使用标准化的动词来表达它们。

特别是 Web 服务，该模式可能会影响 WSDL 定义文件的设计，如图 10.2 所示。

图 10.2
受规范表述影响的 4 个服务的 WSDL 定义

注： 不论服务是否解耦，该模式都能被应用。

影响

乍一看，规范表述的影响可能比较微弱，然而，当要创建一组服务，特别是在大型企业的环境下，一致的功能表述将会大大减少身边的风险因素。

成功应用该模式的主要需求是相关设计标准的引入和加强。如果已经为支持解耦契约（Decoupled Contract，401）和规范模式（Canonical Schema，158）建立了正式的设计流程，那么在该过程中为规范表述增加一个独立步骤所需的工作是很少的。

注意，不同于往往由于治理的影响而必须限定在服务目录域内的规范模式（Canonical Schema，158），该模式能很容易地定位成企业级标准。在企业的各个域建立一致性的描述，对整个企业来说裨益颇多。

关系

由规范表述引入的命名规则对其他若干模式的应用都有影响（如图 10.3 的上方所列出的）。该模式加强了服务识别和重用的直观性，它完全支持契约集中 （Contract Centralization，409）和元数据集中（Metadata Centralization，280）。

图 10.3
规范表述保证了服务契约外部描述的一致性，因此影响了契约和上下文相关的模式。

案例分享

该案例中，为了测试的目的使用了早期开发的测试版服务目录处理服务。它包含一个由开发工具自动生成的服务，服务契约是由遗留的定制化库存管理系统的组件类的接口衍生而来的。

尽管该 Web 服务对很多评估需求价值很大，可是一旦架构师们仔细检查其实际的契约代码，他们发现了一些应被关注的内容：

• 服务操作继承了遗留系统的晦涩的组件方法名。
• 一些 Web 服务操作的输入和输入消息模式是由遗留的方法参数而来的，这些参数对于基于消息的服务交互来说粒度太细。
• 没有真正的库存记录的概念，因为在遗留组件的 API 不支持它。

这些问题和其他一些问题导致了他们快速转移到一个正式的设计流程，该流程要求服务契约的定义必须先于服务底层逻辑的开发。它位于正式分析和流程建模之后，在建模的过程中架构师和业务分析师一起定义概念性的候选服务，并将这些候选服务作为物理服务设计的基础。

由于获得了对服务契约定义的控制，现在，架构师和开发者能够避免不规则的或有问题的服务契约的出现。

元数据集中

如何集中发布和治理服务的元数据

问题

项目组，特别在大型企业内，总是冒着重建现有功能或重建正在开发的功能的风险，这导致了工作的浪费，服务逻辑的冗余以及目录不规范的问题。

解决方案

服务元数据可以集中发布在服务注册库中，从而提供统一的服务注册和发现的方法。

应用

私有的服务注册应作为（由正式的注册和发现流程所支持的）目录架构的核心部分。

影响

服务注册产品应该足够成熟且可靠，它所需要的使用和维护工作应该融入所有的服务交付和治理流程及方法论中。

原则

服务发现

架构

企业、目录

表 10.2
元数据集中模式概览

问题

在增长目录和支持由服务标准化（Service Normalization，131 ）和逻辑集中（Logic Centralization，136）所实现的基本服务质量时，项目组不断面临着这样的风险，他们在不经意间（或有意地）交付的新服务和现存或开发中的 服务具有相同的功能（图 10.4）。

图 10.4
如果没有对所有现有或开发中的服务全盘了解，项目组总面临着交付的服务与现有或开发中服务具有相同的逻辑的风险。

这将会导致不愿看到的结果，最显著的是：

• 冗余服务逻辑的引入，这和逻辑集中（Logic Centralization，136）相违背
• 重复服务上下文的引入，这和服务标准化（Service ­Normalization，131）相违背
• 整体上失效的目录和技术架构，因为附加的冗余和反标准化使其膨胀或扭曲，最终导致更多的治理工作。

所有以上特征都可能导致一个 SOA 项目的失败，因为它们损害了 SOA 项目的潜在战略意义。

解决方案

建立服务注册库，让其成为周边基础设施的中心，使得服务所有者和设计者可以通过它：

• 注册现有服务和能力
• 注册开发中的服务和能力

正如服务发现相关的治理模式所强调的，（服务的）注册流程要求发现信息记录的方式具有高度地描述性且便于沟通，从而项目组可用它们：

• 定位并翻译现有服务，了解它们的功能语义以及边界
• 定位和翻译服务功能，了解它们的调用和交互需求

通过提供一个更新及时且维护良好的服务上下文和服务功能的注册库，可以收获有效的服务发现（如 10.5）。

图 10.5
基本服务发现过程，人们首先通过代表服务目录的服务注册库定位到潜在服务，然后翻译该服务，从而确定其是否适合。

注：很明显元数据集中通常是和服务发现设计原则以及服务发现活动关联的设计模式，那为什么不简单地称之为服务发现呢？

服务发现本身是一个过程，一旦企业成功地在其架构中应用了元数据集中，在其服务中融入了服务发现设计原则之后，它就被执行。因此，服务发现的过程是关联 SOA 治理的一组模式的活动，我们即将发表的《SOA 治理》（SOA Governance）中会单独阐述它，该书是该丛书系列的一部分。

应用

该模式的应用通常要求以下几个步骤：

1. 周期对所有建模和设计的服务契约应用服务发现原则
2. 使用服务概要和支撑性流程标准化服务和功能的元数据文档。例如，服务概要的某一通用部分是标准词汇，它作为附加在服务注册记录之上的关键字。
3. 实现一个可靠的服务注册产品，并将其定位成支撑基设的标准部分。

最后，要建立起正式的用于服务和功能的注册以及发现的流程。

注：该模式可以应用于单个服务目录域，也可以应用于多目录域，这取决于服务注册产品通过服务概要信息关联目录域的能力。要了解服务概要模板 以及服务发现和翻译过程的实现，请分别参阅《SOA 服务设计原则》（SOA Principles of Service Design）的第 16 章和第 12 章。

影响

服务注册和发现过程是服务目录有效治理的关键因素。如果该过程不受项目组的重视和一致遵守，或者注册库更新不及时，那么元数据集中的潜在价值就会大打折扣。

然而，从设计的角度看，基于服务发现原则，该模式会引入元数据标准的需求。它还会进一步要求元数据文档和注册成为标准服务交付的生命周期的一个环节。

进一步，可能还需要一个新的组织角色来督促元素据集中的实现，可能由一人或一小组成员作为服务注册的管理员，并行使收集必要的元数据和维护注册表的职责。

关系

元数据集中的核心是建立一个服务注册库，它是保证逻辑集中（Logic Centralization，136）和契约集中（Contract Centralization，409）长期有效应用的关键。如果能够有效定位正确的服务及其契约，那么无意中引入冗余服务逻辑的风险就能大大降低，从而 进一步支持服务标准化（131）。

不可知服务主要指的是这些服务：为了服务发现的目的，其元数据需要被集中起来的服务。这也是该模式与由实体抽象（Entity Abstraction，175）及效用抽象（Utility Abstraction，168）定义出的服务密切相关的原因。

图 10.6
元数据集中方便了服务发现，因此它关系到其他模式，为了实现模式应用一致性，在设计时就应考虑它。

案例分享

正如第六章所描述的逻辑集中（Logic Centralization，136），Alleywood 和 Region 域中的服务之间原有的功能重叠可能已经悄无声息地消失了，这将导致服务目录的 质量和完整性都受到消极影响。基于此，应该早早决定使用服务注册库来支持服务标准化（Service Normalization，131）并确保逻辑集中（Logic Centralization，136）的应用的一致性。

然而，归于建立独立的域服务目录的决定，架构师会尽力争取为每个服务目录建立独立的服务注册库的方案。尽管这将继续允许每一个组织独立管理其服务集合，但还是要建立两个独立的注册库。

而 Alleywood 和 Tri-Fold 的服务之间有互操作的需要，那些要创建跨目录的复合服务的开发人员必须在两个注册库发出独立的查询时才能找到他们所需的服务能力。

这种治理架构上的尴尬最终促使 McPherson 建立了一个全局的企业服务注册库（图 10.7），该注册库由 McPherson 集团的某部门管理，并允许 Alleywood 和 Tri-fold 项目组查找相互的目录。

图 10.7
跨 Alleywood 和 Tri-Fold 目录的全局注册库。

规范版本控制

如何对同一服务目录里的服务进行版本控制使其造成的影响最小？

问题

对同一服务目录里的服务契约使用不同的版本控制会导致无数的互操作性以及治理问题。

解决方案

规范化同一服务目录内的服务契约的版本控制规则和版本信息的描述。

应用

通过治理和设计标准来确保服务契约在同一目录内有统一的版本控制。

影响

创建和加强所需的版本控制标准引入了新的治理需求。

原则

标准化服务契约

架构

服务，目录

表 10.3
规范版本控制模式概要

问题

当同一服务目录内的服务契约受到不同的版本控制方法以及规则影响时，实现后的契约级的不一致性就产生了，势必会破坏互操作性以及有效的服务治理（图 10.8）。这将给设计时客户端开发，运行时服务访问，服务重用以及全局服务目录的发展带来不利影响。

图 10.8
受不同版本控制方法管理的服务给服务组装、互操作以及对服务的理解带来了挑战。

解决方案

同一服务目录里的服务契约应依据同一的规则进行版本控制，并且也作为整体企业版本控制策略的一部分（图 10.9）。这样才能保证对每一个服务有统一的治理路径，进而保持契约标准化以及目录内的兼容性以及互操作性。

图 10.9
当服务受统一的版本控制策略管理时，它们可以保持原有的标准和互操作性，并且能够更容易被客户端设计人员理解。

应用

该模式通常需要选择统一的版本控制策略，它包含一组可以转变为治理标准的规则和习惯。

规范版本控制的方法可以根据企业的复杂性而不同，某些企业已经拥有了现有的版本控制策略或配置管理方法论，某些也可能已经建立了统一的治理策略。

以下三个通用策略为我们提供了一组基础的规则：

• 严格 ——所有兼容或不兼容的更改都将产生服务契约的新版本。该方法不支持向后兼容或向前兼容，在当服务契约被多个伙伴机构共享且服务契约的修改可能会带来法律上的影响的环境里，这是最常见的做法。
• 灵活 ——所有不兼容的更改导致服务契约的新版本，契约的设计支持向后兼容，但不支持前兼容。
• 松散 ——所有不兼容的更改导致服务契约的新版本，且服务契约的设计既支持向后兼容，也支持向前兼容。

注：这里的“向后兼容”和“向前兼容”在第 16 章的兼容性变更（Compatible Change，465）里有具体介绍。欲了解具体的各个版本控制策略的例子，请参考《Web 服务契约设计及 SOA 版本控制》（Web Service Contract Design and Versioning for SOA）的第 20 至 23 章。

影响

若项目组坚持使用其自有的版本控制方法，或过分依赖像并发契约（Concurrent Contracts，421）这样的模式（该模式允许他们在现有服务上轻松增加新契约），那么这将带来持续的风险。

任何版本控制策略的成功应用都需要对其规则和习惯的强有力的支持，直到选择版本控制的方法和任何其他设计标准一样，成为目录范围内的标准。这势必会引入一个新的组织角色，其工作是加强策略中所制定的流程以及合规特征的执行。

关系

规范版本控制本质上形式化了兼容性变更（Compatible Change，465），版本标识（Version Identification，472）和终止通告（Termination Notification，478）的应用，该模式建立的是高层策略，规定了这些更为具体的版本模式如何应用，以及应用到何种程度。

元数据集中（Metadata Centralization，280）的应用产生了服务注册库并通过它使得针对不同版本的服务契约的查找更为有效，而规范表述（Canonical Expression，275）让服务契约更容易阅读。因此，二者都有助于规范版本控制目标的实现。

图 10.10
规范版本控制模式主要关系到其他版本控制相关的模式。

注：在继续案例分享之前，请先阅读状态存储库（State Repository，242）中案例分享内容中的 Policy Check 服务，然后阅读跨域工具层（Cross-Domain Utility Layer，267）的支持多目录的例子。

案例分享

FRC 宣称基于治理条例对某些策略做了修改。该动作变更了已经通过公共的 Web 服务开放出去的策略数据。

Alleywood 的 Policy Check 服务最初的定位是为其他 Alleywood 的服务屏蔽这类更改，它为其他服务提供了访问 FRC 策略的统一接口。尽管可以扩增其服务逻辑使其适应 FRC 的服务修改，架构师们发现他们不得不创建新的 Policy Check 的服务契约，原因是 FRC 在原有数据结构上增加了新内容。

这是他们第一次必须面对一个主要的版本控制问题，Alleywood 团队决定在他们采取动作前使用一些正式的方法。经过对通用版本控制实践的一番调研和进一步地考虑，他们得出了一套版本控制策略，其具体包含以下规则和条例：

版本标识（Version Identification，472）将应用于：

• 版本信息如下表达，大版本号在小数点左边，小版本号在小数点后边，如（“1.0”）。
• 契约的小版本号和大版本号在 WSDL 文档中描述，并在版本号之前加上“Version”的字样，（如Version 1.0）
• 大版本号附加在 WSDL 定义文件的目标命名空间的后面，并使用“v”作为前缀，比如： http://alleywoodlumber/contract/po/v1

兼容性变更（Version Identification，465）将应用于：

• WSDL 定义文件的兼容性变更会增加小版本号，但不更改 WSDL 中的目标命名空间。
• XML 模式定义的兼容性变更增加小版本号，不修改 XML 模式和 WSDL 中的目标命名空间。
• WSDL 文件中的非兼容性变更增加大版本号，且强制 WSDL 使用新的目标命名空间。
• XML 模式定义中的非兼容性修改增加大版本号，并强制 XML 模式和 WSDL 使用新的目标命名空间。

之前描述的场景会引发一组非兼容性变更，所以需要更改 Policy Check 服务契约的大版本号，使其从 1.0 转变成 2.0。

该例子展示了由此变更导致的 Policy Check 的 XML 模式和 WSDL 定义的文件头信息：

复制代码

 
<xsd:schema xmlns:xsd=
  "http://www.w3.org/2001/XMLSchema"
  targetNamespace="http://alleywoodlumber/schema/pc/v2"
  xmlns="http://alleywoodlumber/schema/pc/v2"
  version="2.0">
  <xsd:annotation>
    <xsd:documentation>
      Version 2.0
    </xsd:documentation>
  </xsd:annotation>
  ...
</xsd:schema>
{1}
<definitions name="Policy Check" targetNamespace=
  "http://alleywoodlumber/contract/pc/v2"
  xmlns="http://schemas.xmlsoap.org/wsdl/"
  xmlns:tns="http://alleywoodlumber/contract/pc/v2"
  xmlns:pc="http://alleywoodlumber/schema/pc/v2"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <documentation>
    Version 2.0
  </documentation>
  ...
</definitions>
{1}

例 10.1
展示了应用版本策略之后的 Policy Check 服务的契约文档片段。

Alleywood 架构师发现了定义版本方法仅仅是第一步，为了规范版本控制的完全实现，这些新创建的规则和标准必须要应用到将来其他的需要版本控制的服务契约。这意味着需要创建一个由治理组成员管理的（版本控制）流程。

查看英文原文： 3 Patterns from SOA Design Patterns by Thomas Erl 。

感谢胡键对本文的审校。

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