没有面向服务的虚拟化SOA就很难取得成功

增加的复杂性和异质性

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

　　要向一个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的灵活性的好处，所有的团队必须在自己的生命周期并行开发和发布自己的服务，不要等待其他人。

　　SOA方法

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　SOV方法

　　·通过把连接的服务模拟为虚拟的服务在服务环境中取代实时受限制的应用程序，无论这些服务是来自WSDL还是根据基础实施和整合层模拟的。

　　·在这些组件能够用于这些活动的理想时候，要重新捕捉和重新模拟新的服务组件，提供比复制的SOA实例更新的目标服务的模型。这需要几个星期或者几个月的时间才能组装完成。

　　·在SOA应用程序中演练所有的系统以创建一个真实数据的丰富的测试平台。这些真实的数据将用来驱动这个虚拟服务的动态行为。

　　·在脱离应用的服务的隔离环境中进行开发和测试(在测试和开发中采用SOV方法，并且修改时间不取代在应用期间实时安装的服务的集成测试)。

　　通过按照这个模型操作，企业能够节省数百万美元的硬件、软件和维护成本，在不影响当前运营的情况下加快产品的上市时间。

　　例子：解决电子商务背后完整的数据图片

　　一家全球的高科技厂商正在实施一个新的电子商务解决方案。这个电子商务解决方案需要连接到一个主要的CRM平台、一个ERP系统以及其它存货和物流系统。虽然使用选择的标准很容易测试这些基本的Web层的可升级性和兼容性，但是，没有它们背后的数据相互交流情况来进行测试，因为这些系统已经在使用并且在管理重要的订单。

　　这家公司没有复制这些昂贵的系统，而是采用SOV流程捕捉数千个与它们交流的这些大型机和服务层之间进行的实时处理和相互作用(有正结果和负结果)。然后，这个丰富的数据集可驱动一些大型计算机的相关的虚拟服务，让这个团队及时地并且以低于预算的成本提供一个非常可靠的新系统。

　　下一步：从SOV向SOA集成过渡

　　一旦SOV的所有的协作开发和测试工作全部完成，这个虚拟服务便进入了实际集成过程的后台。SOV不取代真正的集成测试、性能测试和实时SOA应用程序的功能验证等实际需求。如何这个企业不能恰当地让定义这个服务相互作用的元数据满足商业目标的需求，它就很难产生积极的结果。