Thanks to the IT world's ongoing love affair with Web services and the appearance of more and more Web-service construction tools, Web services are becoming easy to create -- and oh so easy to botch.

A Web service is, after all, a collection of procedures exposed to the unforgiving thoroughfare of the Net (be it inter- or intra-). And a failed Web service invites wrath not only from the managers and administrators who monitor and maintain the server's well-being, but from the clients who have called your Web service. Get your Web service right, or get two earfuls of complaints.

In this roundup, I examined three tools that purport to verify that your Web services do what they are supposed to do, that they resist graceless failure, and (in some cases) that they conduct themselves with efficiency. The tools are soapUI, TestMaker, and WebInject. All are open source, and are available for free download and incorporation into your next Web services project.

I will note one thing: you need to have a good understanding of SOAP and HTTP protocols to use these tools. One might say that one should have that regardless of what tool you're using, but some commercial products offer a helping hand with a "pseudocode" translation of SOAP code. It helps both neophyte and experienced SOAP users understand what's going on in a particular SOAP request or respond block by translating to difficult-to-read XML into easier-to-read pseudocode. These three open-source Web service testing tools require a little more work, and I would recommend them for moderate-to-expert developers, where the learning curve would be only modestly longer than for a commercial product.

soapUI1.6
I reviewed Version 1.6 of soapUI, a Java-based tool from Eviware. This version executes within its own stand-alone UI; the new 1.7 release includes plug-ins for the NetBeans, IntelliJ, and Eclipse IDEs.

Click for larger view.

The user interface conforms to the architecture of the typical IDE: a navigation pane on the left, a content pane on the right, and additional properties panes tucked near the bottom. If you've used an IDE like Visual Studio lately, you'll find your way around soapUI instantly.

soapUI arranges work into projects. Each project is primarily identified by the interfaces that the project is built to test. Here, an interface is the “other end” of a URI (uniform resource identifier) pointing to a site that is exposing Web service methods. You can quickly generate a skeletal project by aiming an empty project at a Web service's WSDL code; soapUI will accept WSDL from either a file or a Web service end point that transmits the WSDL for its services.

Projects are arranged hierarchically and contain one or more TestSuites, which contain one or more TestCases, which in turn contain one or more test steps. The actual work – sending requests, receiving responses, analyzing results, and altering test execution flow – happens at the test step level. TestCases gather and organize the steps need to perform a specific operation on the target. TestSuites gather TestCases into larger aggregates that exercise a particular area of a Web service (such as the operations necessary to order a book). You can create new TestSuites, TestCases, and test steps by right-clicking on the parent node in the project's tree and selecting New from the pop-up context menu.