In-Depth

SOAP interoperability testing coming along

• By Johanna Ambrosio
• March 28, 2003

Fear not. Interoperability among different SOAP-based applications is coming to a Web service near you. But it will take a year or two to become reality.

A key group working in this area is the Web Services Interoperability Organization (WS-I), formed in February 2002. Its more than 100 vendors cover most of the industry's heavy hitters, including Microsoft Corp., IBM Corp., Hewlett-Packard Co. and Sun Microsystems Inc.

The WS-I is working in several areas. One is profiles, which are sets of Web services specifications that support specific types of applications. They typically include the core Web services specifications: XML Schema, SOAP, WSDL and UDDI. The organization is also working on sample implementations, guidelines for implementation and testing tools. These testing tools will take two forms: the first will monitor and log interactions with a Web service; the interactions are then placed in a file that can be analyzed. The second category consists of tools that process the interactions and make sure the Web service is error-free.

Several vendors are planning on incorporating the WS-I interoperability tests. IBM will do so in its WebSphere product line, said Arthur Ryman, IBM's development manager for Web services tools for WebSphere Studio.

Another vendor planning to do this is Mindreef LLC in Hollis, N.H., which will add the WS-I tests into its SOAPscope traffic-monitoring tool, said Jim Moskun, a company co-founder.

However the tests are ultimately provided, the interoperability piece is critical, and it is missing from today's Web services environment. "I don't think that people can take client interoperability for granted," said John Maughan, director of engineering at Cape Clear Software Inc., San Mateo, Calif. "It's not sufficient to define your Java client and assume your .NET client will work."

One of the key problems with interoperability today is that, even unwittingly, developers introduce platform-centric features into the Web services they create. "They expose only the .NET or Java concepts" that they are using, Maughan explained. "Most implementations today take the subset of a schema required by either a Java or .NET interface."

IBM's Ryman echoed this thought. "What we're seeing is that in the early phases, Web services is just another distributed computing technology. You'd create an object with business methods on it."

However, he said, that does not promote good interoperability. "There are differences in programming languages. If I start with a Java object, the way I map that object onto XML is going to allow certain aspects of Java to bleed through."

There is a difference between designing an object and designing a message, he said. So the goal is to start with describing a Web service -- but this is a document format, not an object, and will require developers to think differently. "It implies a different authoring style," Ryman said. "Over the next few years, we'll see developers learning how to deal with XML directly."

Further, Ryman explained that interoperability is really the only reason to use Web services at all. "If you didn't care about dissimilar platforms, all the existing platforms have distributed computing technology you can use -- RMI for Java, DCOM or CORBA for Windows, and so on," he said. "Within a closed system, all these protocols are fairly mature and efficient."

Plus, he said, Web services are more verbose than existing middleware implementations because they are based on XML, which is a textual system rather than a binary representation. So the Web services messages are fatter and require more bandwidth and time to parse.

"There are penalties" to a Web services implementation, Ryman said, "but the payoff is interoperability. If you don't have interoperability, you have the worst of all worlds."

Please read the associated article "SOAP testing easier said than done" by Johanna Ambrosio.