Introduction to Web Services Simulation with SOAPSimulator: a Hands-on Tutorial

Introduction

Typically, companies embark on SOA projects for system-to-system integration within their corporate domains, as well as with external trading partners. Reusable services are the cornerstone of a successful SOA implementation. In an SOA Project, once a producer service is built, developers can subsequently start implementing consumer services and testers can begin building test scenarios. If the producer service is under development and is not available for request-response interaction, development and QA teams are severely hampered in their ability to develop consumer code. Service simulation – the ability to mimic producer services even before they are implemented – enables consumer developers and testers to parallelize their efforts without having to wait for service implementation to complete. Service simulation also enables corporations to provide a portable alternative to building an expensive reference environment.

In this hands-on tutorial, we are going to learn service simulation techniques using SOAPSimulator™ from Crosscheck Networks.

Scenario and Setup Overview

The setup for this tutorial captures a real-life SOA development scenario where a producer web service has to be developed and deployed as shown in the figure below. A service, Factorial(int n), meant to compute the factorial of a number, n, is first designed. In this design phase, the interface stub of this service -- with clear inputs and outputs -- is defined in C# using .NET Web Matrix. The WSDL written or generated in the design phase is handed over to the testing team that imports this WSDL into SOAPSimulator used for service simulation. Through an easy-to-use, simple point-and-click interface, SOAPSimulator is configured for simulated SOAP request-response pairs. The simulation for the Factorial service is then started on port 8000, as show in the figure below.

At this stage, client-side development teams and testers can commence their assigned tasks. Using SOAPSonar™ from Crosscheck Networks as a client-side SOAP test tool, testers can create a number of test cases with SOAPSimulator as a target simulated service. Service simulation provides testers with the independence necessary to start building test cases, without having the real Factorial service available. Meanwhile, the development team is busy coding the Factorial service. As soon as the testers complete building their test cases in SOAPSonar, the developers announce that their Factorial service has been developed and is ready for testing. To the developers’ surprise, the test team is ready to test the service immediately by simply pointing the test cases to the Production version of their Factorial service, as shown in the last circle of the figure above. The efficiencies gained in using SOAPSimulator for service simulation are apparent, since the QA test case development is parallelized with the service development, providing considerable time and resource savings.

To build the SOA development scenario as described above, the following components are required:

1. Microsoft .NET Web Matrix: this installer includes and IDE for building web services and a lightweight web server. Download and install Web Matrix.

2. Web Services File: download and unzip this file. It contains Design-WS.asmx and Production-WS.asmx. The first file has the service stub for computing a factorial, but no implementation. The second file contains the implementation for computing the actual factorial number.

3. SOAPSimulator Download: download and install SOAPSimulator, a service simulation product. This install also contains a lightweight SOAPSonar client-testing tool.

Components can be installed on a Windows 2000/XP/Vista machine with moderate resources. We will now follow STEPS 1-5 to build the scenario described above.

Step 1: Load Design-Time Service Stub in Web Matrix

In the first step of this tutorial, we will load a C# program that is being developed using .NET Web Matrix, which we had installed earlier. The service, Factorial(int n), is to be developed to calculate the factorial of a number. However, only the service stub has been designed so far that simply returns the value of the input integer, n. To load the service into Web Matrix, perform the following tasks:

1. Goto: Start > All Programs > Microsoft ASP .NET Web Matrix > ASP .NET Web Matrix.

2. You will be prompted with a screen. Hit Cancel.

3. Goto: File > Open File and select Design-WS.asmx. You will see the following C# code within the Web Matrix environment:

4. Hit the start button in Web Matrix to run the web service. As shown in the figure below, you will be prompted to start the application on port 80. You can change the port if that port is already taken on your machine. Make sure that your local firewall is turned off.

   

5. A web browser with the operation name Factorial will appear. You can click on the operation name and start experimenting with this web service that simply echoes the input value.

At the end of STEP 1, you have .NET Web Matrix up and running with the Design-WS.asmx web service that can be invoked from a browser.

Step 2: Load Design-Time WSDL into SOAPSimulator

In the second step of this tutorial, we will load the WSDL associated with the design-time service we loaded into Web Matrix in STEP 1. In subsequent steps, we will use SOAPSimulator to build a service simulation based on the design-time WSDL file. To load the WSDL into SOAPSimulator, perform the following tasks:

1. Goto: Start > All Programs > Crosscheck Networks > SOAPSimulator > SOAPSimulator.

2. Type http://localhost:80/Design-WS.asmx?WSDL in the Capture WSDL field. Note that the WSDL is retrieved from port 80 of the Web Matrix server. If Web Matrix is listening on a different port, then that port needs to be entered instead of port 80. The figure below illustrates the WSDL import screen in SOAPSimulator:

   

3. Change the default port from 80 to 8000. You can hit the Test Port Availability button to check if the port is available for SOAPSimulator to listen on. Hit the commit button to save your changes.

At the end of STEP 2, you have loaded the WSDL that you are about to simulate in SOAPSimulator and have configured the listener that the client (consumer) application, SOAPSonar, is going to use to invoke the Factorial service.

Step 3: Configure SOAP Request-Response Pairs in SOAPSimulator

In the third step of this tutorial, we will configure SOAPSimulator to look for a SOAP request and return a SOAP response. This is where we will define criteria for the incoming request and map it to an out-going response. Perform the following tasks to set the request-response pairs in SOAPSimulator:

1. Click on the Project Tree in the left Navigation Panel and select the Factorial_1 simulation as shown in the figure below. Enter a value 5 under the tree node n. Hit the commit button to save your changes.

   

2. Click on the Response Definition in the right panel and enter a value of 120 in the FactorialResult field. This is the factorial result for the request value of n=5. Hit the commit button to save your changes.

   

3. Right-click on Factorial_1 in the Project Tree and select Clone from the menu, as shown below. You can now set a second request-response pair, Factiorial_2, with sample values such as n=6 and FactorialResult=720. Hit the commit button to save your changes.

   

At the end of STEP 3, you set request and response values for within SOAPSimulator and have learned how to rapidly clone simulations to build additional request-response pairs. You are now ready to run your simulations.

Step 4: Run Simulations

In the fourth step of this tutorial, we will run SOAPSimulator and send requests to it using SOAPSonar, which will act as a client. Perform the tasks listed below to run the simulation that you have just authored:

1. Click on the Start Simulation button to start the simulation. The Simulation Control will appear as shown in the figure below. SOAPSimulator is now ready to take input values and will display request-response statistics.

   

2. Goto: Start > All Programs > Crosscheck Networks > SOAPSonar Personal Edition 3 > SOAPSonar to start SOAPSonar, which will act as a web services client and send request to SOAPSimulator.

   

3. Type http://localhost:8000/Design-WS.asmx?WSDL in the Capture WSDL field of SOAPSonar, as in the figure below. Note that the port is set to 8000 and that the WSDL is being retrieved from the SOAPSimulator listener, not Web Matrix.

4. Select Factorial_1 in the Project Tree displayed above and enter n=5. Click on the Send Current Request to Server button to send the SOAP request to SOAPSimulator. As expected, a value of 120 is returned, as shown in the Response panel above. Right click on Factorial_1 and select Clone to add test cases Factorial_2 and Factorial_3. Set the additional values of n=6 and n=10 for the test cases respectively. Other than n=5 and n=6, all values sent to SOAPSimulator will trigger a failure. Review the statistics in the SOAPSimulator Simulation Control to check for Pass/Fail request-response pairs. Click on the Transaction tab to review transaction details.

At the end of STEP 4, you have successfully run multiple simulations using SOAPSimulator and evaluated the SOAP request–response pairs in the Simulation Control tab.

Step 5: Load & Run Production Services

In the fifth and final step of this tutorial, we will use the test cases authored in SOAPSonar and now point the test case created to run against a production service called Production-WS.asmx. When the test cases with request values of n=5, n=6, and n=10 were run against SOAPSimulator, the first 2 values Passed. However, the third value Failed since a simulation was not authored for n=10. When the test cases are executed against a production system that is actually calculating the factorial values and not just simulating them, a computed response of FactorialResult=3628800 is returned. Perform the following tasks in SOAPSonar to point the test cases to the production system:

1. As shown below, in the Request panel adjacent to the Send Current Request to Server button in the URI field, change the value to http://localhost:80/Production-WS.asmx. This points the SOAPSonar test cases to production services where the Factorial(int n) service is code-complete, performing real factorial computations instead of returning a set value as in the case of SOAPSimulator. If Web Matrix is listening on a different port, then that port needs to be entered instead of port 80.

   

2. Run each test case by hitting the Send Current Request to Server button. As expected, all test cases return values verifying that the production service is indeed computing factorial values. You can change values or add more test cases to check the production service.

At the end of STEP 5, you have successfully run multiple transactions against a fully functional production service that computes factorial values. Test cases that you authored did not require the service to be available or complete since the test authoring process was performed against SOAPSimulator, which mimicked the actual service for a number of SOAP request-response pairs.

Conclusion

The success of a SOA deployment is measured by how cost-effectively it solves a pressing business problem by either cutting costs or generating new revenue for an enterprise. The cost-effectiveness of an SOA deployment is driven through reuse of services and the ease with which the services can be integrated to form composite applications. The interdependencies that result from the re-use premise of an SOA deployment means that a web services consumer has to wait for a producer service to be ready and available. The consumer-producer model inherent to SOA means that consumer developer and testers can be held up by delays in producer service availability or accessibility. Providing an alternate set of mimicked services through service simulation can eliminate these hurdles.

In the article, we learned how to rapidly set up simulated services through SOAPSimulator. We built test cases that did not change and were authored independently of the production service. Once the services we complete, the test cases were then used to test the production service. The test case development task was parallelized with the service development. Such parallel development can yield significant efficiencies within an SOA development effort.

About Crosscheck Networks

Crosscheck Networks’ mission is to provide products for testing, scanning and simulating enterprise Web Services. Crosscheck Networks’ products provide QA professionals, security personnel, and compliance officers with necessary information about the functional completeness, scalability, security and interoperability compliance of their Service Oriented Architecture (SOA). Through SOAPSonar and SOAPSimulator - industry leading comprehensive SOA testing products - IT professionals make more informed decisions that enable their companies to stay within corporate quality and regulatory boundaries. SOAPSimulator is an industry-first, easy-to-use, standalone web services simulator that can be deployed on a desktop or a server for simulating services that are inaccessible or unavailable. SOAPSimulator also provides a “reference system-in-a-box” that eliminates redundant IT infrastructure. SOAPSimulator is ideal for enterprises serious about governing their SOA by quantifying and measuring best practices. Visit Crosscheck Networks now.