1、SOA 中的服务版本管理级别： 初级Greg Flurry, 高级技术人员, IBM Software Group2009 年 1 月 14 日使用面向服务的体系结构作为支持灵活和弹性企业的方法，这种做法正在变得普及。初始 SOA 部署的成功现在让架构师和开发人员能够将重点集中于所有业务和 IT 系统所共有的方面。任何系统中都存在的这样一个不变的方面就是更改。本文讨论 SOA 中的更改挑战，并描述帮助处理此挑战的模型。来自 IBM WebSphere Developer Technical Journal。处理更改面向服务的体系结构（Service Oriented Architecture，
2、SOA）正在成功地解决许多企业对业务灵活性和弹性的需要。但是与任何系统一样，即使 SOA 也不可避免地必须处理由于业务或技术原因而导致的更改。事实上，由于 SOA 促进业务敏捷性，而敏捷性意味着更改，因此可以认为 SOA 甚至鼓励更改。但是，即使在 SOA 中，更改也是非常麻烦的。由于 SOA 促进弹性，而弹性意味着能够适应更改，因此可以认为 SOA 必须以适当的方式处理更改。系统中存在多种粒度级别的更改。由于 SOA 重点关注服务，因此研究 SOA 中的更改的重点自然是服务。当某个事物发生更改时，我们通常将结果视为该事物更改后的新版本。因此，本文将讨论 SOA 上下文中的服务版本管理。在 S
3、OA 中，服务使用者与服务提供者进行交互以完成某个业务任务。SOA 中的更改会影响服务。多个服务使用者可以使用一个服务提供者（在理想的 SOA 中是这样）。因此，可以合理地预计使用者和提供者在服务版本管理方面的观点和预期是不同的。例如，提供者通常有最小化更改的动机，但是当然要合理地快速响应来自使用者的更改请求和来自内部的更改需要。另一方面，使用者通常不希望更改，或者希望与更改隔离，或者希望非常缓慢的更改。对 SOA 中的更改的不同观点增加了服务版本管理在以下方面的挑战： 推动提供者对更改的交付。 最小化由于更改而对使用者造成的中断。 下面让我们研究一个模型，该模型引入了可用于分析此挑战的概念，
4、以及可采用来处理该挑战的方法。服务规范 由于同时与服务提供者和服务使用者具有业务和技术相关性，服务版本管理模型的关键是服务规范。如图 1 所示，服务规范是由服务规定的一组简洁的外部功能和非功能特征。服务规范仅定义外部特征，以维持服务使用者与服务提供者之间的关注事项分离。图 1. 服务规范在业务级别，服务使用者和服务提供者使用服务规范来了解进行服务交互能够实现什么功能行为。在技术级别，服务使用者和服务提供者使用服务规范来了解服务使用者实例如何与服务提供者实例交互。因此服务规范描述了服务交互的“什么”和“ 如何”方面。图 1 表明服务规范是该模型中接受版本管理的实体。因此，服务规范具有标识符，在该
5、图中缩写为“Nx.y”。服务规范的标识符在域中是唯一的。该标识符是形如 名称, 版本 的元组。名称反映服务的相关粗粒度功能及非功能外部特征，并区分不同的服务，但是不区分服务的不同版本，例如：“CreditScore”, ? 与 “Customer”, ?。版本区分服务的不同版本，例如，“CreditScore, 1.2 与 “CreditScore”, 1.3。服务规范版本在逻辑上具有 号码的形式，并基于从 OSGI 改编而来的向后兼容性。初始服务规范的版本从 开始。向后兼容的更改导致 号递增。向后不兼容的更改导致 号递增，并且 号重置为 0。对服务规范中的更改进行版本管理服务规范中的更改可以
6、是渐进的或激进的。渐进的更改表现出对以前服务规范的明显继承。激进的更改则不是这样。渐进的更改产生本质上相同（虽然经过了发展）的业务价值，因而是服务的新版本。这导致将服务视为服务规范随服务生存期（从初创到退役）推移而发展的连续体，如图 2 所示。图 2. 渐进的更改激进的更改产生新服务，如图 3 所示。提供者必须基于更改对使用者以及随后对提供者产生的影响，从而确定更改是渐进的还是激进的。“旧的”服务生存期可以继续或终结，具体取决于企业的需要。产生新版本的渐进更改是本讨论的重点。图 3. 激进的更改服务规范详细信息 图 4 显示了关于服务规范的附加详细信息图 4. 服务规范详细信息服务规范由四个主
7、要部分组成： 行为规范 (BS) 主要从操作所需要或产生的业务数据方面描述服务（特别是其操作）的业务语义。 接口规范 (IfS) 从操作所使用的抽象数据类型方面严格描述服务的操作的业务语法。 交互规范 (IaS) 描述为了让使用者能够与服务交互而必须满足的非业务或基础结构策略、协议、机制和约束。 操作规范 (OS) 描述非业务功能特征，服务应该体现这些特征，但这些特征不是使用者与服务交互所必需的，例如性能或能力。 可以认为 IaS 和 OS 定义了操作的服务质量。服务规范将作为整体来看待，各个部分本身不是接受版本管理的实体。此外，服务规范中未包括的任何特征都不能视为更改源。服务描述服务规范定义
8、了服务交互的“什么”和“ 如何”方面，但是单凭服务规范本身还不足以真正支持交互。特别是，不存在任何指示特定服务提供者实例位置的信息。称为服务描述（图 5）的实体包含了与服务的某个版本的实例进行交互所需要的所有信息。服务描述（通过包含或引用）由服务规范构成，以定义相关的外部功能和非功能特征（“什么”和“ 如何”）以及服务实例的地址（“何处”）。图 5. 服务描述服务描述本身具有与服务规范的形式相同的唯一标识符。事实上，服务描述标识符反映了服务规范标识符，但是其版本在服务规范版本的基础上添加了 ，以考虑到 “维护更改”。当做出内部更改时，如果此更改会影响与服务规范的特定版本相关的隐含行为，则 将递
9、增。示例包括不同的配置文件或规则，甚至是服务实例的实现或组装中的错误修复。服务描述可以包括各种形式的标记，以将一个服务实例与规定相同服务规范的其他实例区分开来。通常将服务描述作为元数据在某个服务注册中心进行发布。一般来讲，同时还会作为元数据发布关联的服务规范。服务版本 前一部分表明多个服务实例可以实现某个服务规范的相同版本。这促使了该模型中另一个称为服务版本的实体的产生，如图 6 所示。图 6. 服务版本服务版本聚合了所有实现某个服务的相同服务规范版本的服务实例。服务版本（通过包含或引用）由某个服务规范的一个版本和一个或多个服务描述组成。服务版本本身具有与服务规范标识符相同的唯一标识符。但是，
10、服务版本本身不是该模型中接受版本管理的实体；它只是表示特定服务版本的所有实例。与其他实体一样，通常将服务版本作为元数据在服务注册中心进行发布。服务该模型中的最后一个实体是服务，如图 7 所示。前一部分表明可以将服务视为服务规范和那些服务规范的实现的连续体。图 7. 服务服务聚合了从服务初创到最新版本的所有服务版本，从而产生服务版本的连续体。服务还间接聚合了实现某个服务规范的所有版本的所有服务实例。服务（通过包含或引用）由一个或多个服务版本组成，每个版本标识对应的服务规范和服务描述。服务具有标识符，此标识符就是服务规范中的服务名称。服务本身不是该模型中接受版本管理的实体。与其他实体一样，通常将服务作为元数据在服务注册中心进行发布。图 8 显示了该模型的摘要。图 8. 模型实体摘要服务包括许多服务版本。每个服务版本具有服务规范中定义的外部功能和非功能特征。任何单个服务规范都可以具有许多体现该服务规范的服务实例。每个服务实例由服务描述定义，其中每个服务描述由对应的服务版本标识。总结本文介绍的模型使您可以推断 SOA 中的更改如何通过服务体现出来，如何表示更改，如何对更改分类，以及如何表达更改以便能够了解其影响。可以在能够支持治理流程实现的服务注册中心表示此模型以控制更改，将有关更改的情况通知相关各方，甚至允许让 ESB 中运行的中介帮助最小化更改的影响。
