使用 WebSphere Service Registry and Repository 实现和执行服务生命周期

本文提供了详细的步骤说明，介绍在 WebSphere® Service Registry and Repository 中设计、开发和加载服务生命周期的整个过程，包括如何使用 WebSphere Integration Developer 创建关联的 SACL 文件。
引言

随着面向服务的体系结构（Service-Oriented Architecture，SOA）的出现，服务正越来越被视为一项主要企业资产。这种业务和 IT 的以服务为中心的观点的转换带来了对跨越组织生态系统（由多个参与者、流程和系统组成）管理和促进服务相关信息和元数据的全面解决方案的需求。

作为 SOA 治理的一部分，您需要定义、管理和执行服务生命周期，以形成企业的服务和相关概念的全面视图。在本文中，我们将了解 WebSphere Service Registry and Repository（以下称为 Service Registry）为了支持服务生命周期而提供的功能。具体来说，本文将提供详细的步骤说明，以了解如何定义自定义服务生命周期和如何实现独立的生命周期（而不是 Service Registry 中提供的缺省生命周期）来对不同的实体类型或给定实体的不同方面进行治理。

安装 Service Registry 时，会提供两个生命周期，缺省生命周期和更为复杂的示例 SampleLifecycleDefinition。缺省生命周期非常简单，如图 1 中所示：

图 1. 缺省生命周期



SampleLifecycleDefinition 包含十个状态，其中一个是包含五个细分状态的组合状态，如图 2 中所示：

图 2. SampleLifecycleDefinition



本文的目的并不是对这些缺省生命周期进行解释，而是要说明如何从头构建新的生命周期。

回页首

设计服务生命周期

没有用于创建服务周期的万能解决方案。在我们开始之前，需了解需要哪些状态和转换、存在多少角色以及如何及何时用户将与 Service Registry 交互以经历生命周期的不同状态。生命周期定义还可能会因为其应用到的环境不同而有所变化。您需要清楚地定义在进入下一阶段前需要进行哪些活动。为了帮助您处理 SOA 治理生命周期，Service Registry 提供了一个框架来验证数据与元数据并通知其他组件。

在任何组织中，即使 SOA 不是主要关注的内容，也仍然很好地确定了相关的角色来负责定义业务分析、体系结构设计、设计、开发、部署、管理等等的相关责任和任务。当将 IT 治理扩展为 SOA 治理时，可能需要添加一些之前不存在的额外角色，但这里的要点是，必须清楚地知道和定义所有的角色及其相关的职责。有关业务中的不同角色如何在 SOA 治理生命周期中与 WebSphere Service Registry 进行交互的详细说明，请参见 IBM WebSphere Service Registry and Repository 简介，第 1 部分: WebSphere Service Registry and Repository 在 SOA 生命周期中的一天。

下面让我们更为详细地分析一下 UML 术语中状态的定义。状态是实体行为模式中的一个阶段。状态使用实体属性的值进行表示。通过这个定义，可以发现需要定义一组属性，以表示您希望治理的实体。定义信息模型时就是在进行此工作，此时可以修改特性 (attribute) 或自定义属性 (property)、关系、分类，甚至还能够更改实体的内容（如果处理的是将驱动对不同状态的需求的文档）。

另外还需要定义状态间的转换。在 UML 上下文中，转换是从一个状态转换到另一个状态的过程，将由所建模的实体的内部或外部事件触发。转换通常是由于导致状态发生重要更改的调用造成的。不过，并非所有调用都会导致出现状态转换。这可能是因为存在与一个实体（例如，讨论服务概念时）或一组实体（考虑该实体所有的依赖关系时）相关的很多重大更改，从而使得我们需要另一个状态，即需要进行转换。

可能会因为其他原因而需要创建其他状态和转换；例如，当希望实现治理模型中定义的不会导致所治理的实体的数据或元数据更改的一些流程时。需要执行遵从性或有效性检查来确保恰当地遵循了服务设计指导方针时，就是如此。在这种情况下，管理员或质量经理将验证特定实体是否恰当地遵循了指导方针，然后将调用转换，以过渡到下一个状态。可以使用 Service Registry 管理控制台手动创建此转换，也可以使用一个 Service Registry 接口（如 Web 服务或脚本接口）来自动化创建。

确定了元数据集和/或物理文档后，就可以开始问自己以下这些问题，从而开始设计生命周期。这些问题基于作者的经验，而不是以 Service Registry 提供的任何具体建议为基础。

谁是具体元数据的所有者？例如，谁拥有和管理服务端点信息？谁拥有和管理决定要在服务信息模型中使用的服务质量信息？

元数据是否特定于环境？如果某个服务端点信息包括在服务信息模型 (Service Information Model) 中，则元数据将可能特定于每个环境。

元数据是否存在明显的分组或分类，或者是否彼此独立？

值发生变化时，是否存在任何验证或通知规则？

生命周期中元数据的值是否会发生变化？如果是，为什么？

这些问题应该能帮助您将元素的不同值或文档的内容链接到生命周期的不同状态。

回页首

创建自定义服务生命周期

本文转自：IBM developerWorks 中国
请点击此处查看全文