本文是本系列的第17部分，将讨论如何开发能在内部和外部正常运行而不会导致系统过载的Web服务。通过本文的示例，您可以了解如何在开发过程中使用IBM Rational ClearQuest和IBM Rational Functional Tester。

　　引言

　　在本系列前面的部分中，我们已经了解了面向服务的体系结构（Service-Oriented Architecture，SOA）中连接到另一个SOA中的一个或多个外部服务的原始Web服务。另外还了解了如何尽可能地提高外部Web服务互操作性。

　　本系列的第1部分提供了组织控制之内和之外的通过SOA弥合企业系统差距的多个场景。您了解了如何在组织控制内对来自一个或多个SOA的Web服务进行重用，以及如何将这些Web服务组合为组合应用程序。

　　本系列的第9部分讨论了如何将内部和外部射频识别（Radio Frequency Identification，RFID）Web服务组合为原始SOA中的组合应用程序。内部Web服务可能在组织的业务单位控制之下，而外部Web服务可能在相同组织的不同业务单位控制之下。

　　在本文中，您将了解如何提高Web服务的动态性。完成此任务的一种方式是，同时以遵循内部和外部工作的方式开发每个Web服务，具体取决于每个Web服务的组织控制程度。您还将了解如何确定何时Web服务能彼此进行互操作来尽可能地利用外部和内部资源而不会导致系统过载。

　　存储库动态Web服务

　　为了让内部Web服务像外部Web服务一样工作，需要开发我称之为存储库动态Web服务(Repository Dynamic Web services)的存储库。这在概念上与在本系列第16部分讨论的服务成熟度模型（Service Integration Maturity Model，SIMM）的存储库Web服务类似。您需要创建存储库动态Web服务，而不采用将代码存储在基于活动和资源的服务上的形式引用模型。

　　让我们将存储库动态Web服务划分为核心、高级和组合Web服务，如以下所示：

　　·核心内部Web服务
　　·核心外部Web服务
　　·高级内部Web服务
　　·高级外部Web服务
　　·组合动态Web服务

　　您需要能够与其他核心Web服务及现有高级Web服务一起重用来构建组合动态Web服务的核心Web服务（内部或外部）。如果没有核心Web服务，就缺少构建的基础。您需要从业务合作伙伴或不同的原始组织单位获得在存储库中存储外部Web服务的权限。

　　在存储内部Web服务前，必须将其标识为核心Web服务或高级Web服务。要构建动态Web服务，您必须首先从核心内部Web服务开始着手。如果没有这个核心Web服务，则需要应用框架内部Web服务模板作为临时核心Web服务的占位符。可以将核心内部Web服务与其他核心与高级Web服务一起重用，以构建组合应用程序。

　　可以在指定的时间内将这些高级Web服务保留在存储库中，以便进行进一步重用、再工程或重新配置。过期后，会对其进行处置，从而为最新的高级Web服务腾出空间。

　　活动和资源

　　为了将内部和外部Web服务组合为动态Web服务，必须指定一个或两个参数，从而将其指定为内部服务或外部服务。参数的值必须为动态的，以使动态Web服务将其状态瞬间从外部更改为内部，或反之亦然。其值将根据内部或外部Web服务所触发的事件发生变化。可以将基于活动的Web服务和基于资源的Web服务组合为组合动态Web服务。

　　随着动态Web服务从内部服务变为外部服务（反之亦然），基于活动和基于资源的服务各自所占的比例将发生动态变化。例如，在Web服务生命周期中响应事件的特定点，基于活动的服务所占比例可能会比较高，而基于资源的服务所占比例可能会比较低。随着动态Web服务在响应另一个事件时移动到生命周期的另一个点，基于活动的服务所占的比例可能会降低，而基于资源的服务所占的比例可能会提高。

　　避免系统过载

　　接下来，需要检查动态Web服务的性能。您需要确定在不会导致系统过载的情况下能够内部和外部使用的最大资源数量。一个方法是开发一组Web服务分析器，如以下所示：

　　·工作流分析器
　　·冗余分析器
　　·资源分析器
　　·性能分析器

　　为了节约开发时间，可以使用Rational ClearQuest和Rational Functional Tester，这两个工具为测试团队提供了对测试管理、缺陷管理和自动及手动功能测试的集成集中访问。通过将测试工具集成到大型的企业开发项目中，可以减少测试实验室管理成本。

　　Web服务分析器

　　第一个分析器关注能够与外部Web服务进行组合形成动态Web服务的内部Web服务的工作流。第二个分析器删除由于组合造成的冗余（只要可以删除）。第三个分析器关注运行多个动态Web服务时的资源总量、限制和峰值。第四个分析器从线程、句柄和流程的角度考虑动态Web服务的总体性能。

　　工作流分析器

　　Web服务工作流分析器的主要目的是，向用户或开发人员发送关于在开发组合动态Web服务的过程中，Web服务用于与其他Web服务进行协作的任务、功能、活动和资源的消息。可以通过更改Web服务的参数创建备选工作流，然后从其中选择最好的备选项。

　　冗余分析器

　　当将Web服务组合为单个动态Web服务时，开发人员需要开发Web服务冗余分析器。如果分析器发现要创建的动态Web服务将导致冗余或重复服务，则会向您发送一条消息，指出组合Web服务或减少冗余的首选方法。这意味着会对代码进行简化，以减少使用、发现或公开动态Web服务所需的资源。

　　资源分析器

　　减少代码的数量并不是减少所需资源的唯一方法。您需要开发Web服务资源分析器来确定由于互操作问题和过度使用资源导致系统过载的其他因素。当Web服务从一个协议切换到另一个协议以及从一个软件框架转向另一个软件框架时，就可能出现运行Web服务的平台间的互操作问题。

　　此分析器应该能够实时地发送消息，指示Web服务何时何地以何种方式表现出性能低下。性能糟糕的动态Web服务可以导致多米诺效应，导致其他Web服务（内部和外部）降到不可接受的地步。分析器应该提供足够的详细信息，以帮助您在出现系统过载前实时地纠正问题。

　　性能分析器

　　从Web服务资源分析器中，可以使用信息作为Web服务性能分析器的输入，以确定提供性能的备选方法。性能分析器还应该提供能够在使用稀缺资源时获得最佳性能的Web服务组合，从而避免所得到的动态Web服务导致系统过载。

　　动态Web服务场景

　　假定两个组织合并导致使用需求更改，而且由于新技术和新法规使供应资源发生了变化。这意味着动态Web服务开始充当外部和内部Web服务。它们动态地将其角色从内部切换到外部，或反之亦然，以响应使用服务的资源和活动的组织控制更改。

　　动态Web服务还可以应用到合并的代理服务中的更改。合并代理可能对所合并的提供者（连锁酒店）的服务使用者提供一组不同的代理服务（旅行）。可以开发动态Web服务来更新生产者与代理间的契约中的流程和资源活动。然后您（开发人员）和测试团队就可以基于分析器所进行的测试来检查工作流、冗余和性能方面的情况。

　　结束语
　
　　为了开发动态Web服务，将需要由开发人员、测试人员、系统管理员和潜在用户组成的团队。为了消除冗余、尽可能利用资源并确保部署不会导致系统过载，在从存储库构建流程和资源活动时，您必须事前进行计划，确定如何创建、测试和部署动态Web服务。

　　解决这些问题后，会使得开发动态Web服务的工作变得容易得多。可以使用IBM Rational ClearQuest和Functional Tester来缩短企业开发项目的测试时间，并减少测试实验室成本，从而提高效率。