Testing Web Services
As more enterprises embark on the path of turning enterprise applications into Web services, development teams are finding it increasingly difficult to assure the quality of those services. Building and maintaining Web services is a very different prospect than for traditional applications. Certainly the code inside individual services is developed and tested in similar ways, but Web services are more about the interactions than among code components than they are about what goes on inside those components.
This requires new rules, and new tools to make and enforce those rules. I found both in ample evidence in the offices of Mindreef (www.mindreef.com), a web services testing vendor exploring new ways to define quality in the lifecycle of Web services. Mindreef started with a product called SOAPScope, a single-user debugger for SOAP packets. This was largely Java-based and was a natural way for doing basic debugging on communication between Java Web services.
Today, the company has significantly expanded its offering, delivering SOAPScope Server (try saying that three times fast), for team-based Web service quality. SOAPScope Server provides a Web-based interface for teams from business analysts to developers to partners. SOAPScope Server is a portal that is more agnostic about the nature of Web services, focusing on testing the WSDL and underlying supporting schema.
There are two ways to use SOAPScope Server. One is as a decidedly nontechnical user, who can perform basic testing of interfaces by entering data into an abstraction of the WSDL and ensuring that the proper values are returned. The product also serves as a type of collaboration platform, where users can exchange notes based on testing results and fixes put into place.
Developers have a higher level of access to schema, SOAP packets, and other technical details of the services. If necessary, they can examine both WSDL and schema to perform detailed analysis of interfaces. They can also create stubs of services to behave in an expected way in order to test other services. In other words, you can design an interface to give a certain output based on a given input, and without writing any code. This by itself can significantly improve the ability to test services in an SOA.
There are several challenges in moving ahead with a server-based platform, according to founder and president Frank Grossman. Probably the biggest is how to integrate into an enterprise environment that may involve multiple project groups, users, QA groups, and even teams from different business partners. These challenges involve both getting the collaboration model right, and getting the technology right so that all of these disparate participants can get access to the information they need. Once that occurs, however, SOAPScope Server is very well positioned to offer Web service quality features in a Software as a Service package.
Most enterprises that have made a strong commitment to Web services and SOA realize that the problems of quality are very real, but they are also very different than in the past. Traditional testing tools might be able to help assure the quality of individual Web services, but they don't get you very far in looking at a collection of interacting services. And this collection is what comprises your application. SOAPScope Server is a first attempt at true testing of an SOA in a collaborative environment.
Posted by Peter Varhol on 07/14/2006