不连贯的开发和整合生命周期

　　开发人员需要把服务接口做成一个占位符模型以便确定他们的服务如何与其它服务互操作。例如，一个开发团队正在扩建用户数据，而第二个开发团队正在创建账户数据。由于这些应用程序是并行开发的，这两个团对需要相互依赖对方的服务。每一个团队都需要依靠访问接近完成或者已经实施的服务来证明他们自己的服务能够正确地互操作。

　　SOA通过把松散耦合的组件当作服务来实现灵活性。因此，更小的和更分散的团队能够并行开发和集成这些服务。当仍然存在依赖性的时候，我们如何才能达到这种并行开发的水平呢?看一下这个典型的项目计划或者甘特进度表。在下一个开发团队继续开发下一个组件的之前，肯行会遇到一个项目中可用组件的下一个“依赖性”。这正是我们希望用SOA打破的一个模式。

　　增加的复杂性和异质性

　　虽然许多做SOA的计划都是以Web服务(WSDL/SOAP)为中心的，但是，在非常好的的企业实施的SOA计划中只有大约50%是基于Web服务的。有多种技术可以用来创建SOA中间件软件。这些SOA中间件软件也许是非常合法的，对于一个指定的机构来说也许比一个Web服务栈更好，例如使用一个几乎不依赖Web服务的企业服务总线。要保证SOA的质量，各个团队需要验证实施状况和对各种不同技术产生的副作用，而不仅仅测试自己选择的Web服务或者中间件软件层。

　　SOA测试环境维护和技术支持的高成本

　　要向一个SOA应用程序提供服务，许多机构试图复制和维护自己的测试环境。然而，复制他们需要在自己的过渡环境中进行交流的全部组件是一个成本非常高的过程。它需要高水平的配置、许可证成本和维护，以保证那个测试构件保持最新状态，即使它是在虚拟的硬件中运行也是如此(虚拟的硬件也有一些增量的许可证成本)。SOA利用的许多企业系统都太大了，有太多的开销，不能实施虚拟化。

　　不要试图通过复制数十个变化的服务来创建一个巨大的测试基础设施，SOA需要一个策略解除这些团队对这些实施的依赖。这将提供一种根据部署中存在的现实状况进行测试和开发的方法。

　　数据和系统记录的庞大规模

　　达到企业级SOA应用水平的最后(也许是最困难的)障碍是需要管理的系统和数据的庞大规模。要测试一个SOA应用程序的实际效果，机构需要输入一套逼真的数据，然后离开正在测试中的环境。

　　虽然他们能够在架构和设计过程中根据制定的元数据描绘出与其它服务之间的互动，但是，一旦他们通过连接这些端点的理想的模型，他们还必须要应付一个CRM大型计算机或者企业系统以及这些系统的管理者。嵌入在这些层的数据和商业逻辑在过去的若干年里已经增加并且客户化了。把这个系统和数据制作成完整的镜像副本并且根据另一个企业许可证和实施团队的要求进行测试成本太高了。

　　引进面向服务的验证

　　SOV(面向服务的虚拟化)是一种IT策略，它要模拟组成一个SOA应用程序的软件资产的实际行为，进而使开发和测试团队摆脱对应用的服务及其基本实施层的依赖。

　　SOV包括建模和模拟设计之中和应用的服务以及虚拟的服务。这些虚拟的服务将提供给扩展的SOA团队进行测试并且开发自己的服务和工作流，不用依靠这些服务的实例。当各个团队摆脱了对应用的服务和实施层的依赖的时候，提高的灵活性、更快的上市时间和减少的交付成本等扩展的SOA的好处就全部实现了。要做个比喻的话，SOV是针对SOA的，就像硬件虚拟化是针对数据中心的一样。

　　在SOA生命周期中的SOV的例子

　　SOV不仅影响完成的应用程序的质量，它在加快SOA生命周期的开发和治理过程中发挥着巨大作用。目前在企业中还没有出现更多的采用SOV的做法。

　　SOV应用实例1：灵活开发SOA新功能

　　企业正在脱离昨天单一的发展缓慢的“宇宙大爆炸”式的实施方法。那个时候，整个应用程序的开发、测试和发布都是一个连续进行的过程，通常是在一个权威机构的领导下。

　　今天，应用程序是松散耦合式的一些服务的集合，是在运行时间作为灵活的工作流的情况下灵活消费的，由灵活的开发人员和合作伙伴组成的分布式的团队进行管理的。一个灵活的SOA应用程序基础设施能够非常灵活地满足不断变化的商业需求。

　　为了提供能够满足商业要求的服务，开发人员和QA团队必须要针对当前正在开发中的虚拟服务进行测试。如果企业要得到SOA的灵活性的好处，所有的团队必须在自己的生命周期并行开发和发布自己的服务，不要等待其他人。