Web Service Simulation Using Servlets Blog

Version 2


    The following background is prerequisite for complete understanding of this article:

    • basic knowledge about web service simulation
    • understanding of basic servlet technology concepts
    • basic understanding of XML

    See the Resources section for references on these technologies.


    Web service simulation is a growing need for every web service based assignment. Many of the assignments do not have the ready-to-use web service available during development stage, so the developers try to write their own mock implementation. A typical way of simulating a web service is:

    1. Using a bottom up approach, generate the artifacts from WSDL.
    2. Write the logic to choose the alternate response.
    3. Deploy to some server.

    This is a common mechanism for simulating each service, and this effort is repeated for each simulation. Suppose you have 1000 web services: you have to repeat these three steps 1000 times. However, these can be avoided by writing one servlet which accepts all soap input messages and generates the response file name using the message content. This way, there is no need to create a web service for each WSDL, resulting in lot of time and money savings. Let's look at the some common cons of the standard web service simulation approach.

    [Note: This article only provides conceptual knowledge. You need to do your own implementation.]

    Drawbacks of the common web service simulation approach

    As discussed in the introduction section, the standard three steps are typically repeated for each web service simulation. Buth this method has to the following drawbacks:

    1. Effort Repetition/Time consumed for the three steps
    2. Effort for defect resolution in simulation itself
    3. Deployment to servers (Generally, large projects have different environments, for example, Development, QA, etc). It also constitutes some effort

    Of course, these are not all the drawbacks. However, some common issues can be mitigated with clever design and simulation. In the next section, I will discuss one of the web service simulation design practices that can mitigate these issues.

    Web service simulation - designing using servlets

    Let's go into the basics of web services and soap envelopes. The intended message resides in the soap body and is based on the message/content of the body; the response from the file system is picked up and can be returned to the caller.

    This task simply can be achieved with servlets using following steps.

    1. Extract the soap envelop from input stream.
    2. Retrieve the first node of soap body.
    3. Apply the algorithm to generate the response file name using input message. (I'll discuss one of the algorithm in following sections).
    4. Read the response from file system.
    5. Prepare the soap envelop and send it to the caller

    Let's discuss the algorithm to generate file name using input message.

    Response File Name Generation algorithm

    Let's discuss the algorithm using one example: the input SOAP message as shown in Listing 1.

    Listing 1

     <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding" xmlns="http://abc.com"> <soap:body> <m:findPlace xmlns:m="PlaceFinder"> <placeName>redlands</placeName> <placeFinderOptions> <dataSource>Oracle</dataSource> <filterType>G</filterType> <searchType>Random</searchType> <fileterCountry>IN<fileterCountry> <startIndex>0<startIndex> <count>5<count> </placeFinderOptions> <token>TheToekn</token> </m:findPlace> </soap:body> </soap:Envelope>

    Note 1 - Expected response file to be picked from file system is findPlace_redlands_G.xml
    Note 2 - Careful observations of the soap envelope suggest that the expected response file name convention isfindPlace_ placeName_ filterType.xml

    Let's understand this convention:

    1. findPlace is the first local node name of the soap body
    2. placeName is the child of findPlace(its xpath is //m:findPlace/placeName)
    3. filterType is the child of the nodeplaceFinderOptions (its xpath is//m:findPlace/placeFinderOptions/filterType)

    Concatenating these three xpaths yields the expected response file name findPlace_redlands_G.xml. So, the crux of the algorithm is to use xpath to retrieve the node values and concatenate them. In the following section, I'll discuss the high level design & implementation to achieve this.

    Designing the fully configurable algorithm

    The heart of the idea is now how to achieve the above mentioned algorithm in a configurable manner so that there should not be any need to write any java code -- in other words 100% configurable and no deployment required for any change.

    To achieve this, let us define XSD/XML of the form as in Listing 2. It is just a sample XML and you can define your own XML structure. Of course, you will have to write your one time xml parser/processor to process this XML.

    Listing 2

     <cfg:entry servicename="PlaceHunt"> <cfg:method methodName="findPlace"> <cfg:component> <cfg:constant>findPlace</cfg:constant> <cfg:xpath dataType="string">//m:findPlace/placeName </cfg:xpath> </cfg:component> <cfg:component> <cfg:xpath dataType="string">//m:findPlace/placeFinderOptions/filterType</cfg:xpath> </cfg:xpath> </cfg:component> </cfg:method> </cfg:entry>

    Here is the basic defination of XML element and attribute used in Listing 2:

    • servicename - It is an attribute representing the name of the web service
    • methodName - It is an attribute representing the name of the method inside the webservice
    • cfg:constant - It specifies the constant value to be used for file name generation
    • cfg:xpath - Specify the Xpath to node whose value will be used as a part of file name

    Let's apply the algorithm using the Listing 2 XML.

    1. Web service client sends a request to simulation servlet (SayWebServiceSimulatorServlet)
    2. Web service simulator servlet extracts the first node from received soap body. This node is the actual web service message.
    3. WebServiceSimulatorServlet calls the FileNameGenerator component to generate the response file name (It is the component which actually implements the file name generation algorithm. You need to write your own component)
    4. FileNameGenerator uses the Listing 2 XML to generate the file name. It reads the XML, apply the xpath/xsl/etc on the input message received from servlet and concatenates the all values to generate the file name.
    5. FileNameGenerator returns the file name to theWebServiceSimulatorServlet.
    6. WebServiceSimulatorServlet reads the response from file system
    7. WebServiceSimulatorServlet prepares the soap envelop and returns it to the caller.


    The web service simulation has been achieved using a simple mechanism. During the journey key findings are:

    1. Servlet to simulate web service.
    2. Alter response file name generation logic can be done using simple XML logic.
    3. You need to write your own XML structure to achieve this. You can customize my XSD to accomplish your task.
    4. This logic needs to be developed once and afterwards there is no java coding is required. It's fully configurable which saves lot of effort, time and money.

    Let's follow some good design and save the effort, time and money. You can find a sample XSD design to make a configurable web service simulator.