User:CodeCurmudgeon/sandbox

In software engineering, service virtualization is a means of separating computer functionality from direct hardware dependencies called virtualization. Hardware virtualization hides the physical characteristics of a computing platform from the users. This reduces costs, is more efficient, and make it easy to scale applications by easily adding more processors, memory, and storage without interrupting service. Service virtualization takes the concept one step further by isolating specific tasks and services rather than a complete computer. Software developers can then use the services as "building blocks that can be assembled and reassembled to adapt to changing business needs". This allows the virtual services to be less tightly coupled to the underlying system making them easy to replicate, share, and scale as needed without regard to having to first install specific hardware.
 * first sentence needs to be short and punchy, before we dive into the nitty gritty. It's what will appear in standard google search. "means make version, often used for testing, not mocks"

Service virtualization is also a technique used for software testing that similarly isolates the component being tested from dependent components so that tests can be run without having all systems available, before all components are finished, or without having effect on real data or systems. Service virtualization is often confused with mocking but differs in that virtual assets are capable of stateful behavior allowing them to be much more realistic and less susceptible to problems as the code being tested changes.

Overview

 * explain both things uses


 * ONE
 * "...applications are encapsulated as services and a distribution framework is sued to disseminate work across service instances. Service virtualization also allows the application developers to :treat services from different application domains as building blocks that can be assembled and reassembled to adapt to changing business needs"


 * TWO
 * "one of the most common barriers to service virtualization adoption is the confusion between stubbing/mocking and service virtualization. It is common to see developers resist service virtualization use because they believe that this type of work is already achieved through stubbing and mocking."
 * and
 * "From a testing perspective, stubs and mocks make the test suite ignore unavailable components. In doing so, vital components are left out of testing and may not be tested in the aggregate until a final end-to-end test prior to going live"
 * from

In software engineering, service virtualization is a method to emulate the behavior of specific components in heterogeneous component-based applications such as API-driven applications, cloud-based applications and service-oriented architectures. It can be used for software testing to provide software development and QA/testing teams access to dependent system components that are needed to exercise an application under test (AUT), but are unavailable or difficult-to-access for development and testing purposes. With the behavior of the dependent components "virtualized", testing and development can proceed without accessing the actual live components. Service virtualization is recognized by vendors, industry analysts, and industry publications as being different than mocking.
 * OLD STUFF BELOW

Reasons for virtualization
In deployment SV is used for blah blah blah
 * the hardware virtualization page uses this section, probably a good idea to do this the same way - stuff rationale here. probably see grid2 ref

In testing service virtualization mimics the behavior of software components to remove dependency constraints on development and testing teams. Such constraints occur in complex, interdependent environments when a component connected to the application under test is:
 * Not yet completed
 * Still evolving
 * Controlled by a third-party or partner
 * Available for testing only in limited capacity or at inconvenient times
 * Difficult to provision or configure in a test environment
 * Needed for simultaneous access by different teams with varied test data setup and other requirements
 * Restricted or costly to use for load and performance testing

Use for testing

 * SV for testing takes SV one step further with (simulation|emulation) instead of just the virtualization piece
 * maybe explain the emulation/simulation confusion and the answer "talks like" instead... do we have ANY ref for that explanation (other than my own presentations) meeting WP:RS?

Although the term "service virtualization" reflects the technique's initial focus on virtualizing web services, service virtualization extends across all aspects of composite applications: services, databases, mainframes, ESBs, and other components that communicate using common messaging protocols.

Service virtualization emulates only the behavior of the specific dependent components that developers or testers need to exercise in order to complete their end-to-end transactions. Rather than virtualizing entire systems, it virtualizes only specific slices of dependent behavior critical to the execution of development and testing tasks. This provides just enough application logic so that the developers or testers get what they need without having to wait for the actual service to be completed and readily available. For instance, instead of virtualizing an entire database (and performing all associated test data management as well as setting up the database for every test session), you monitor how the application interacts with the database, then you emulate the related database behavior (the SQL queries that are passed to the database, the corresponding result sets that are returned, and so forth).

Application
Service virtualization involves creating and deploying a "virtual asset" that simulates the behavior of a real component which is required to exercise the application under test, but is difficult or impossible to access for development and testing purposes.

A virtual asset stands in for a dependent component by listening for requests and returning an appropriate response—with the appropriate performance. For a database, this might involve listening for a SQL statement, then returning data source rows. For a web service, this might involve listening for an XML message over HTTP, JMS, or MQ, then returning another XML message. The virtual asset's functionality and performance might reflect the actual functionality/performance of the dependent component, or it might simulate exceptional conditions (such as extreme loads or error conditions) to determine how the application under test responds under those circumstances.

Virtual assets are typically created by:
 * rewrite as narrative rather than list
 * Recording live communication among components as the system is exercised from the application under test (AUT)
 * Providing logs representing historical communication among components
 * Analyzing service interface specifications (such as a WSDL)
 * Defining the behavior manually with various interface controls and data source values

They are then further configured to represent specific data, functionality, and response times.

Virtual assets are deployed locally or in the cloud (public or private). With development/test environments configured to use the virtual assets in place of dependent components, developers or testers can then exercise the application they are working on without having to wait for the dependent components to be completed or readily accessible.

Industry analysts report that service virtualization is best suited for "IT shops with significant experience with 'skipping' integration testing due to 'dependent software', and with a reasonably sophisticated test harness.

Relation to stubbing and mocking
Service virtualization is recognized by vendors, industry analysts, and industry publications as being different than mocking.
 * CLEANUP


 * "one of the most common barriers to service virtualization adoption is the confusion between stubbing/mocking and service virtualization. It is common to see developers resist service virtualization use because they believe that this type of work is already achieved through stubbing and mocking."
 * and
 * "From a testing perspective, stubs and mocks make the test suite ignore unavailable components. In doing so, vital components are left out of testing and may not be tested in the aggregate until a final end-to-end test prior to going live"
 * and
 * "Service virtualization, unlike stubbing and mocking, allows for a “stateful” component. A stateful component means that the virtualized asset is capable of storing the interaction and triggering the interaction with other components or virtualized assets." etc.

An alternative approach to working around the test environment access constraints outlined in this article's introduction is for team members to develop method stubs or mock objects that substitute for dependent resources. The shortcoming of this approach became apparent in the early 2000s with the rise of Service-oriented architecture. The proliferation of Composite applications that rely on numerous dependent services, plus the rise of Agile software development following the 2001 publication of the Agile Manifesto, made it increasingly difficult for developers or testers to manually develop the number, scope, and complexity of stubs or mocks required to complete development and testing tasks for modern enterprise application development.

The first step in the evolution from stubbing to service virtualization was the technology packaged in SOA testing tools since 2002. The earliest implementations of service virtualization were designed to automate the process of developing simple stub-like emulations so that composite applications could be tested more efficiently. As enterprise systems continued to grow increasingly complex and distributed, software tool vendors shifted focus from stubbing to the more environment-focused service virtualization. While stubbing can still be completed through manual development and management of stubs, what has become known as "service virtualization" is completed by using one of the available commercial off the shelf (COTS) service virtualization technologies as a platform for the development and deployment of their "service virtualization assets".