The Consumer of the Service Should Build the Virtual Service

Blog Post created by Mike_Gavaghan Employee on Nov 7, 2017

Let’s start with a common scenario that’s probably happened to you more than once. Suppose one of your teams is building an order entry web service and another is building a UI that depends on that web service. The order entry service won’t be available for several months because it’s under development, but the UI team wants to begin work now.


Before Service Virtualization, you’d be out of luck. But now, you have the opportunity to move forward with both by virtualizing the order entry service and achieving parallel development between the UI and server teams.


But, who should be responsible for the virtualization?


Many teams are inclined to make the server team complete the virtualization. After all, they’re building the real system, so they know it best, right?


In a proper service oriented environment, the server team doesn’t necessarily know – or care – who its clients are.


Hence, they have no idea what portion of their behavior is consumed by each client, nor do they know the test cases or data requirements of each client.


They’d have to resort to building a service that can respond to any ad hoc request. This will result in an unnecessarily complex and costly-to-maintain virtual service, much like the one I dealt with in “Create the Service that Meets Your Team’s Needs.”


A Better Approach

Each consumer of the service must be responsible for creating her own, independent virtual service models that meet their specific testing needs – and nothing more. This means creating virtual services that are cheap and easy to build and maintain.


It also means the service developers must work closely with the client system developers to understand how the client interacts with the server. It can sometimes be challenging to get sufficient insight this way, but transaction recording, when possible, can help illuminate the back end calls that are invoked.


Although there may be some overlapping requirements between client teams, trying to accommodate all the needs into a single, combined model is seldom advisable. The idea of virtualization, of course, is to eliminate constraints. This is achieved by preventing one team from being held up by a dependence on another.