SOA中的服务版本管理.doc

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