In the past, communications between software systems, especially those between two or more different organizations, has often been cobbled together with a variety of ad-hoc methods and proprietary protocols. This approach to integrating software is often difficult, expensive and time-consuming, especially when the number of connections the organizations have to support increase.

One of the key goals of the web services movement has been to develop a set of universally-supported protocols that enable "snap-together" system-to-system communication on a much larger scale than in the past. SOAP is one such protocol; it defines an XML-based encoding and enveloping standard for system-to-system communication.

To date, over 50 SOAP toolkits have appeared since the first introduction of this specification, and the number continues to grow. The quantity and diversity of the toolkits highlight how quickly the computing community has embraced SOAP. However, the full value of SOAP can only be realized if interoperability between toolkits is ensured.

In this article, I will look at some of the challenges that toolkit implementers have faced on the SOAP interoperability front, and how the community has worked together to overcome some of these challenges. I will also examine a case study of a situation where improved interoperability environment was clearly illustrated.

The interoperability challenge

Applications use SOAP toolkits (usually in the form of libraries) to prepare XML-based SOAP envelopes, send the envelopes over a transport protocol such as HTTP or SMTP, and process incoming SOAP envelopes. If two SOAP toolkits make different assumptions about how to build and interpret envelopes, interoperability problems may occur.

For example:

• One or both of the SOAP toolkits might implement only a subset of the full SOAP or XML specifications. In some cases, there may be a mismatch in what features are supported, where one system sends a SOAP document that the other cannot process.
• The SOAP specification makes certain things optional -- for instance, the SOAP specification makes it optional to send type information for encoded parameters . If one implementation assumes that type information will exist on messages it receives, it may not interoperate with another implementation that chooses not to send that information.
• Two implementers may interpret parts of the SOAP specification differently, where the language of the specification is ambiguous.

Finally, implementers may simply have bugs in their toolkits that that do not show up during stand-alone testing. Such bugs may also contribute to interoperability problems when two different toolkits attempt to hook together.

Back to top

The solution: communication and testing

To help address these issues and to promote SOAP interoperability in general, the SOAPBuilders online group was created. The participants in the SOAPBuilders group are a diverse set, from very large corporations such as IBM and Microsoft, to individuals with their own open-source toolkits. To increase communication and provide opportunities for cross-toolkit testing, the SOAPBuilders group provides the toolkit implementer community with:

• A mailing list that acts as a forum for discussion of implementation and interoperability issues
• An interoperability test suite specification
• A directory of test server endpoints
• Links to testing results

The SOAPBuilders Interoperability Lab (ILAB) exists to support the above needs of interoperability testing. You can find out more about the the ILAB from the link in the Resources section.

Back to top

The SOAPBuilders test suite

At the heart of the activities on the list is the SOAPBuilders Interoperability test suite. The is a collection of simple "echo" SOAP remote procedure call (RPC) invocations, in which a client sends a parameter of a certain type (such as integer, string, etc.) and the server simply returns a parameter of the same type and value. The client then examines the returned value to ensure that it matches the value it sent. Figure 1 illustrates the round trip for one such test, echoString:

By executing this round trip, the test exercises:

1. The ability for the server to parse the client's SOAP envelope.
2. The ability for the server to deserialize the encoded parameter contained within the envelope.
3. The ability for the client to parse the SOAP envelope sent by the server in response.
4. The ability for the client to deserialize the encoded parameter sent back from the server.

Currently, echo methods are defined for the following data types:

• string
• integer
• float
• struct
• dateTime
• base64Binary
• an array of strings
• an array of integers
• an array of floats
• an array of structs

As a client executes the tests with a server, it records the pass or fail status for each test. Many implementers have posted their client's results (see Resources). Table 1 shows a set of sample results between a client built with a toolkit "X" and a variety of servers.

Table 1. Sample Client Results Matrix

Once a client-server pair experiences an interoperability failure on one (or all) of the tests, the problem is usually reported on the list and the community has the chance to immediately discuss why the failure occurred and what might be done to correct it.

Back to top

A sample interoperability issues list

Examples of problems that have been encountered through testing and discussed in the forum are listed below. It is not an exhaustive list, but hopefully provides a sample of the kinds of issues that have come up in the past.

1. When bound to HTTP, SOAP mandates the use of an HTTP header called "SOAPAction." Some toolkits were not quoting their SOAPAction HTTP header values, contrary to the SOAP specification; this caused problems with toolkits that assumed that all SOAPAction values would be quoted.
2. The SOAP specification allows for, but does not require, explicit "on-the-wire" typing of parameters."On-the-wire" typing is type information included directly in the SOAP message envelope. Some toolkits relied on "on-the-wire" typing for deserialization instructions, while other toolkits did not send "on-the-wire" type information.
3. The SOAP specification does not mandate the use of a specific version of the XSD Schema, which is understandable, given the fact that the XML Schema standard had not stabilized at the time of the creation of the SOAP spec. Toolkits were sometimes unable to deserialize encoded parameters sent from other toolkits using a different version of the XML Schema (for example, 2001 vs 1999).
4. Some toolkits were unable to parse the Unicode byte order mark sent by other toolkits.
5. Some toolkits were unable to handle the use of XML ID/HREF referencing mechanism within SOAP envelopes that were being received.

For a more detailed view of the issues and their resolutions, please see the SOAPBuilders message archive (see Resources).

Back to top

Case Study: SOAP interoperability demonstration

The community's collaborative effort has yielded definite, tangible results in a remarkably short time. Bugs have been found and fixed; specification interpretations have been clarified; as a result, many toolkits have been patched to incorporate modifications and fixes that improve interoperability.

To illustrate this improved interoperability situation, Microsoft and IBM co-sponsored a SOAP interoperability event at the Networld+Interop show in May, 2001 that showcased much of the SOAPBuilder group's work, with several vendors and individuals participating. In this demonstration, using SOAP-based clients and servers from a wide variety of platforms, a simple business-to-business situation is illustrated in Figure 2.

1. A seller registers its presence with the registry.
2. A buyer retrieves the list of all registered sellers from the registry.
3. The buyer issues a request-for-quote to a seller for an item.
4. The seller responds with the quote.
5. Steps 3-4 are repeated between the buyer and a number of other sellers.
6. The buyer issues a purchase order for the item to the seller of choice.

After defining the business scenario, the group defined the programmatic interfaces that supported the scenario. Each participant then implemented the interfaces as a SOAP-capable service endpoint (in the cases of seller and registry implementations), or as a client that could utilize such endpoints (in the case of a buyer implementation), and an active network of buyers, sellers, and registry was born.

Because of the cross-implementation interoperability work that had already been done at the SOAPBuilders group, over 10 toolkits, based on a number of different platforms and languages (Java, COM, .NET, Perl, etc) were able to integrate with each other relatively easily.

Back to top

Next Steps

The SOAPBuilders interoperability test suite in its current form is only a first step, and will continue to evolve. Further evolution of the testing process will most likely incorporate:

• A wider spectrum of data types will be tested (essentially covering the full set of basic types defined in the XML Schema specification, which is now in W3C Recommendation status).
• More interesting variations on SOAP will be incorporated into the tests.
• The ability for toolkits to conform rigorously to a standard WSDL service description will be tested.
• Incorporation of the more general document-style SOAP, as compared to its current focus on "section 5" method call / parameter encoding.
• Additional automation of testing procedures and processes, as the number of testing participants continues to grow.

Back to top

Conclusion

The SOAP interoperability picture has improved dramatically, thanks to improved communication among implementors and the introduction of inter-toolkit testing. SOAP interoperability testing will be a continual process, as new implementations appear and other existing ones improve and will serve as an early example of interoperability testing for web services. There is still a tremendous amount of work to be done, but the community has now established a solid foundation for the continued growth and improvement of SOAP interoperability.

Resources

• Visit the SOAPBuilders Yahoo Group and read the archives.
  
  
• Visit the SOAPBuilders ILab page to view test endpoints and links to test results.
  
  
• The results of SOAPBuilders ILAB interoperability testing between clients.
  
  
• Read the SOAPBuilders Testing Proposal document.
  
  
• Check out the SOAP Implementation list that Paul Kulchenko maintains at soaplite.com.
  
  
• Learn how to get Apache SOAP and Microsoft SOAP Toolkit from the web services insider.
  
  
• Brush up on the SOAP 1.1 Specification.
  
  
• In this article on Trends in e-business technologies from the IBM Systems Journal, R. A. Smith examines how trends in technologies such as SOAP will lead to future web services.
  
  
• This whitepaper, Web Services Development Concepts (WSDC 1.0), describes the approach for developing Web Services from the point of view of the developer of service providers and service requestors and includes information on deploying SOAP services.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• The interoperability challenge
• The solution: communication and testing
• The SOAPBuilders test suite
• A sample interoperability issues list
• Case Study: SOAP interoperability demonstration
• Next Steps
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

With the no-charge DB2 Express-C, pureXML and evolving your XML schemas you can easily increase development and application performance.

---

• Try: Download a free trial version of DB2 Express-C, which includes pureXML technology that is ideally suited for managing XML schema and relational data.
• Article: See how to use DB2's pureXML schema evolution capabilities, that evolve schemas without making any changes to your applications.
• Tutorial: This tutorial shows you how using a native DB2 XML database enables changes in an existing XML schema to also appear in your application code.
• Buy: DB2 9 for Linux, UNIX and Windows

Dig deeper into SOA and Web services on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers