由于采用了灵活、螺旋状的并行开发方法，在很多敏捷性开发周期的收尾阶段，用传统的瀑布式开发方法测试接近完成的应用程序其实并不能达到敏捷的效果，因为应用程序的组成要素在不断变化。传统的IT治理模式也将无法发挥作用。

　　为了解决这一问题，人们采用了SOA（面向服务的架构）设计模式，努力让IT更加积极地对业务所需要的变化做出更加积极的响应。新的过程工具被引进，专门用来协助分类服务资产，并组织SOA治理策略。

　　这些为了支持SOA而特意开发的新工具主要围绕SOA治理平台，比如惠普公司的Systinet / s2、SAG Centrasite、SOA Software、TIBCO ActiveMatrix和Oracle Fusion。这些SOA治理工具管理与服务有关的元数据的收集和分类，并组织他们之间的相互依存关系，同时再根据SOA策略文档确定如何组合服务才能满足业务需求。

　　在治理工具集中，SOA Registry/Repositories自动化测试和验证的新平台。传统的系统需求和功能测试将仍然执行，但在SOA环境中，自动化策略验证和执行的机会将会更多。

　　目前关于SOA治理的思想基本上是围绕设计时WSDL验证、运行性能和安全政策的执行。随着SOA治理的逐渐成熟，它需要支持各种各样的SOA项目，而SOA治理思想也必须大幅度扩大。SOA治理平台最大的价值之一就是必须提供一个证明，确保用人类语言或商业条款所表述的策略能够在系统中连续执行。

　　验证SOA策略

　　让我们看看下面这个部署示例：比如，你要将一系列的Web服务定义（WSDL文件），加载到UDDI注册器中。这些服务彼此之间的关系，以及这些文件如何捆绑在在一起以创建一个业务流程会被记录下来。如果企业招聘了一位新员工，这就可能会设计到一系列的服务，从确定员工的职位和上司的人力资源计划，到提供IT必要的资源比如电脑和电子邮件，同时还可能涉及到外部合作伙伴的保险和福利登记。这些服务将通过WSDL记录下来并储存在UDDI注册器中。这样，一个从人力资源到薪水制定的业务流程将会被确定下来。

　　只要每一个业务流程参与者提供了有案可稽的，可靠并安全的服务，这一切看起来很简单。这些围绕单个服务架构、行为和性能的策略都被记录在治理工具中。举例来说，业务分析师将会在CentraSite ActiveSOA这样的工具中编写策略，描述服务的行为。

　　IT服务将会根据新雇员的姓名和身份证号码返回一个新的e-mail地址，域登录和默认密码。安全服务将会向这位新雇员提供合适的系统访问控制权限。安全负责人指出，只有加密和签名数据被发送给服务，该服务才能运行。签名必须由企业安全证书主管验证，证明该请求是来自经过授权的HR人员。最后，IT运营团队将会围绕该服务每秒应该处理多少交易以及服务的最大响应时间制定一个策略。

　　如果要进行一个严格的人工验证过程，要进行的步骤远远不止这些。测试的执行应该驻留在SOA治理过程之中。

　　测试，验证和政策执行解决方案

　　企业为了管理IT环境的设计、架构、集成和治理必须要部署很多过程，鉴于此，找到一种通用的并且可重用的过程验证和执行方法是非常有意义的。SOA验证执法范围大增，可重复使用并且丰富的测试融合到业务的每一个流程以及支持它们的工具中。

　　上图所示的验证法提供了通过运行测试案例来验证一流的IT过程工具定义的不同的规则和策略的功能。通过在过程工具的工作流中将自动化的测试运行与的预期的行为和政策捆绑在一起，治理行为得以实现。从治理平台援引测试以确保SOA策略这一做法与测试管理解决方案的治理方法很相似，最大的不同在于需要验证组件整个生命周期的背景和阶段。

　　在传统的瀑布式开发测试方法中，有一个具体的时间点，用来标志该系统可以用于测试了。在今天基于服务的应用程序中，我们不能找到这样一个时间点。

　　在SOA生命周期中，我们将设计时、运行时和变更时看做是松散耦合系统中正在建设的业务过程或服务的三个阶段。在上面的例子中，一些服务与套装应用软件（人力资源系统）是互动的，一些是本地系统，其余的则来自外部合作伙伴。这三个阶段的开发和发布周期会有所不同，并且不能通过协调融合成一个大型发布。SOA的一个优势是有能力实现系统分拆，并利用其它项目创建的服务，无需自己开发。

　　在设计时阶段，运行测试确保WSDL符合WS-I的标准，并遵循RPC或文档调用结构，而且客户的特定标记被用于服务标识。在通过了上述符合性测试的基础上， WSDL就会被放入Repository中，开发人员就可以使用它们进行功能编码。

　　一旦开发人员编写了必要的代码来执行服务及其基本技术组件，服务的行为和安全性就需要被验证。验证服务背后的代码工作是否正常的唯一办法是援引该服务，然后验证基本的记录系统是否正确更新，因为在现实世界中没有硬编码响应，并且那种安全性是应该遵守的。

　　同样地，一个测试案例是用来调用并验证业务需求、行为以及安全策略得到了落实。如果候选服务可以通过这些策略测试，那么它就可以被发布在注册器中被消费者使用。如果这些测试失败了，那么该服务就不应该被提供给消费者。

　　作为最佳做法，单个服务一旦可用就应该进行负载测试。如果我们在组件开发的过程中就进行负载测试，根据测试结果随时改善系统性能，而不是等到系统部署完毕再去做这些事情，那么引入风险的概率就会小很多，因为系统一旦部署完毕，问题修复就会变得很难并且代价昂贵。渐进式开发团往往是在服务功能得到确认后立刻开始负载测试，从而使开发人员可以在消费者开始利用这些服务之前就修改代码，优化逻辑和数据访问。

　　在运行时阶段，服务会被提交到注册器中，同时还要进行功能测试，并把它提供给消费者作为自己应用流程的一部分。这些消费者也会承担使用该服务所造成的后果的责任。最好的方法是建立一个可执行测试资产来验证当服务被使用时，整个消费者工作流的架构、行为和性能方面是被支持的。当测试作为治理过程的一部分被连续运行时，这将会带来极大的方便。

　　最后一个阶段是变更阶段。SOA和敏捷性开发的真正有优点就是在这一阶段开始体现出来的。如果需要增加一项新的服务，或修改了现有服务以适应不断变化的业务需求，那么服务策略必须被重新审核。我们不仅要根据预期的新行为更新任何行为策略，而且还要复原现有策略。

　　如何你自己是一个服务消费者。你怎么才能相信打破现有的业务流程并使用新的服务，不会对你造成意想不到的后果（比如失败）？每个消费者需要将自己期望的行文作为一项策略放在注册器中，同时还要附带相应的测试，以便能够在做出更改之前自动验证。在测试中，自动化结构和策略行为代表了消费者的权利，以及他们使用这些服务的责任。当这些测试作为SOA治理的一部分自动运行时，服务消费者和生产者之间的信任就实现了。

　　在下一章节，我们将得出我们的研究结论。