SOV应用案例
SOV不只可以影响已完成应用的质量，还可以加速SOA周期中的开发与治理过程。我们可以找到很多可供实施SOV实践企业参考的案例。
SOV用例1：灵活开发SOA新功能
大多数企业已经不再使用过去单一、拖沓的实现方法在集中的管理机制下顺序进行开发、测试和发布全部应用。
现在，这些应用由松耦合的服务构成，由灵活的运行时业务流程实现弹性，由灵活的开发人员构成分布式团队进行管理，最终实现可以满足不断变化的业务需求的、灵活的SOA应用基础设施。
为发布满足业务需求的服务，开发人员与质量保证团队还必须对开发中的虚拟服务进行测试。如果公司要取得SOA的灵活性，那么所有这些团队必须按照自己的开发进度平行开发和发布各自的服务，而不能依赖其他的团队。
使用SOV建模
这些团队应该以虚拟服务的方式对所依赖的服务进行建模，而不必等待其他团队提供对已完成的服务的访问（见图3）。
图3
- 需要其他团队提供的服务拷贝以进行测试的团队，可以根据服务的行为、控制与响应方式，以及服务的实现基础和数据来开发虚拟服务。
- 开发过程中，开发人员也可将不完整的、或者即将完成的服务版本以虚拟服务的形式发布。
- 虚拟服务是供其他开发和质量保证团队用来测试自己团队所开发服务的。
- 这可节省开发与质量保证测试的成本，以及编写准确的测试客户端或“模拟服务”的时间。
- 可以在企业中实现高平行、灵活的开发与测试协作，减少新功能的开发时间，并可更精准地预测上市时间。
实例：实现经济服务公司发布灵活性
某家在经济服务市场占主导地位的公司将其集中的开发能力以类SOA的方式分为不同的业务流程交给特定的开发团队完成，以达到缩短服务实施周期的目的。虽然初期结果显示实施速度确实有所提高，但随着越来越多的支持SOA应用的服务部署，产生越来越严峻的客户服务方面的问题。
为解决这个问题，公司恢复了对发布服务的集中化管理，要求在11月之前提交所有“终端”服务。这样，经过两个月的测试周期，可以在2月前创建一个完整的SOA环境。但如果在以年为单位的测试周期中产生任何错误，系统管理人员就必须将服务换回前一版本。这意味着在正常情况下，一年只能进行一个开发周期，发布一个版本。不管从哪方面来讲，这都是非常不灵活的。
后来公司引进SOV模型，很大程度地缩短了开发周期。开发团队以虚拟服务的方式对环境进行建模，并在此环境下进行按需测试。他们还可以提供托管的虚拟服务，方便其它开发团队更早地进行测试。结果，公司解散了管理委员会，实现了每季一次的发布周期，周期变得更有持续性和灵活性，并可根据客户要求更快地进行编译和测试。
SOV用例2：复制完整的SOA环境
在内部应用开发过程中，在虚拟机上运行的虚拟化硬件和虚拟测试平台是一种很有效的复制服务器环境的方式，可以为新开发的组件提供针对现有软件的开发和测试环境。这种实践可以节省硬件与配置两方面的成本。
然而，SOA应用经常需要与第三方系统进行自由交互，而第三方系统一般不在集中的团队控制下。并且，SOA应用还需要与业务的基础系统（主机、ERP系统等）进行交互，而这些系统的实现可能要花费几百万美元的成本，并且储存有大量的关键数据。一般来说，开发过程中是禁止在这些系统上使用测试数据进行测试的，因为测试增加的负载可能会导致主要系统崩溃或者产生意料外的行为。并且，不管是从系统负载还是从配置成本方面考虑，用硬件虚拟化技术复制这样一个庞大的系统都是不可能的。
使用SOV复制SOA应用行为
即使用虚拟机复制部分功能，为完整的SOA应用实例配置与维护一个由独立组件组成的、完整的测试环境仍然需要巨大的的维护与支持费用。
如图4所示，SOV实践虚拟化了整个模拟测试系统的行为。各个团队对于测试或开发的复制需求由对所需的系统行为进行抓取和建模代替了。
图4
- 以虚拟服务的方式模拟相关服务代替受到使用限制的具体应用，不管这些服务是由WSDL生成、基础的实现或集成层服务的模型。
- 在恰当的时间重新捕捉或建模新的虚拟服务组件，比花费数周甚至数月才能复制完成的SOA实例能提供更新的目标服务模型。
- 在SOA应用中不断实践所有系统，为具体的业务数据创建一个丰富的测试平台，进而使用这些数据从虚拟服务中获得更多动态变化的行为。
- 远离服务部署进行开发与测试（测试、开发与修改过程中，SOV不能取代具体实现中对服务的集成测试）。
使用这个模型，企业可以在硬件、软件和维护方面节省数百万美元的成本，并缩短产品上线时间。
实例：解决电子商务全面数据监控问题
某全球化的高科技生产公司要实现使用CRM平台、ERP系统及其它存储与逻辑系统的电子商务解决方案。基本的Web服务层的可扩展性和兼容性在相关标准下的测试比较容易，但背后的数据交互系统却无法测试，因为这些系统已在使用并管理着关键的指令。
公司并没有花费大量资金去复制这些系统，而是选择采用SOV过程捕捉了主机和与系统交互的服务层的上千具体事务处理和交互（包括正面与负面的结果）。然后，使用这些丰富的数据集为主机设计与真实行为相近的虚拟服务，让团队在预算范围内准时完成有高可靠性的新系统。
下一步：从SOV到SOA集成的转换
一旦完成面向服务的虚拟化所有方面的协作开发与测试，虚拟服务便进入具体的集成过程。SOV不能取代具体的SOA应用对集成测试、性能测试和功能验证的需求。如果服务不能正确地与满足业务需求的服务交互的数据元协作，仍然可能产生负面效果。
有效的SOV策略可以产生两方面的价值：
- 灵活性：可以最优化分散的SOA开发与测试团队之间的协作性，使团队进入更平行的开发与发布周期，缩短新产品与功能的上市时间。
- 降低成本：可以在软件授权、配置、维护、数据管理、开发与测试效率等方面为每个SOA环境下的开发节省几百万的IT成本。SOA应用的协作性与互通性越强，虚拟服务能带来的效益就越高。
总之，对于使用分布式团队与资源开发的大规模的企业应用来说，SOA的圆满实现离不开SOV实践。因此，我们应该进行面向服务的虚拟化实践，用SOV技术解决SOA实现过程中的障碍，让SOA为企业带来更大的效益。
