本系列讨论如何在企业级面向服务的体系结构（Service-Oriented Architecture，SOA）环境中使用Web服务；在本部分中，您将了解如何开发更改流程活动Web服务，并讨论如何开发这些Web服务来补充IBM?服务集成成熟度模型(SIMM)。本文将提供一些示例，以了解如何将IBM Rational? Function Tester Plus和IBM Rational Performance Tester作为开发流程的自动化测试工作的一部分使用。

　　引言

　　在所有能力成熟度模型（Capability Maturity Model，CMM）中，IBM SIMM被视为最灵活的部分，包括其在每个阶段的服务集成级别表示方面的灵活性。因为这个原因以及组织变更及其能够适应新技术引起的服务集成流程活动中的更改，开发人员应该构建作为SIMM补充的Web服务。

　　您应该首先从希望放入存储库中的流程活动的层次结构或工作流着手。然后将这些存储库中的所需流程活动组合起来或加以重用，以构建Web服务。接下来，应该测试所得到的Web服务SIMM应用程序。当测试成功时，将Web服务放入存储库中（称为存储库Web服务），以稍后在流程活动更改的情况下进行重用。

　　SIMM回顾

　　SIMM划分为七个成熟度阶段或级别。每个成熟度阶段表明服务集成的灵活性和分离级别，并提供了简单的说明。从每个阶段过渡到下一个阶段，就意味着更高的服务集成级别。这个流程将继续，直到模型达到其最高级别的生态系统集成。

　　第1级：竖井(Silo)

　　在此数据集成级别，组织从适当的临时集成开始，当遇到更改时，体系结构会很脆弱。

　　第2级：集成

　　在此应用程序集成级别，组织过渡到了某种形式的企业应用程序集成（Enterprise Application Integration，EAI）。其使用的方法经过定制，适合使用遗留系统。

　　第3级：组件化

　　此功能集成级别允许组织对其应用程序投资组合的主要或关键部分进行组件化和模块化。会对基于Java? 2 Platform Enterprise Edition (J2EE)或Microsoft? .NET的遗留系统进行重构，使其具有清楚组件边界和范围，以更为模块化的方式公开功能。

　　第4级：简单服务

　　在此流程集成级别，组织开始采用早期的SOA，将定义和公开供内部使用或供业务合作伙伴外部使用的服务。它将充当服务提供者。

　　第5级：组合服务

　　此供应链集成级别允许组织将其影响扩展到价值链和服务生态系统中。服务在提供者、使用者和代理之间形成契约，它们可以为随需应变交互构建自己的生态系统。

　　第6级：虚拟服务

　　在此虚拟基础设施级别，组织将创建虚拟基础设施来运行应用程序。组织在分离应用程序、其服务、组件和流之后，就可以达到此级别。它将其监视、管理和事件（公共事件基础设施）外部化。

　　第7级：可动态重新配置的服务

　　处于生态系统集成级别的组织现在将创建虚拟基础设施来运行应用程序。组织在分离应用程序、其服务、组件和流之后，就可以达到此级别。它将其监视、管理和事件（公共事件基础设施）外部化。

　　流程活动的更改

　　SIMM在从较低成熟度级别向较高成熟度级别过渡的过程中，不能跳过任意阶段。由于不可能合并，所以此模型无法从较高级别返回到较低级别，例如，无法在组织作为服务提供者的原始角色的流程活动更改的情况下，从流程集成级别降级。另外，也不可能从模型的稍后阶段（如组合服务）向之前的阶段（如简单服务）发送消息，以请求由于流程活动的更改而更新组织的角色（如服务提供者）。

　　要处理这些更改，我建议将Web服务作为层次结构流程活动的存储库和可重用Web服务开发。可以从存储库检索流程活动，并将其组合为自定义Web服务功能，并同时消除活动冗余。可以在Web服务SIMM中使用组合功能来与模型的简单、组合、虚拟化可动态重新配置的服务进行通信，并对其进行补充。

　　流程活动的层次结构

　　该层次结构的底部是任务，任务是流程活动的基本组成部分。下一级别是一组有顺序的任务，用以执行单个流程活动。再上一级别，您将功能以松散耦合或紧密耦合的方式分组到一起——全部在一个流程活动中。然后可以对各个流程活动进行组合，以形成更为复杂的流程活动。这个流程将继续，直到抵达顶级流程活动为止。

　　在自顶向下方法中，首先从顶级流程活动开始，此活动分组为三个或更多基本的流程活动。其中每个活动都进一步细分为更低级别的活动、功能和任务。

　　在这两个版本中，都可以看到每个流程活动如何通向不同级别的另一个活动。流程活动可以跳过一个级别，到达层次结构中更高或更低级别的活动。

　　流程活动工作流

　　使用层次结构的一个优势是，可以看到工作流如何更改以及任务和功能冗余的位置（及如何消除冗余）。另一个优势是，流程活动会发展和更改，可以随后在层次结构中调整工作流，以包含这些更改。

　　而且，还可以看到较高级别的流程活动如何以及从何处向较低级别的活动发送反馈消息，反之亦然。将更改包含到流程活动中的灵活性为其本身带来了流程控制功能。也就是说，如果流程活动的性能从可接受阈值下滑，此灵活性允许您确定哪些流程活动影响了性能而需要进行改进来将性能提高到阈值之上。

　　存储库与分析器

　　要检查Web服务SIMM的性能，需要按照以下顺序进行开发：

　　·存储库Web服务
　　·Web服务工作流分析器
　　·Web服务冗余分析器
　　·Web服务性能分析器

　　为了节约开发时间，可以在Microsoft Windows?和Linux?平台上使用Rational Functional Tester Plus和Rational Performance Tester实现Web服务应用程序测试自动化。自动化非常重要，因为决策者可能没时间等着看流程工作流的工作和性能结果。决策者可能对关键问题要立即决策。

　　第一类测试工具允许测试团队测试采用Java和.NET技术编写的应用程序，包括IBM Rational Robot（该工具专门测试使用Oracle Forms、Microsoft Visual Basic、C/C++、Sybase PowerBuilder和Borland Delphi构建的应用程序）。第二类测试工具分析测试，以验证复杂电子商务应用程序的可靠性，并提供了针对Siebel和SAP应用程序的可选扩展。

　　存储库Web服务

　　需要开发一个存储库Web服务来存储和检索存储库中流程活动的代码。应该依据较高成熟度级别的重要元素对存储库进行组织。其中包括组织、随需应变交互（服务提供者、使用者和代理之间）、应用程序和事件。

　　Web服务工作流分析器

　　Web服务工作流分析器的主要目标是建议用户或开发人员存储库中的哪些任务、功能或流程活动能够在工作流中一起工作。可以从备选工作流中选择能够用于创建Web服务的项，以执行补充SIMM的单个功能。

　　Web服务冗余分析器

　　当将流程活动组合为单个Web服务功能时，需要开发Web服务冗余分析器。如果分析器表明将要创建的Web服务SIMM将导致冗余或重复服务，则会发出消息，指出对任务、功能和流程活动进行组合或减少冗余的首选方法。这意味着有必要减少代码数量。

　　Web服务性能分析器

　　应该有相应的机制（如Web服务性能分析器）来建议流程活动的哪种组合能够在使用稀缺资源的情况下获得最佳的性能。分析器应该确定由组合服务组成的Web服务不会导致系统过载。

　　补充流程活动

　　考虑以下两个使用通过存储库中的流程活动构建的Web服务对SIMM进行补充的场景：

　　场景1：简单服务

　　假定处于简单服务阶段的组织最终与另一个组织合并了。合并后的组织提供一组不同的服务，以供内部使用或供业务合作伙伴外部使用。

　　您需要从Web服务存储库调用脚本来执行流程活动，如自动更新合并后的组织提供以向客户和代理公开的服务。然后您和测试团队测试分析器的结果，并使用Rational tester工具检查工作流、冗余和性能。

　　场景2：组合服务

　　组合服务级别不讨论合并或其他形式的重组对契约中的使用者、提供者和代理的影响。一个影响的例子是，由于新技术和新法规的实施，不仅会影响合并后的组织的在其使用需求方面的更改，而且还会影响供应组织在其供应资源方面的更改。

　　那为特定提供者（连锁酒店）的很多服务使用者提供代理服务（旅行）的代理（也称为中介）如何呢？代理组织合并时，这将如何影响所得到的代理服务？需要从Web服务存储库调用脚本来更新提供者、使用者和代理间契约中的流程活动。然后您和测试团队测试分析器的结果，并使用Rational tester工具检查工作流、冗余和性能。

　　结束语

　　为了开发Web服务来补充SIMM，需要由开发人员、测试人员、系统管理员和潜在用户组成的团队进行协作。从存储库构建流程活动工作流时，需要事先对Web服务创建、测试和部署进行计划，以消除冗余和确保部署不会导致系统过载。

　　您会发现解决这些问题后，您开发Web服务来补充该模型的工作变得容易多了。可以使用IBM Rational Functional Tester Plus和IBM Rational Performance Tester通过减少构建/发布循环中的测试时间，从而提高效率。