一个服务从开发到最后的发布，需要进行大量的在不同环境下的部署工作。开发人员实现了服务的功能后，将服务交给测试人员，测试人员在测试环境中部署服务，并对其进行测试。由于服务还处于开发阶段，所以经常要重新部署服务。直到服务开发测试完成，才能将其发布到生产环境中。当服务发生更新或者升级时，需循环重复上述的活动。这种重复的人工劳动不仅增加了开发人员和测试人员的负担，而且影响了开发的效率，增加了管理难度，并且由于环境的多样性，也增加了维护的成本。
IBM WebSphere® Service Registry and Repository（以下称为 WSRR）是服务交互端点描述的主元数据存储库。作为服务元数据的集成点，WSRR 提供了用于管理服务元数据的集中位置。一旦将服务元数据存放到 WSRR 中，就可以对其控制可见性，管理版本，监视使用，分析和理解建议的更改。本文介绍的提升，是 WSRR V6.2 中的一个功能，它为多部署环境下的元数据提供了方便有效的管理办法，很好的解决了服务开发过程中的重复部署及元数据管理问题。提升相关的基本概念
在正式介绍提升之前，先向大家介绍一些 WSRR 中与其相关的一些基本概念。
- 治理概要(Governance Profile)：治理概要提供执行治理策略的能力，可以用来进行服务生命周期的治理。
- 分类(Classification)：分类在与 WSRR 的许多交互中起主要作用。它们允许您使用公司术语来标注服务端点和服务定义的各部分。WSRR 使用它们来捕获治理状态。您可以使用它们来隔离在不同环境中部署的服务端点。WSRR 分类系统被捕获 OWL 文档中，您可以使用管理界面来将这些文档加载到 WSRR 中。然后使用来自这些分类系统的值来对 WSRR 实体分类，从而执行基于分类的查询，并基于分类来限制访问。
- 生命周期(Life cycle)：WSRR 通过一些状态以及指示这些状态变化的转换来表现生命周期。状态通过分类来表示，因此在访问控制中，可以用来限制服务在一个生命周期的特定状态，可以执行哪些转换。转换指定了状态之间的变迁。WSRR 允许相关服务的集合处于相同的生命周期，这样就保证了这个服务以及它所有的依赖都在严格的控制之中。每个被治理的集合都有一个最上层的对象----生命周期的主对象。任何从这个主对象到其他对象的关系（relationships）也都属于这个被治理的集合。当然，如果这个对象在与主对象建立关系前已经被治理，这时，该对象不会属于被治理的集合。WSRR 默认支持四种生命周期：服务生命周期，服务接口生命周期，服务版本生命周期，策略生命周期。
- 治理(Governance)：WSRR 通过生命周期的形式提供了基本的治理功能并支持一组丰富的可扩展治理能力：为治理实体建立您自己的服务生命周期模型、定义服务状态之间的有效转换、编写和插入验证器以保护状态之间的转换，以及指定（通知）作为转换结果而执行的操作。它还提供相关的界面来分析 WSRR 内容更改所产生的影响，并提供了对此类更改的审核。
前面我们介绍了与提升相关的一些基本概念，下面我们将通过提升的定义，场景分析以及原理来说明它的具体细节。
简单来说，提升就是将元数据从一个 WSRR 实例拷贝到其他的 WSRR 实例的过程。通过提升，您可以在一个中心 WSRR 实例上管理关联到多种部署环境的元数据（metadata）。当发生生命周期特定的转换（指示状态变化的转换）时，这个拷贝操作就会自动执行。中心 WSRR 实例上的元数据的状态发生变化的时候，数据内容或者数据的子集就会自动的拷贝到目标 WSRR 实例中。由此可见，提升可以有效的对 WSRR 中的元数据进行管理、控制。那么究竟什么可以在 WSRR 之间进行拷贝？提升又需要满足哪些条件呢？下面将通过一个典型的应用场景来说明提升是什么以及它是如何工作的。
图 1 提升的应用场景
如上图 1 所示，JK 证券公司有一个中心 WSRR （被治理的），里面所有的服务都被治理。他们有一个用于测试(test)的 WSRR 和一个用于生产(production)的 WSRR。他们希望服务根据其所处生命周期的不同阶段，可以被存储到不同的 WSRR 中去。同时，希望在中心 WSRR 中管理这些过程。
在这个场景中，当中心 WSRR 中的服务发生了触发测试提升的转换时，位于中心 WSRR 的服务将会被拷贝到测试 WSRR 中；当中心 WSRR 中的服务发生了触发生产提升的转换时，位于中心 WSRR 的服务将会被拷贝到生产 WSRR 中。
根据 WSRR 中实体所处的生命周期，当其发生指定的转换时（transition），提升即被触发。在一次提升过程中，会发生以下动作。首先，源 WSRR 实例（中心实例 central WSRR，提升的发起方）检查指定的实体处于生命周期的状态。接着，在源 WSRR 实例将实体导出，并将内容存储到文件中。然后，在目标 WSRR 实例中，将实体导入，从上一步导出的文件中获得相关内容。最后，改变被导入的实体的状态。
注意：
如果实体定义了属性和分类，那么当它被提升到目标 WSRR 实例中时，所有定义在该实体上的属性和分类也会被提升到目标 WSRR 实例中。
通过上面的介绍我们知道了提升应用在多部署环境中（多个 WSRR 之间），那么究竟可以在哪些 WSRR 之间可以进行提升呢？下表列出了几种支持提升的拓扑结构。
表 1. 支持提升的拓扑结构
源 WSRR 所在 server 环境 目标 WSRR 所在 server 环境 未开启安全的 WebSphere Application Server 未开启安全的 WebSphere Application Server 开启安全的 WebSphere Application Server 未开启安全的 WebSphere Application Server 开启安全的 WebSphere Application Server 开启安全的 WebSphere Application Server
提升提供了三种工作方式，可以根据实际需要选择其中的一种。
- 同步方式：WSRR 实体在发生生命周期的特定转换的时候，提升会立即被触发。
- 异步方式：WSRR 实体的提升不会在发生生命周期的特定转换时立即被触发，而是由定时器（Scheduler）触发的。也就是说，当实体发生了生命周期的特定转换，并且定时器到达了轮询时间，提升才会发生。
- 人工方式：WSRR 实体的提升由用户的操作来触发。
可以通过修改提升配置文件中的属性来对其进行配置，也可以通过配置界面进行配置（如图 2）。
图 2 提升配置界面
可以通过定义 WSRR 实例的环境和生命周期的转换来对提升的内容进行配置。提升的环境指定了目标 WSRR 实例。具体的信息包括，目标WSRR实例的地址（Location）和安全信息。Transition 标签指定了触发提升的转换，以及提升的目标 WSRR。当 WSRR 实体发生了生命周期的特定转换时，提升机制会检查配置文件中 transition 标签的内容，如果满足条件，提升就会被触发。其中，定义在该实体上的所有属性及分类也会一同被拷贝到目标 WSRR 实例中。另外，该实体关联（relationship）的所有实体，也会被拷贝到目标 WSRR 实例。
首先，我们来看一下提升配置文件的整体结构。
清单 1. 提升配置文件整体结构
... details of the promotion environments ... ...details of the life cycle transitions which cause promotion to occur ...从清单 1 可以看出，配置文件包括两个主要的元素，environment 和 transition。下面，我们分别来看一下这两个元素的包含的详细信息，以及如何对它们进行配置。
清单 2. 提升配置文件 environment 部分
syncmyIDmyPassword
清单2定义了一个 "Development"的提升的环境。 标签定义了提升的方式，内容为"sync"，即是同步方式。 标签定义了目标 WSRR 实例的信息，包括 WSRR 实例所在的服务器的名称和端口号。 标签定义访问开启了安全控制的目标 WSRR 实例的信息。包括访问的用户名和密码。
清单 3. 提升配置文件 transition 部分
http://....../6/1/GovernanceProfileTaxonomy#Development http://....../6/1/GovernanceProfileTaxonomy#Test
清单3显示了一个完整的 transition 元素的例子。在这个例子中，如果 WSRR 的实体发生了"DeployToTest" 的转换，那么它将被拷贝到 "Development" 和 "Test" 环境。转换(transition)的名字是一个完整的 URI(http://....../6/0/GovernanceProfileLifecycle#DeployToTest)。 里面的名字是清单 2 的 元素中定义的，并且，环境的名字也要保持一致。
如果提升失败，那么，将发生 所指定的转换。那么，什么时候需要用到 呢？比如说，当实体正在进行异步方式的提升过程中发生了错误，那么，为了保证数据的一致性，我们需要把被提升的实体回滚到被提升之前的状态，这个时候，我们需要在配置文件中定义 元素来达到这个目的。需要注意的是， 的内容必须是一个有效的转换，否则，失败转换将会失败，数据将会不一致。而且，这个元素只能用在异步提升的方式中，如果是同步方式或者是人工方式，这个元素将不起作用。下面将通过一个具体的配置来说明，如果使用 元素。
清单 4. promotion 配置文件 -failure 部分
http://....../6/1/GovernanceProfileTaxonomy#Developmenthttp://....../6/1/GovernanceProfileLifecycle#Repair
清单 4 是一个 failure transition 的例子。如清单中所示，如果实体发生了"ApproveForDeployment" 的转换，那么它将被拷贝到开发环境中（Development）。如果拷贝失败了，实体将会发生 标签所示的 "Repair" 转换，回滚到提升之前的状态。
JK Securities 证券公司营销策划部根据中国用户的需求，计划开发一个全新的投资海外市场的QDII 基金产品。当营销策划部建立了业务流程以后，就将这个商业模型移交给产品开发部进行具体的 IT 技术层面的实现。
现在产品开发部的开发人员完成了股票报价服务的开发，希望测试人员对其进行测试，于是将中心 WSRR 中的该服务的状态改成 ApproveForDeployment。WSRR 检测到状态的变化，将该服务提升到测试 WSRR，以便测试人员进行测试。整个过程如图3所示：
WSRR 默认支持 4 种生命周期，服务版本生命周期，服务生命周期，服务接口生命周期，策略生命周期。应用场景中的 WSDL（StockQuoteServiceSample.wsdl） 处于服务版本生命周期（如图 4 所示），当发生 ApproveForDeployment 转换时，提升被触发，该 WSDL 被拷贝到测试 WSRR。
下面将为您演示如何通过同步方式将 WSDL 文档从中心 WSRR 实例拷贝到测试 WSRR 实例。
1．实验环境介绍
本次试验包括两个 WSRR 实例和一个 WSDL 文件。
- 中心 WSRR 实例（地址: 9.186.0.70，端口:2809），该 WSRR 实例里存储了一个 WSDL 文件 （StockQuoteServiceSample.wsdl）。
- 测试 WSRR 实例（地址: 9.186.0.159，端口:2809），提升的目标实例，提升发生后，中心WSRR 实例的 WSDL 文件将会被拷贝到该实例。
2．实验步骤
1. 使用 WSRR 的界面激活 Governance Profile。
图 5 激活 WSRR Governance Profile
2. 通过 WSRR 的界面修改配置文件，如下图 6 所示：
3. 对 WSDL 文件进行分类，该分类即为目标环境中的分类。
4. 使用服务生命周期（ServiceVersionLifecycle）治理 WSDL 文件（StockQuoteServiceSample.wsdl）中定义的服务版本（ServiceVersion）。
5. 将 ServiceVersion 转换到 AprroveForDepolyment 状态，这时 promotion 就会被触发。
3．实验结果
从图 10 中可以看出，WSDL 文件（StockQuoteServiceSample.wsdl）已经被拷贝到目标 WSRR实例中。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-589250/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14789789/viewspace-589250/
扫一扫
329
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
