WSRR Studio V8.0 应用系列,第 2 部分 使用 Studio 实现 WSRR 生命周期管理1

引言

服务是 SOA 架构成功实施的关键因素之一,服务的生命周期包括服务需求的提出,分析,设计,实现,部署以及相关的版本变更,服务下线等一系列过程,贯穿于 SOA 的整个生命周期当中。
为了保证服务能够满足 SOA 的基本设计原则,
例如可重用性,符合相关标准及规范等,需要对服务的生命周期进行管理,这一过程可能会包含多个角色,包括业务分析人员,开发人员,IT 实施人员,SOA 治理人员等,其中 SOA 治理人员负责生命周期各个阶段的审查工作,只有经过他们的审批和确认,服务才能进入下一个阶段,例如从设计阶段进入开发阶段。WSRR 能提供管理服务生命周期的能力,下面将具体介绍。


 

WSRR 服务生命周期管理介绍

WSRR 的服务生命周期管理主要采用如下三个技术手段:

1.    访问控制

2.    生命周期模型定义

3.    监管策略

其中访问控制用于定义用户的权限,在本系列的第一篇中已经有详细的介绍,它可以用来定义哪个用户具有修改生命周期状态的权限。

生命周期模型定义了服务在生命周期中的各个状态及相互之间的迁移关系。如
1
所示,服务可以通过发现已有的服务然后进入 managed 的状态,也可以通过 modelassembledeploy 的开发流程进入 managed 的状态。
状态之间有带箭头的连线才能进行状态转换,这样所有服务可以遵循预先定义好的服务生命周期来进行管理。


1. Default 生命周期定义

监管策略定义的服务状态转换的规则,即符合什么样的条件才能进行状态转换。这些规则的定义是基于对服务元数据信息的检测,例如服务要进入 managed 状态即上线状态,必须具有至少一个 endpoint 的值,这样的定义可以通过 policy 文件来描述,然后在服务状态转换的时候做自动检测。
这些元数据信息可以被 ESB 产品消费,例如只能查询处在上线状态的服务的 endpoint 值来完成服务调用。

WSRR 预定义服务生命周期介绍

WSRR 安装完成以后,可以载入 Governance Enabled Profile, 根据 SOMA 方法论和一些最佳实践,该 profile 里面包含了 11 种不同的生命周期的定义以及相应的角色和监管策略的定义,可以实行完整的服务生命周期管理。客户也可以根据自己的实际需求对这个生命周期进行裁剪和简化。详细过程参考红皮书 :Service Lifecycle Governance with IBM WebSphere Service Registry and Repository

下面以业务服务的创建为例,介绍如何使用服务生命周期管理。业务服务在 WSRR 中是业务分析人员创建的用于表示服务的需求和功能描述的对象,与具体的实现无关,在整个生命周期的实现过程中,
该对象会最终关联到服务的具体实现,实现业务和 IT 的衔接。不同的用户对生命周期管理的需求不一样,所需要的业务对象也有可能不一样,这时候用户可以通过业务模型自定义所需的对象。详细介绍参考文章:
WSRR Studio 7.0
应用系列,第 2 部分 : 使用 WSRR Studio 创建商业模型

下面通过 WSRR Web UI 来创建该对象并进行生命周期管理。首先业务分析人员创建业务服务如
2
所示。
输入业务服务名称 Sample Business Service


2. 创建业务服务

创建完业务服务,进入 Governance tab
选择初始化 capability lifecycle,点击 Govern 按钮,将新创建的业务服务放入 capability lifecycle 进行治理。如
3
所示。


3. 初始化 Capability Lifecycle

完成初始化以后,可以看到该业务服务当前可以做的状态转换,选择 Propose Charter 转换,点击 Transition 按钮。该步骤表示向公司提出新的业务服务开发需求,然后由相关部门负责审批该业务服务,看是否有现成的服务可以重用,还是需要分配资源重新开发。
该步骤会出现如下错误提示信息,如
4
所示。


4. 业务服务状态转换错误

这是治理策略对业务服务对象进行校验的结果,根据错误提示信息,
要完成 Propose Charter 操作,需要绑定相应的 Charter 文档,也就是具体的服务需求描述文档。
返回业务服务对象,点击 Edit Relationship, 在名为 Charter 的关系上添加对象,该对象的类型是二进制文档,例如 Word 文档等。
如果 WSRR 没有注册的二进制文档,可以先注册一个,然后将该文档添加到业务服务的关系上。如
5
所示。


5. 编辑业务服务关系

编辑完关系并保存以后,重复 Propose Charter 操作,这时候该操作可以顺利完成,该业务服务的状态也从 Capability identified 变为 Charter review
相关人员可以对 Charter 文档和业务服务对象进行审批,然后根据审批结果选择 Approve Charter 或者 Revise Charter 操作。
读者如果有兴趣,可以参考红皮书,走完整个 WSRR 中预定义的服务生命周期。

WSRR 服务生命周期配置文件介绍

上述过程所涉及的配置文件包括三类:

    SACL 生命周期描述文件,描述状态及状态之间的转换关系

    OWL 生命周期对应的分类系统文件

    Policy 治理策略描述文件

下面通过一些文件的片段,来介绍一下这些文件的基本结构。

SACL 文件,
每一个 Profile 里面只能包含一个 SACL 文件。
该文件可以在 profile Configuration Profile Files/SACL 目录下找到。

<sacl:state displayName=”Business Capability Identified” name=”CapabilityIdentified”>

<sacl:description> …………… </sacl:description>

</sacl:state>

<sacl:transition name=”fromCapabilityIdentified_toCharterReview”>

<sacl:sourceState>CapabilityIdentified</sacl:sourceState>

<sacl:operation name=”ProposeCharter” portType=”_:CapabilityLifecycle”/>

<sacl:targetState>CharterReview</sacl:targetState>

</sacl:transition>

以下文章点击率最高

Loading…

     

如果这文章对你有帮助,请扫左上角微信支付-支付宝,给于打赏,以助博客运营

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注