级别： 中级 Arnauld Desprets (arnauld_desprets@uk.ibm.com), IT 架构师, IBM
Laurent Rieu (Laurent.Rieu@fr.ibm.com), SOA 解决方案架构师, IBM
2007 年 10 月 22 日 本文提供了详细的步骤说明，介绍在 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) 中，则元数据将可能特定于每个环境。
-
元数据是否存在明显的分组或分类，或者是否彼此独立？
- 值发生变化时，是否存在任何验证或通知规则？
- 生命周期中元数据的值是否会发生变化？如果是，为什么？
这些问题应该能帮助您将元素的不同值或文档的内容链接到生命周期的不同状态。
创建自定义服务生命周期
对于本文，我们将假定您已经设计了生命周期。现在我们将了解如何使用 WebSphere Integration Developer（以下称为 Integration Developer）对其进行构建。我们将使用 Integration Developer 的原因是，其中包含能够用于创建所需的 SACL 文件的状态关系图编辑器。SACL 即状态自适应编排语言 (State Adaptive Choreography Language)，是用于将状态关系图表示为文件的标准。
还可以采用其他方式构建 SACL 文件。Ian Shore 所撰写的 Creating customized classification systems with WebSphere Service Registry and Repository V6.0.0.1: A step-by-step guide for administrators to create new classification systems and life cycles for WebSphere Service Registry and Repository 描述了一种替代方法，可以使用文本文件来表示状态关系图。还可以创建状态关系图的简化 UML 表示形式，然后使用 Rational™ Software Architect 中的转换框架创建 SACL 文件。
在下面的内容中，我们将了解如何创建与生命周期关联的状态关系图，然后使用 Integration Developer 将所得到的 SACL 及关联的 Web 本体语言（Web Ontology Language，OWL）文件加载到 Service Registry 中。在本例中，我们所使用的是 Service Registry V6.0.2 和 Integration Developer V6.0.2。
可以使用 Integration Developer 来生成能供 Service Registry 使用的 SACL 文档。对于我们的示例，将使用 WebSphere Integration Developer 生成所调用的状态关系图。我们将使用非常简单的生命周期，从而让您方便地了解 Integration Developer 中所需的步骤。请注意，我们对状态使用的是形容词，而对转换使用的是动词，这种描述是最佳的方式。图 3 显示了 SACL 的内容和接口：
图 3. 新生命周期状态关系图
创建 SACL 文件
要创建 SACL 文件，请执行以下步骤：
- 启动 Integration Developer。
- 选择 File => New => Module，以创建新模块。
- 输入
WSRRLifeCycle 作为模块名称。
- 在 Business Integration 窗口中展开 WSRRLifeCycle => Business Logic => State Machines，然后右键单击 New Business State Machine，以打开 New Business State Machine 向导。
- 在 New Business State Machine 对话框中，指定以下内容，如图 4 所示：
-
Module：指定模块的名称；我们的示例中使用的是
WSRRLifeCycle。
-
Namespace：取消选中 Default，以允许输入命名空间，然后指定希望为生命周期使用的命名空间和用于表示它的分类系统。在本例中，我们使用
http://www.mycompany.com/xmlns/lifecycle/CustomLifeCycle。
-
Folder：指定 SACL 文件的存放位置。在本例中，我们使用
lifecycle。
-
Name：指定要创建的生命周期的名称。在本例中，我们使用
CustomLifeCycleStateMachine。
图 4. New Business State Machine 对话框
- 单击 Finish，以打开业务状态机编辑器，如图 5 中所示：
图 5. 业务状态机编辑器
创建接口
接下来我们将创建与状态关系图关联的接口。接口将包括用于定义状态关系图中的转换的操作。
- 选择 File => New => Interface。
- 选择 WSRRLifeCycle 模块。
- 取消选中 Default（以便输入命名空间），然后输入命名空间。在本例中，我们将使用
http://www.mycompany.com/xmlns/lifecycle/interface/CustomLifeCycle。
- 为 Folder 指定
lifecycle。
- 为 Name 指定
CustomLifeCycleInterface。
- 单击 Finish，以打开新接口的接口编辑器，如图 6 中所示：
图 6. 接口编辑器
定义转换
接下来，我们需要向接口添加各种操作，以定义转换。
- 在接口编辑器中单击 Add One Way Operation 图标，如图 7 中所示：
图 7. 单击 Add One Way Operation 图标
- 将操作名称由
operation1 更改为 create。
- 将 Input 名称更改为
bsrURI。
- 将 Type 保留为
string。
图 8. 指定 create 操作
- 使用以下名称重复相同的操作，以创建其他三个单向操作：
develop、deploy、deprecate。可以为这些操作全部指定相同的输入（类型为 string 的 bsrURI），如图 9 中所示：
图 9. 所添加的操作
- 按 Ctrl + S，以保存更改，然后关闭接口编辑器。
- 接下来，您需要完成状态关系图。在业务状态机编辑器中，创建以下状态：Created、Specified、Provisioned、Operational、Deprecated。为此，请将 State1 重命名为 Created。
- 对于其他状态，请从选择面板中选择状态图标，并单击空白图面。按照上面所示对每个状态进行重命名。所得到的结果应该与图 10 中所示类似：
图 10. Created 状态
- 现在已经完成了指定状态的工作，接下来需要对转换进行定义。要创建转换，请单击一个状态并保持选中状态，然后单击希望与其建立转换的另一个状态。在每个状态间重复此操作（Created 和 Specified、Specified 和 Provisioned 等等）。所得到结果应该与图 11 中所示类似：
图 11. 所定义的转换
- 右键单击 Created 状态和 FinalState1 之间的转换，然后选中 Delete，从而将其删除。
- 在窗口右侧单击 Interfaces 旁边的 + 图标，从而将接口定义链接到转换，如图 12 中所示：
图 12. 将接口定义链接到转换
- 选择 CustomLifeCycleInterface 并单击 OK。
- 接下来，需要将操作与转换关联。在 Properties 视图中选中 operation1 转换，确保为 Interfaces 选择了 CustomLifeCycleInterface，然后选择 create 操作。应该看到与图 13 类似的结果：
图 13. 将 create 操作与 operation1 关联
- 对于其他所有转换重复此操作。即，在 Property 视图选择转换，单击相应的操作按钮，并选择相应的接口和操作。或者，可以将 Interface 面板拖放到转换本身。还可以从 CustomLifeCycleInterface 的 Interfaces 面板（屏幕右侧）拖放操作定义。所得到结果应该与图 14 中所示类似：
图 14. 已关联的操作和转换
添加相关性属性
- 最后，需要添加相关性属性。相关性集定义用于对状态机的实例与运行时环境中的其他实例进行区分的属性。对于状态机响应的每个操作或事件，都使用属性别名来确定与每个已定义的相关性属性对应的输入的位置。在窗口右侧单击 Correlation properties 旁边的 + 图标，为 Name 输入
bsrURI，为 Type 选择 string，并单击 OK。
- 选择 bsrURI 相关性属性，并在每个操作的属性视图中单击和选择 bsrURI，如图 15 中所示：
图 15. 添加相关性属性
- 保存状态关系图。
- 检查 Problem 窗口，以确定是否存在任何错误。应该只收到一条警告，如图 16 中所示：
图 16. Problem 窗口
导出 SACL
现在已经准备好将 SACL 导出到文件系统。
- 在 Business Integration 视图中选择 WSRRLifecycle => Business Logic => State Machines => CustomLifeCycleStateMachine，然后单击右键并选择 Export，以打开 Export 窗口。
- 选择 File system 并单击 Next。
- 指定用于导出文件的目录，例如 C:\article\，单击 Finish，如图 17 中所示。（我们假定此目录已经存在了。如果尚不存在，会提示创建此目录。）
图 17. 导出文件
- 要加载到 Service Registry and Repository 中的 SACL 文件需要一个对应的 OWL 文件。要创建此文件，请使用 WebSphere Service Registry and Repository 安装中包含的 XSLT 文件。
从命令提示符中输入以下命令，以生成与 SACL 关联的 OWL 文件：
<was_home>\java\bin\java.exe -cp <was_home>\java\jre\lib\xml.jar
org.apache.xalan.xslt.Process -in C:\article\CustomLifeCycleStateMachine.sacl
-v -xsl <wsrr_home>\admin\scripts\GenerateLifecycleOntology.xsl
-out C:\article\CustomLifecycleDefinition.owl
|
- 现在需要删除 Service Registry 中已经加载的缺省生命周期。选择 Classification Systems => Classification systems，然后选择 DefaultLifecycle 并单击 Delete。
- 从 Service Registry 删除 SACL 文件。从命令提示符输入以下命令：
<wsrr_home>\CLI\WSRRCLI.bat deleteConfig.py -a myserver
-c \wsrr\CLI\config\wsrrcli.conf -n LifecycleDefinition -t SACL
|
提示：以下命令将提供一个列表，其中包含 Service Registry 中加载的所有配置文件，文件类型为 SACL：
<was_home>\profiles\wsrr2\bin\wsadmin -wsadmin_classpath
<wsrr_home>\ServiceRegistryClient.jar -username wasadmin
-password wasadmin -f <wsrr_home>\admin\scripts\
reportAllConfigurations.jacl /temp wsrr_report.txt
|
- 从命令提示符输入以下命令，从而将新 SACL 文件导入 Service Registry（假定 WebSphere Application Server 配置文件的名称为 wsrr2）：
<was_home>\profiles\wsrr2\bin\wsadmin -wsadmin_classpath
<wsrr_home>\ServiceRegistryClient.jar -username wasadmin
-password wasadmin -f <wsrr_home>\admin\scripts\loadConfiguration.jacl
/article CustomLifeCycleStateMachine.sacl LifecycleDefinition SACL true
|
注意：名称 LifecycleDefinition 可以随意选取。如果不能在此处指定任何内容，将不会失败，但不会正常工作。
加载 OWL 文件
现在使用 Web 接口加载关联的 OWL 文件。
- 选择 Classification Systems => Load，然后单击 Browse。
- 将路径指定为
C:\article\CustomLifecycleDefinition.owl，然后单击 OK，如图 18 中所示：
图 18. 加载 OWL 文件
- 重新启动 Service Registry。
使用生命周期
现在可以开始使用新生命周期了。让我们以一个简单的 WSDL 文档为例。除了这个示例外，还可以使用任意实体，让我们假定已经将“著名”的 TemperatureConverter 服务 WSDL 文件加载到了 Service Registry 中。
- 选择 TemperatureConverter.wsdl。
- 单击 Governance 选项卡，然后单击 Make Governable，如图 19 中所示：
图 19. 让实体处于可治理状态
- 选择 InitialState1 作为 Governance State。
- 要进入下一个状态，只有一个转换，即 create 转换。此示例非常简单，由于使用的是 WSDL 文件，因此可以假定创建服务的工作已经完成了。例如，我们可以假定已经创建了服务规范文档（未存储在 Service Registry 中）且已与此 WSDL 关联。检查了文档的准确性并确保 WSDL 也正确后，服务所有者将决定进入 Created 状态。
图 20. TemperatureConverter Created 状态
TemperatureConverter 服务进入 Created 状态。随着时间的推移，我们将过渡到表示此服务的开发与部署的不同状态。
清理与还原
如果要删除在进行本文所述操作的过程中对 Service Registry 所做的更改，请完成本部分的步骤。
- 从用户界面删除 LifecycleStateMachine 分类。从导航窗格中展开 Classification Systems，然后选择 Classification Systems。选择 CustomLifeCycleStateMachine 并单击 Delete..
- 从命令提示符输入以下命令来删除 SACL 配置文件：
<wsrr_home>\CLI\WSRRCLI.bat deleteConfig.py -a myserver -c
\wsrr\CLI\config\wsrrcli.conf -n LifecycleDefinition -t SACL
|
- 从命令提示符输入以下命令，以将缺省生命周期加载到 <wsrr_home>\install\config\DefaultLifecycle.sacl 中：
<was_home>\profiles\wsrr2\bin\wsadmin -wsadmin_classpath
<wsrr_home>\ServiceRegistryClient.jar -username wasadmin
-password wasadmin -f lt;wsrr_home>\admin\scripts\loadConfiguration.jacl
<wsrr_home>/install/config/DefaultLifecycle.sacl LifecycleDefinition
SACL true
|
- 将关联的 OWL 文件加载到 <wsrr_home>\install\config\DefaultLifecycle.owl 下：
- 重新启动 Service Registry。
结束语
在本文中，我们提供了设计自定义生命周期的指导方针，其中强调了花费足够的时间来获得最准确的 SOA 治理生命周期的需求，并突出了良好治理模型设计的重要性。然后我们演示了如何在 Integration Developer 中构建自定义生命周期并将其导出到 Service Registry 中。
参考资料
作者简介  | 
| |
Arnauld Desprets 是英国 IBM Software Services for WebSphere 的 IT 架构师。Arnauld 为全欧洲的许多公司提供咨询服务已超过 10 年。他具有 8 年以上的 WebSphere Application Server 使用经验，并且现在专长于 SOA 和 Web 服务，尤其是 WS-Security。他最近主要研究管理和注册中心的作用，包括 WebSphere Services 注册中心和 SOA 中的存储库。 |
| 
| |
Laurent Rieu 是 IBM Software Group 的 Worldwide SOA Advanced Technology 团队（之前称为 Enterprise Integration Solutions）的一位 IT 架构师。作为此全球团队的一员，Laurent 担任欧洲/中东/亚洲（Europe/ Middle East/Asia，EMEA）的首席解决方案架构师，帮助通过合作、现场开发、资产收集和领先思想来推广和增强 IBM 有关 SOA 的软件战略。Laurent 有 8 年以上的 IT 行业从业经验，曾在欧洲从事过 7 年针对各个行业的 IBM 客户服务工作。他于 1998 年获得了 Ecole Supérieure d’Electricité (Supélec) 的硕士学位。您可以通过 Laurent.Rieu@fr.ibm.com 与 Laurent 联系。 |
对本文的评价
| 
