SOA方法

　　不要等待其它团队提供访问已经完成的服务进行测试，这个团队要制作他们作为虚拟服务所依靠的那些服务行为的模型。

　　一个团队需要一个服务的副本进行对照测试和开发。这个团队要把一个服务的行为、它对刺激的控制和反应以及它的基础的实施和数据作为一个整体进行分析并且制作一个虚拟服务的模型。

　　一个服务开发人员在开发的时候还能够以虚拟服务的方式发布一个自己服务的完整版本或者“未来的”版本。

　　其它开发和QA（品质保证）团队将利用这个虚拟的服务测试自己的服务。

　　这将节省开发/QA成本和减少编写客户化测试客户端软件或“模拟服务”的时间。这些模拟服务不是附属服务的真正行为的实际模型。

　　它允许在整个机构中进行高度并行的、灵活的开发和测试协作，以便用新的功能保证更快和更有预见性的上市时间。

　　例子：提供访问以重新获得灵活性

　　一家主要金融服务公司把它集中的开发功能按照SOA式的模型分为不同的商务流程，让专业服务开发团队实现更短的服务交付周期。虽然最初的结果显示了更快的交付过程，但是，随着支持SOA应用程序的更多新服务开始应用，出现了客户技术支持需求量大幅度增长的问题。

　　为了解决这个问题，这家公司恢复了对发布的集中控制，要求在11月之前提交所有的“最终服务，以便为计划在1月份完成的两个月的测试周期创建一个完整的SOA的总体环境。如果在一年的测试周期中出现任何错误，这个系统管理员会把这些候选的服务退回到以前的版本。这就意味着一个开发周期是一年，如果一切正确才能发布。这种做法按照任何定义都是不灵活的。

　　通过使用一个SOV模型，这家公司现在能够把这个一年的周期分为若干部分。开发团队现在能够根据目标环境创建一个模型，并且根据需要针对这个环境进行虚拟服务和产品测试。他们还能够向其它附属团队提供一个托管的虚拟服务，这样，他们就能获得进行测试的早期的资产。因此，这家公司解散了它的控制委员会，采用每个季度发布一次的周期（这个发布周期是连续不断的和灵活的），并且建立和测试对用户的需求反应更明显的活动。

　　SOV应用实例2：复制一个完整的SOA环境

　　在一个内部应用程序开发过程中，在虚拟机上运行的虚拟化硬件和虚拟测试平台是复制服务器环境的一种有效方法。它为对照现有的软件开发新的软件组件提供一个良好的开发和测试的基准线。这种做法可节省硬件和设置成本。然而，SOA应用程序通常需要与那些不在任何集中的团队控制之下的第三方系统进行互动。此外，它们需要连接到商业的“基础的”系统（大型计算机、ERP系统等）。每一个系统都是数十亿美元的设备，里面有大量的重要数据。在开发期间向这些系统发送测试数据是被禁止的，因为测试负担会引起关键系统发生故障或者出现不可预料的后果。而且，从系统开销和配置成本方面来说，通过硬件虚拟化复制这样庞大的系统都是不可能的。

　　通过面向服务的虚拟化（SOV）设置和维护一些互相依赖的组件的一个完整的测试环境为一个完整的SOA应用程序实例复制SOA应用程序的行为在维护和技术支持的成本方面不允许的，即使采用虚拟机复制某些功能也是如此。

　　如图4所示，这种SOV的做法虚拟化了正在测试之中的整个系统的模拟版本的行为。为了每一个团对访问相关的测试和开发过程，捕捉和模拟系统需要的大多数行为的能力将取代复制的需求。