From time to time, we excerpt the definitive volume Service Virtualization: Reality is Overrated – How to Win the Innovation Race by Virtualizing Everything for some advice and basic explanations on how this transformational technology helps businesses develop software faster, better and cheaper. Today, we look at how Virtual Services are created, an excerpt from Chapter 5:
Creation of a Virtual Service
Service Virtualization creates an asset known as a Virtual Service (VS), which is a system-generated software object that contains the instructions for a plausible “conversation” between any two systems.
It is important that there must be real software automation involved in the capture and modeling of the Virtual Service. Otherwise we are still talking about the “stubs” developers would manually code and maintain on their own.
Let’s say your team is developing an update to a key application that must make requests of a downstream mainframe and a cloud-based partner service (SaaS). Both of those downstream systems are unavailable for you to use to run your regression and performance tests throughout development. So you replace them with Virtual Services and get to work. Think of the VS as a reliable stand-in for those constrained and costly applications that you don’t want to expose to the daily grind and dangers of being set up, used, and reset for testing and integration purposes by developers.
We will cover alternate ways to build virtual services, but the fundamental process works this way (see Figure 5-2):
- Capture: A “listener” is deployed wherever there is traffic or messages flowing between any two systems. Generally, the listener records data between the current version of the application under development and a downstream system that we seek to simulate.
- Model: Here the Service Virtualization solution takes the captured data and correlates it into a VS, which is a “conversation” of appropriate requests and responses that is plausible enough for use in development and testing. Sophisticated algorithms are employed to do this correctly.
- Simulate: The development team can now use the deployed Virtual Services on-demand as a stand-in for the downstream systems, which will respond to requests with appropriate data just as the real thing would, except with more predictable behaviors and much lower setup/teardown cost.
Remember, we say that a VS is “simulating” the constrained system for purposes of development and test, not “replaying” it in terms of a step-by-step sequence, as you would a recorded video. Sufficient dynamic logic must be captured and modeled into a VS to allow it to respond with enough intelligence to support the variability of needed usage scenarios. The VS should resemble the live system closely enough to make upstream applications and test users think that they are interacting with the real thing for most needed scenarios.