Welcome!

SOA & WOA Authors: Elizabeth White, Kevin Nikkhoo, Liz McMillan, Jeremy Geelan, Pat Romanski

Related Topics: SOA & WOA, .NET

SOA & WOA: Article

Parasoft's SOAtest 3.0

Ensuring Acceptable Performance While Creating A .NET Web Service

Recently, a client asked me to create a new .NET Web Service that would let them do sales tax calculations from any computer on their network. The product they had been using was an old-fashioned C program meant for a single computer. They used to wrap this in a COM component and access it via traditional Active Server Pages, but now they wanted to migrate to fully managed code.

There were two reasons that I looked to SOAPtest to assure the quality of my newly constructed Web Service. On one hand, I had been working to inculcate a sense of quality craftsmanship in the development group at this client and wanted to demonstrate that creating unit tests for code could be fun and productive. On the other hand, the client was concerned that the new .NET Web Service would perform the same or better than its current ASP-based solution.

Installation was straightforward. It only took about five minutes and consisted mainly of an installation wizard where, in this case, I was able to accept all the defaults. The one thing I noticed immediately was that it asked me whether or not I wanted to install the Java Runtime Engine. In a product marketed to .NET developers, I thought that strange, but I accepted the default and it seemed to work fine.

After the install, I started up the application and was immediately prompted for my license information. I was automatically e-mailed this information by Parasoft's servers and it was easy enough to cut-and-paste it into place, however, I was a little disappointed that the license was tied to a specific machine. See, a week into my testing I had to relocate to a different machine and it forced me to ask for a different license.

Once I had provided my license, I was able to create my first set of unit tests in a little under 10 minutes. I particularly liked SOAPtest's ability to "remember" the results returned from a Web Service during a given run and use that as the basis for determining the accuracy of results returned later. For example, I set up a unit test to ask for the tax on a $10 sale of food in San Leandro, California. Once I got the initial results of 85 cents back, I told SOAPtest to remember that for future test runs. From this point on, not only would SOAPtest validate the shape of the responses returned to this test, but also the exact dollar value - with no coding on my part whatsoever!

Once I created my unit tests and verified the basic accuracy of the Web Services I created, my next task was to create Load Tests to prove to my client that my Web Services would exhibit acceptable performance. For this purpose, SOAPtest provides multiple kinds of Load Tests out-of-the-box.

  • Bell - increases the load until the middle of the test run, and then tapers it off. This is intended to simulate the typical flow of work in a business system during an average workday.
  • Buffer Test - alternates high and low loads. You should see the performance of your application go back to normal during the low loads, otherwise you probably aren't freeing up the resources properly.
  • Linear Increase - builds the load throughout the test.
  • Steady Load - maintains a constant load throughout the test.
Of all of these, I used the Buffer and Steady load tests since the Bell and Linear weren't useful in my particular circumstances. They generated excellent statistics and very easy-to-read graphs, as shown in Figure 1.

My only gripe with the Load Testing was that on my first run it showed that my Web Service generated a number of errors. Looking at the interface and paging through the documentation for about half-an-hour, I couldn't figure out how to go from the raw number of errors displayed to punch down into the actual error messages that were returned in each failure case. Ultimately I realized that I was running my Web Service on Windows XP and more concurrent users than XP's license allowed. Moving my Web Service to Windows Server 2003 solved the problem, but I still don't know how to punch down into the individual error messages.

In conclusion, I would say that if you are just writing one or two simple Web Services not intended for high-performance, complex, or interoperable tasks, you can probably get what you need for free by writing your tests with a tool like NUnit.

Given its amazingly rich feature set, however, SOAPtest is an absolute must-have for anyone who is doing truly advanced work with Web Services.

Company Information

Parasoft
401 E. Huntington Drive
Monrovia, CA 91016
Phone: (888) 305-0041
Fax: (626) 305-9048
Sales: info@parasoft.com

More Stories By Derek Ferguson

Derek Ferguson, founding editor and editor-in-chief of .Net Developer's Journal, is a noted technology expert and former Microsoft MVP.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Web Services Product Review 07/31/05 12:32:46 PM EDT

Parasoft's SOAPtest 3.0. Recently, a client asked me to create a new .NET Web Service that would let them do sales tax calculations from any computer on their network. The product they had been using was an old-fashioned C program meant for a single computer.