摘要：服务虚拟化成为一类新兴的SOA组件建模工具的基础。利用一种新的仿真方式，在软件服务实现之前很久，开发团队就可以与其协同工作了。这涉及到在创建高质量的复合应用时遇到的某些最大的瓶颈，并帮助敏捷开发工作，努力跟上快节奏的Web应用的步伐。

　　“在应用开发生命周期中植入虚拟化的想法是我们目前所见到的最令人兴奋的技术，”Theresa Lanowitz说：“这会使得包括开发、测试及运营团队在内的IT组织管理可以管理典型的成本、质量及进度的三角关系。”Theresa是Voke Media的创始人兼分析师。
　　
　　这些工具使得软件开发团队可以在已有或计划服务的上下文中，使用预期要交互的新代码测试新服务的性能及行为。这降低了在开发中测试代码的门槛，使得在开发过程可以更早更容易地发现缺陷，并打开了SOA应用敏捷开发之门。
　　
　　Parasoft声称其一款产品SOA Test体现了服务虚拟化概念。这一术语是在2007年由iTKO在LISA平台发布时发明出来的。近年来，包括IBM、CA及惠普在内的主流企业软件供应商已经开发或收购了一些服务虚拟化工具，服务虚拟化已蓄势待发，准备成为主流的工具类型。IBM最近收购了Greenhat,CA则收购了iTKO,HP也开发了自己的内部工具。
　　
　　Lanowitz说：“市场已经准备好聆听服务虚拟化在帮助管理成本方面能做些什么。这已经在金融服务、零售、电信及其他组织内部署了高度复合的应用。在测试组织无法接触大型主机的时候这很有用。”
　　
　　Stub、mock及服务虚拟化
　　
　　传统上开发者已经建立了stub和mock来表示新代码需要交互的服务。这一方案把开发者的注意力从写代码上转移，从而减少了其有用的输出。PeterCole,GreenHat的前CEO,现在是IBMRational软件部质量管理主管说：“开发者针对mock进行测试的时候，他们将服务预期表现出来的行为进行编码，而不是根据实际情况进行。我们发现最令人生厌的集成问题就是由于不好的假设导致的。”
　　
　　中间件集成是一种不断复杂化的尝试。一旦新代码最终准备就绪，可以拿到实体平台上进行测试，开发者或测试者就得管理与这一代码交互的其他服务。在许多情况下这些服务都是运行在开发者不熟悉的平台上的。“有些开发者把30-50%的时间花在准备测试上面，”Cole说。而另一方面，他继续说：“虚拟化服务更容易实现和管理。不到15分钟开发者就能建立几个虚拟化服务了。”
　　
　　服务虚拟化对代码有可能需要交互的服务的行为建模。这跟对所有的底层代码逻辑都进行建模相比要容易得多，ITKO创始人、现在是CA技术的着名工程师John Michelsen说：“你必须开发软件的一部分以便与软件的另一部分行为相匹配，这样就不会有人知道仿真与实体的区别了。它必须提供相同的界面，但不需要支持所有的底层逻辑。”
　　
　　“客户也许有10亿行自己无法理解的COBOL,”他说。通过仿真或虚拟化服务，他们不再需要理解这10亿行代码，他继续道，他们只需知道如何与别的应用交互即可。
　　
　　服务虚拟化工具可以移除若干开发过程中对测试硬件可用性、服务及隐私方面的约束，Parasoft负责战略企业发展的副总裁WayneAriola说。Parasoft最近的一项调查发现组织与平均8到10个受测应用存在依赖关系。而开发者在任何时间点上只能接触到这些依赖关系的30%.
　　
　　通过服务虚拟化，开发团队还可以针对新服务的特定行为进行测试，而不是等待代码开发完毕再开始。这强化了朝着更敏捷、高度迭代开发技术趋势的演进。服务虚拟化还可以允许组织对敏感数据建模和屏蔽，使得这些数据可以在HIPAA、SOX等隐私约束下进行服务测试。
　　
　　向云计算的演进可能会进一步加快服务虚拟化的应用，惠普应用产品营销主管KellyEmo说：“比如说，当作为复合应用的一部分的新业务需求向云迁移时，信贷服务或存货服务就会倍感压力，”她说：“从开发团队的角度看，已有的共享服务会出现非常快速的变化。”
　　
　　更糟糕的场景正等着。实际上，开发团队往往会陷入等待状态，Emo说。“他们需要进行端到端的测试，可是服务可能却还没有就绪，”她说。这些延误导致团队错过日程安排，或者测试不够优化。惠普的服务虚拟化产品试图解决这一瓶颈。
　　
　　美洲银行是服务虚拟化的早期采用者之一，该公司已经习惯了用这一技术来增加测试的覆盖面以及改进代码质量。美洲银行的前任性能与弹性测试经理BurtKlein说，为了采用传统测试方法对两项应用进行测试，该组织一直在考虑使用一款高成本的测试平台。现在他们可以采用iTKO的一款新的服务虚拟化测试基础设施来节省投入，现在该产品已经壮大到支撑更多的并发版本。
　　
　　Klein说这个平台能够为性能、运营测试提供更好的测试覆盖面。它们能够模拟新代码需要交互的单个服务的性能，从而帮助识别出不同的断点以及相关行为。在失败发生时这一知识可以帮助运营团队识别底层的瓶颈。
　　
　　这一基础设施工具还极大地改善并加快了寻找、解决缺陷问题的能力，Klein说。在这个案例中，有一个缺陷被认为是完全的失败或者无法满足应用的服务水平协议。在第一次部署服务虚拟化之后，错误率从每百万次有18000次失效的几率下降到了250次。进一步的调优之后错误率最终降低为0.0001/百万。
　　
　　Klein对服务虚拟化的印象异常深刻，以至于他离开了该银行，自己组建了一个服务虚拟化社区，帮助树立对该技术的意识，并作为共享最佳实践的论坛。他解释说：“我将其视为我的软件开发生涯中的游戏改变者。”
　　
　　责任编辑：Randy