Author : Varun Garg

Web Service Virtualization

By : Varun Garg

Virtual
The word ‘virtual’ refers to a physical item/software/hardware component which is not real but exists
only for mocking up the behavior of the real component during certain well defined scenarios.

Virtualization
Virtualization is a technique using which we can create a virtual component by mocking up the behavior
of real component.

Types of Virtualization
Below is a list of most communly used virtualization types.

• Server Virtualization
• Desktop Virtualization
• Hardware Virtualization
• Database Virtualization
• OS Virtualization
• Web Service Virtualization

Web Service
Web service in simple terms refers to a business logic which can be called over a network and any
person having the access to that particular network can call that business logic and got the work done.
The person who calls the web service is called ‘client’ and the hardware on which that business logic
resides is called ‘server’.

The client sends a request over the network to the server. In return, the server sends back the
appropriate response back to the client.

Request
Client Server
Response

1
 Author : Varun Garg

Web Service Virtualization

Web service virtualization is the technique for creating a web service which imitate the actual web
service only during certain pre-defined scenarios. Virtual web service are usually deployed on a local
LISA Server which is easier to access and maintain.

Normal Scenario

Request
Client Server
Response

Virtualization Scenario

Request
Client LISA Server
Response

Represents connection to a virtual service

Represents a virtual service

Areas of Application for Virtualization

Below is a list of scenarios for which web service virtualization is most commonly used:

• Unit Testing
• Functional Testing
• Performance Testing
• Development
• Interceptor Services
• Third Party Services

1. Unit Testing
Consider a scenario as drawn below:

Client Service A Service B

Service A Service is developed and ready for unit testing

Service B Service is still under development

In this scenario, we need to test Service A which is dependent on Service B. Service A is already
developed and needs to be unit tested, but Service B is still under development. So, due to the

2
 Author : Varun Garg

dependency of Service A on Service B, we can’t start the testing on Service A until the development and
testing on Service B is completed. Now we have 2 options to test Service A.

Option 1: Wait for Service B to be completely developed and then start the testing.
Option 2: Create a virtual service for Service B and point Service A towards virtual service of Service B.

If we opt for Option 1, then we have to wait till Service B is ready. This will delay the release cycle. But if
we go for Option 2, then we can quickly create a virtual web service for Service B and point Service A to
hit virtual service of Service B, instead of original Service B. This will enable us to start the testing on
Service A even before Service B is made available to us.

Virtualized Scenario

Client Service A Service B

Service B’

Represents connection to a virtual service

Represents a virtual service
Service B’ Represents virtual service for Service B

Benefits for Unit Testing Virtualization

• Faster Release Cycles
• Dependency Removal
• 24/7 availability as service is deployed on local LISA server.

2. Functional Testing
Consider a scenario as drawn below:

Client Service C Service D

Service C Service is developed and ready for functional testing

Service D Service is deployed in a production environment

In this scenario, we need to test Service C which is dependent on Service D. Service C is already
developed and needs to be functional tested, but Service D is deployed in a production environment.
For functional testing of Service C, we need a special type of response from Service D, which is usually
returned by Service D only during some special circumstances. For example, there is negative scenario in
functional testing of Service C for which we need Service D to be down.

3
 Author : Varun Garg

Now as Service D is deployed in a production environment, if we try to bring Service D down to test
Service C, then it will affect many live users which can in turn leads to a huge loss in revenue.

So, we can quickly create a virtual web service for Service D and point Service C to hit virtual service of
Service D, instead of original Service D. This will enable us to configure the response XMLs that we
require from Service D to perform the functional testing of Service C without even affecting the live
service in production environment. We can also make the virtual service down whenever it is required
as it deployed on our local LISA servers.

Virtualized Scenario

Client Service C Service D

Service D’

Represents connection to a virtual service

Represents a virtual service
Service D’ Represents virtual service for Service B

Benefits for Functional Testing Virtualization

• Dependency Removal
• 24/7 availability as service is deployed on local LISA server.
• Full control over the virtual service enables us to changes the response anytime we want.

3. Performance Testing
Consider a scenario as drawn below:

Client Service E Service F

Service E Service is developed and ready for performance testing

Service F Service is deployed in a production environment

In this scenario, we need to test Service E which is dependent on Service F. Service E is already
developed and needs to be performance tested, but Service F is deployed in a production environment.
If we start performance testing on Service E, then it will also put a huge load on Service F which results
in the delayed response to the users of Service F. This might also result in the failure of Service F which
means Service F will go down and becomes unavailable to the users resulting in the huge loss in
revenue.

4
 Author : Varun Garg

As an alternative, we can setup a dedicated PTEST environment for Service F and then perform the
performance testing of Service E. But for this we need to setup dedicated servers on which we can
deploy Service F for performance testing. But this will require huge investments to setup dedicated
servers.

So, we can create a virtual service for Service F and point Service E to hit virtual service of Service F,
instead of original Service F. This will enable us to put as much load on the virtual service as we want as
the service is deployed on our local LISA servers and it will not affect the service deployed in the
production environment.

Virtualized Scenario

Client Service E Service F

Service F’

Represents connection to a virtual service

Represents a virtual service
Service F’ Represents virtual service for Service B

Benefits for Performance Testing Virtualization

• Dependency Removal
• 24/7 availability as service is deployed on local LISA server.
• Cost Saving as we don’t need to setup dedicated servers.

4. Development
Consider a scenario as drawn below:

Client GUI Service G

GUI GUI needs to be developed

Service G Service is still under development

In this scenario, we need to develop GUI which is dependent on Service G which is also under
development. So, due to the dependency of GUI on Service G, we can’t start the development of GUI
until the development and testing on Service G is completed. Now we have 2 options to develop GUI.

Option 1: Wait for Service G to be completely developed and then start development of GUI.
Option 2: Create a virtual service for Service G and point the GUI towards virtual service of Service G.

5
 Author : Varun Garg

If we opt for Option 1, then we have to wait till Service G is ready. This will delay the release cycle. But if
we go for Option 2, then we can quickly create a virtual web service for Service G and point the GUI to
hit virtual service of Service G, instead of original Service G. This will enable us to start the development
of GUI much before Service G is made available to us.

Client GUI Service G

Service G’

Represents connection to a virtual service

Represents a virtual service
Service G’ Represents virtual service for Service G

Benefits for Develpment Virtualization

• Dependency Removal
• 24/7 availability as service is deployed on local LISA server.
• Faster release cycle as the development of GUI and web service happens in parallel.

5. Interceptor Service
Consider a scenario as drawn below:

REST/HTTP SOAP/HTTP

Client Service H Service I

Service H Service converts request/response from REST/HTTP to SOAP/HTTP and vice versa.
Service I Service provides the business logic

In this scenario, we need to test Service H to verify if this service is correctly converting REST request to
SOAP request and SOAP response to REST response.

To test Service H, we need to get the SOAP request which Service H is sending to Service I and SOAP
response which Service I is sending back to Service H. We then need to compare these SOAP request
and response with the corresponding REST request and response.

For this, we can create a virtual service and insert it between Service H and Service I. This virtual service
will capture SOAP request from Service H and pass it to Service I. Also it captures the SOAP response

6
 Author : Varun Garg

from Service I and pass it to Service H. This service will then save these captured request and response
in a LAN location from which the client can get the SOAP request and response and perform the testing.

REST/HTTP SOAP/HTTP SOAP/HTTP

Virtual
Client Service H Service I
Service

Benefits for Interceptor Service Virtualization

• Reduces Complexity.
• 24/7 availability as service is deployed on local LISA server.
• Increases test coverage.

6. Third Party Service

Consider a scenario as drawn below:

Third Party
Client Service J
Service

In this scenario, we need to do the functional and performance testing on Service J.

For functional testing on Service J, we need to test some peculiar test cases, for which we need the
modifications in third party service which is very difficult and time consuming process.

For performance testing on Service J, we need to send thousands of transactions to third party service.
For third party services, we usually need to pay a fee to third party vendor for each transaction. So, if we
start doing the performance testing on Service J using live third party service, then we need to pay huge
amount to the third party vendor just for testing the service.

So, we can create a virtual service for third party service and use that service for both functional as well
as performance testing. As this service would be deployed on local LISA server, we can make any type of
changes in the virtual service for doing the functional testing on Service J. Also we can apply any amount
of load on virtual service to perform the performance testing on Service J and we don’t need to pay
anything extra for our testing.

7
 Author : Varun Garg

Third Party
Client Service J Service

Virtual Service

Represents connection to a virtual service

Represents a virtual service

Benefits for Interceptor Service Virtualization

• Cost Saving
• Full control over the service
• 24/7 availability
• Easy to maintain

Methods for creating virtual service

Below is a list of methods available with CA Lisa Workstation for creating virtual services:

• Using WSDL
• Using LISA Recorder Service
• Using request-response pairs

1. Using WSDL
This method is used when the actual service is still under development.

Requirements
WSDL file
Request XML
Response XML

Pros
A virtual service can be created even when the actual service is not available.

Cons
Have to manually configure all the tags in the service image.
Difficult when we have to deal with large XML files.

8
 Author : Varun Garg

2. Using LISA Recorder Service

This method is used when the actual service is available.

Requirements
Endpoint URL (of actual service)
WSDL file
Request XML
Response XML

Pros
East to configure as we need not configure each and every tag. All the tags will be configured
automatically while recording from the actual service.

Cons
The actual service needs to be up and running to use this method.

3. Using request-response pairs

This method is used when the actual service is available. In this method we prepare all the request and
response pairs that we need to configure in our virtual service and place them in a folder. Then the LISA
will pick up all the request response pairs from that folder and create the virtual service.

XML naming formats:

Request XML: <name>-req.txt or <name>-req.xml
Response XML : <name>-rsp.txt or <name>-rsp.xml

Requirements
Request XMLs
Response XMLs

Pros
All the requests and responses can be configured in one shot in the virtual service image.
Virtual service can be created even when the live service and WSDL file is not available.

Cons
The request and response xmls should be available with correct data.

9
 Author : Varun Garg

Components of Virtual Service

Virtual service has below components:

1. Virtual Service Image

• Request XMLs
• Response XMLs
• Think Time Specs
• Matching Style
• Match Script
• META transactions

2. Virtual Service Model

• Steps
• Filters
• Assertions
• JavaScript (if required)

1. Virtual Service Image

Service image is the component of virtual service which contains all the logic of virtual service. Below
are the various components of virtual service image:

• Request XMLs : Request XMLs are a part of service images. When the virtual service got any request
from a client, it will check if the request XML that the client sent is present in the virtual service
image or not. If the virtual service would be able to find a matching request, then the virtual service
would reply with the corresponding response.

• Response XMLs : Every request has a matching response XML present in the virtual service image. If
the virtual service is able to find a matching request XML in the virtual service image, then it replies
with the corresponding response XML present in the virtual service image.

• Think Time Specs : For each request/response pair, we have a think time specs value present in the
virtual service image. This value specifies the time (in ms) that after how much time the virtual
service should send the response back. This value will be used basically when we create a virtual
service for performance testing as we require the response from the virtual service exactly in the
same time as from the actual service.

• Match Styles : There are certain match styles according to which the virtual service would decide,
which is the correct request/response pair for a particular transaction/ There are three types of
match styles:

10
 Author : Varun Garg

a. Operation : In this match style, the virtual service only matches the operation name in the
request XML. If the operation name matches, then it will send back the corresponding
response.
b. Signature : In this match style, the virtual service matches the operation name and tag
names in the request XML. If all the things matches, then the virtual service will send back
the corresponding response.
c. Exact : In this match style, the virtual service matches the operation name, tag names and
tag values in the request XML. If all the three values match in the request XML, the virtual
service will send back the corresponding response XML.

• Match Script : This component is used when we want to create a complex logic to match the
request XML coming from the client with the request XML present in the virtual service. Match
script is nothing but a JavaScript code which we can provide for each request-response pair. If the
match script returns true, then the corresponding response will be sent back to the client, else the
virtual service will move on to the next request-response pair.

• META Transactions : Every virtual service image has META transactions field in it. When virtual
service receives a new request, it uses the match styles corresponding to each request-response
pairs to get the correct pair. But if virtual service get a request XML which doesn’t matches any
request XML present in the service image, then it picks up the response mentioned in the META
transaction and returns it back to the client.

2. Virtual Service Model

Service model is the component of virtual service which specifies the flow of request and response XMLs
through virtual service. Below are the various components of virtual service model:

• Steps : Steps here denotes the LISA steps. These steps are used to navigate the request XML and in
the process virtual service goes through different steps till it reaches the final Responder Step using
which the virtual service sends the response back to the client. The first step of each virtual service
is Listener step. Using this step, virtual service listens to the incoming requests coming from clients.
One of the main step used in the virtual service model is “VS Image Response Selection” step, using
which virtual service looks into the virtual service image to determine the correct response for a
particular request.

• Filters : Filters are very important part of virtual service models. By default virtual service model
uses a lot of filters for capturing different types of data. Also we can use custom filters if we want to
filter out any additional data from request/response.

• Assertions : Assertion can be used in virtual service models to include additional comparison logics
in our virtual service.

11
 Author : Varun Garg

• JavaScript : We can include JavaScript codes in our virtual service model using JavaScript step. We
can include any type of complex logic in our virtual service model using JavaScript.

Virtual Service Settings in VSE Dashboard

1. Execution Modes

• Most Efficient : In this execution mode, the virtual service will perform normally and look into
the service image for the request/response pairs.

• Transaction Tracking : In this execution mode, virtual service will behave exactly as the ‘Most
Efficient’ mode. The only difference is that the request and response will also be saved in the
LISA server for all the transactions, which can be used by virtual service developers for
debugging purposes.

• Live System : In this execution mode, the virtual service will not look into the virtual service
image but it will hit the actual service using the endpoint URL mentioned in the ‘Live Invication
Step’ of virtual service model.

2. Concurrent Capacity
This property denotes the number of request XMLs that our virtual service will be able to handle
simultaneously at any point of time. If there is a huge load on a particular virtual service, then we can
increase this value to address the requests faster.

3. Txn Count
This value denotes the number of transactions performed by our virtual service since last restart.

4. Error Count
This value denotes the number of errors that the virtual service has encountered since last restart.

5. Current Txn
This value denotes the number of transactions in the queue and waiting to be served.

6. Peak Txn
This value denotes the number of transactions that hit the virtual service simultaneously at any given
point of time.

12
 Author : Varun Garg

***********************************Disclaimer****************************************
This document is created by the author with the best of his knowledge. Author is not responsible for any
issues/losses occurred due to the contents provided in this document.
For any other comments/support, please contact author:

Author : Varun Garg

Email Address : varungarg455@gmail.com
Mobile No. : +91-7042932015
Website : http://calisautility.blogspot.com

*************************************************************************************

13