SOAP is the currency of the SOA marketplace -- for now, anyway. Though SOAP's significance may diminish as Web services evolve, its importance for the time being is unquestionable. Therefore, a substantial portion of the QA work by Web service providers and consumers must entail verifying the accurate exchange of SOAP messages. Not surprisingly, several SOAP-focused Web service testing tools have appeared.

I had an opportunity to look a five such tools: AdventNet's QEngine, Crosscheck Networks SOAPSonar, iTKO's LISA, Mindreef's SOAPscope Server, and Parasoft's SOAtest. Readers of my earlier reviews of open source Web service testing apps will recall that those products required a relatively technical command of XML, SOAP, and WSDL (Web Service Definition Language). That is less a requirement with these tools; virtually all provide a user-friendly means of manipulating SOAP request-and-response data in ways that insulate the user from hands-on XML work.

Fundamentally, testing a SOAP-based Web service involves three activities: constructing a SOAP request, submitting it, and evaluating the response. As easy as that sounds, it is anything but. An effective SOAP-testing tool cannot simply rely on a user-friendly mechanism for building requests. It must also enable the user to organize and arrange requests in realistic sequences, provide a means of altering request input values, and intelligently tweak requests so as to expose the Web service to a range of good and bad usage scenarios. In short, you want the tool to run the Web service through a reasonable approximation of real-world activity.

In addition, the tool must be equipped with a collection of gadgets for evaluating responses. Such gadgets should include everything from simple string matching to executing an arbitrarily complex XQuery on the SOAP payload.

All of the tools reviewed here provide variations on the preceding capabilities. All make valiant attempts to shield the user from direct exposure to XML, and some keep users entirely in a protective GUI so that coding is never necessary. Meanwhile, most of the tools supply "authorized personnel only" doorways into more advanced testing functions that involve scripting, feeding request data from databases, parsing and filtering results, and so on.

Most also provide conformance verification of the format of SOAP messages and Web service WSDL files to the growing list of Web-service related standards and specifications -- primarily the profiles from the Web Services Interoperability Organization (WS-I) and the WS-* specifications from the likes of OASIS and others. Some also offer load-testing capabilities so that you can unleash a squad of virtual clients on the Web service and measure its response to the increased traffic. Some take a "holistic" approach to Web service testing, recognizing that SOAP-based Web services are not the only form of service being presented on the Web.

The offerings are complex, and each could support an entire review on its own. I've done my best to cover the distinguishing features of each tool. You should consult the associated comparison matrix for a high-level glimpse of some of the more important characteristics.

AdventNet QEngine

QEngine's UI is a browser, which means that when you launch the tool, you're really launching an application server. In this case, the application server is Tomcat, which also fires up an instance of MySQL server for the tool's data storage system. QEngine tries to mitigate the inconveniences of running in a browser by installing the QEngine toolbar browser plug-in, which adds buttons that make it easier to control the QEngine system.

Logging into QEngine ushers you into the suite manager screen. From there, you can either create or import a new test suite, or choose to work with an existing suite. If you choose the latter, a dialog materializes, giving you the option to work on Web functionality, Web performance, Web services functionality, or Web services performance. In other words, a single suite can host up to four categories of tests, and these categories are never really aware of one another. So, for example, if you're doing Web functionality test work, you don't see the Web services performance tests within that same suite. This takes some getting used to.

Scripts perform actual test execution. When you add a new Web service to a test suite, QEngine queries the Web service's WSDL and from that generates a set of basic test scripts -- one for each Web method on the service. Select a script from a suite's explorer tree, and the generated source code appears in an editor window. QEngine's scripts are written in Jython, the implementation of the Python language that executes in a Java virtual machine.

The prebuilt test scripts are extremely spartan; you have to flesh them out for them to be useful. This is a two-step process. First, you supply the content of the requests using a pair of menu selections: DataSet Configuration and Parameterization. Dataset Configuration lets you set the sources of your input data as either a database (QEngine supports Oracle, SQL Server, or MySQL) or a CSV file. After you've configured your datasets, choose Parameterization and you can set specific input values to be supplied either by the dataset you just configured or by manually entered values.