SOV Use Case 2: Replicating a Complete SOA Environment
In an internal application development process, virtualized hardware and virtual test beds, running on VMs, are an effective way to replicate server environments to provide a good baseline for development and testing for new software components against existing software. This practice saves both hardware and configuration costs. However, SOA applications often need to interact with third-party systems that are not under any centralized team's control. In addition, they need to interface with the "foundational" systems of the business (mainframes, ERP systems, etc), each of which could be a multimillion dollar implementation with terabytes of critical data sitting on it. Throwing test data against these systems during development is often forbidden, as a test burden could cause that key system to fail or behave unpredictably. Furthermore, replicating such a large system through hardware virtualization is impossible, both in terms of system overhead and configuration cost.

Replicating the behavior of SOA applications through service-oriented virtualization (SOV) Configuring and maintaining a complete test environment of interdependent components for a complete instance of the SOA application is cost-prohibitive in terms of maintenance and support, even if a VM is employed for replicating some of the functionality.

As shown in Figure 4, the practice of SOV virtualizes the behavior of a simulated version of the entire system under test. The need for replication is replaced by an ability to capture and model most of the needed behaviors of the system for relevant test and development access for each team.

The SOV Approach

• Replace live constrained applications in the services environment by simulating connected services as virtual services, whether they are pulled from WSDL or modeled from underlying implementation and integration layers 
   
• Recapture or remodel new virtual service components at ideal times when they are available for such activity, providing a more current model of target services than a replicated SOA instance, which can take weeks or months to assemble 
   
• Continuously exercise all systems in the SOA application to create a rich test bed of realistic data that is used to drive more dynamic behavior from the virtual services 
   
• Develop and test in isolation from the deployed services (SOV during testing, development, and change time does not replace integration testing of live implemented services at deployment time).

By following this model, enterprises can save millions of dollars in hardware, software and maintenance costs, and accelerate time-to-market without compromising ongoing operations.

Example: Solving the Complete Data Picture Behind eCommerce
A global high-tech manufacturer was implementing a new eCommerce solution, which needed to interface with a leading CRM platform, an ERP system, and other inventory and logistics systems. While the basic Web services layers were easy to test for scalability and compatibility with chosen standards, the data interactions behind them were not available for testing, as those systems were already live and managing critical orders.

Rather than trying to replicate these costly systems, the company employed an SOV process to capture thousands of live transactions and interactions (with both positive and negative results) between those mainframes and the services layers that interacted with them. This rich dataset could then drive a more relevant virtual service of the mainframes, allowing the team to deliver a highly reliable new system on time and under budget.

Next Step: Transitioning from SOV to SOA Integration...
Once all of the collaborative development and testing aspects of service-oriented virtualization are complete, the virtual services step into the background of the actual integration process. SOV does not replace the actual need for real integration testing, performance testing, and functional validation of the live SOA application. If the business does not properly align the metadata that defines the interaction of services to meet business goals, it will still struggle to produce a positive outcome.

Expected Benefits of Virtualizing Services
An effective SOV strategy provides two areas of value:

1. Agility: Maximizing collaboration across distributed SOA development and testing teams, moving them into more parallel development and release cycles for faster time-to-market of new products and functionality.
2. Reduced cost: Saving millions of dollars in IT cost per SOA environment through software licensing, configuration, maintenance, data management, development, and testing efficiencies. The more collaboratively built and the more interdependent the target SOA application is, the more potential benefit virtual services can offer.

Indeed, for any large-scale business application with distributed teams and resources, SOA will not fully succeed without SOV practices. I invite you to experience service-oriented virtualization and learn how SOV can break the barriers to delivering the benefits your company expects from SOA.

Reference
1.  Aberdeen Group, Inc.

• Parallels CEO Speaking This Week at SYS-CON's 4th International Virtualization Conference & Expo in Silicon Valley