In the previous articles in this series I described how many different standards are used together to implement Web services. (See Resources.) Each of the standards, including SOAP, WSDL, and XML Schema, can stand alone, independent from the other standards. However, each standard solves only a very specific issue in the creation of a Web service. All of the standards leave extensibility points and room for further specification due to the limited scope of each of the standards. Thus, implementations of each standard must decide how to handle the extensibility points and what extensions are supported. To interoperate, different implementations cannot simply rely on having proper support for the standard itself, but must also note specifically how the extensibility points of the standards are handled. For instance, in the previous article, I described that simply knowing that two products implement the SOAP standard is not enough to ensure interoperability. The products must give information as to the specific transports they support, the data encoding they require, and possibly the type system they make use of for their data.

In this article, I will describe the issues around the Web Services Description Language (WSDL). I will also discuss where it fits into the Web services architecture and the specific features of the standard that one needs to be aware of to properly assess interoperability.

So many WSDL bindings, so little time

The concept of a Web service is very abstract. Thus a description language for Web services is also very abstract. WSDL describes services in terms of operations, which represent functionality accessed by exchanging messages, which are made up of message parts. A set of operations can be grouped into a portType. None of these WSDL concepts are concrete, meaning that knowing a Web service's portType, which gives you the relevant operations, messages, and message parts, is not enough information to make a real request to the server. Obvious things which are missing are the transport protocol, the wire format, and even the location on the network of the Web service. All of those things are seen by WSDL as concrete details of the implementation of the service. Of course, these details are not ignored by WSDL. But it is important to understand that they are not part of the WSDL standard exactly. Just as supporting SOAP did not mean supporting SOAP Encoding; supporting WSDL does not mean supporting specific WSDL bindings.

The term binding in WSDL refers to the link between abstract and the concrete details of a Web service. A WSDL binding is an extension to the WSDL standard that specifies how the messages will look on the wire and creates constructs for specifying the location on the network to find the service. To illustrate the purpose of a binding in WSDL, imagine a Web service that has an operation called getStockPrice. The operation takes two parameters: the company symbol and the date for which to give the price. The Web service uses SOAP as its wire format. The WSDL specification is independent of the SOAP specification but there needs to be a way to describe how to format the request into a SOAP Envelope. For example, if this is not specified, how does one know whether the parameters are to go in the header of the SOAP Envelope or the Body? The Web service author would use the SOAP WSDL binding to specify such details in the WSDL document. In Listing 1, the piece of WSDL presented describes how the getStockPriceoperation should contain the date parameter in the header and the company symbol parameter in the body of the SOAP Envelope. Elements using the wsdl namespace prefix are defined by the WSDL standard, any others are part of a particular binding.

	
...
<wsdl:binding name="mySOAPBinding" type="servicePortType">
    <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <wsdl:operation name="getStockPrice">
        <soap:operation /> 
        <wsdl:input>
            <soap:body parts="companySymbol" use="literal" /> 
            <soap:header part="date" message="getStockPriceRequest" use="literal"
                wsdl:required="true" />
        </wsdl:input>
...
    </wsdl:operation>
</wsdl:binding>
...

As expected, there exists a WSDL binding for SOAP. This binding is described in the WSDL spec as a suggested binding. Other bindings that have been defined publicly are HTTP GET bindings, which make use of HTTP without SOAP by encoding the data in URLs, and MIME bindings, which allow the use of MIME in messages. So with WSDL and the HTTP GET binding, that simple CGI script you wrote to keep office table soccer statistics can be a bona fide Web service. This extensibility point of WSDL can also cause compatibility issues. Higher level Web service APIs that consume WSDL to generate proxies need to support not just WSDL itself, but the specific WSDL bindings that are in use by the Web service. The SOAP binding is the most commonly supported binding. Often these higher level APIs will refuse to deal with any WSDL that mentions any other binding. Yet it is not difficult to find Web services whose WSDL depends on the MIME and HTTP GET bindings.

Ambiguities of encoded usage

Often the encoding style of choice is SOAP Section 5 Encoding. However, a problem arises because it is not made clear how you can model SOAP Encoding data models, that is, the graphs, with XML Schema. For this reason, the WSDL SOAP binding's encoded usage is the cause of many compatibility problems even if all the relevant technologies are properly supported. The problem is that XML Schema is a language designed to specify an XML document structure. XML documents are tree structures. However, the SOAP data model is more general and can deal with graphs rather than just trees. So XML Schema cannot describe a SOAP data model in any obvious way. Unfortunately, with WSDL as it stands today most Web services use XML Schema to describe an instance of the SOAP data model. Since XML Schema cannot describe data conforming to the SOAP data model, toolkits that depend upon reading the WSDL to infer the structure of the requests and responses are left to a guessing game. This is often benign is the same toolkit is used for the server and the client, but it soon becomes problematic when different toolkits are used. The problem is not with encoded usage or XML Schema particularly. The problem is that no standard defines the rules for describing a SOAP data model with XML Schema. Lliteral usage, as opposed to encoded, usage simply asserts that the XML Schema referenced in the WSDL completely and exactly describes the XML that will travel on the wire. Thus the mapping from the abstract messages in the WSDL to the concrete requests and responses on the wire is completely unambigous with literal usage.

To illustrate the problem, imagine a Web service that returns a linked list data structure which we serialize to XML using the SOAP Section 5 Encoding rules. Listing 2 shows two different serializations of the same linked list data structure serialized according to SOAP Encoding rules.

	
Version 1:
<ns:list xmlns:ns="urn:myns">
    <node id="node1">
        <data>Some Data</data>
        <next href="#node2"/>
    </node>
    <node id="node2">
        <data>Some Other Data</data>
        <next href="#node3"/>
    </node>
    <node id="node3">
        <data>Yet More Data</data>
        <next href="#node1"/>
    </node>
</ns:list>

Version 2:
<ns:list xmlns:ns="urn:myns">
    <node id="node1">
        <data>Some Data</data>
        <next id="node2">
            <data>Some Other Data</data>
            <next href="#node3"/>
        </next>
    </node>
    <node id="node3">
        <data>Yet More Data</data>
        <next href="#node1"/>
    </node>
    <node href="#node2"/>
</ns:list>

The problem arises when I try to create an XML Schema that describes the linked list structure. The client that reads my schema must be able to understand that I am describing such a linked list structure and thus must accept all possible versions of the XML that de-serialize to the same graph. This means the schema must represent more than simply what the XML looks like, it must represent the essence of the data structure: a linked list. But XML Schema is not designed to do more than represent a particular XML serialization. Nowhere in any specification is a means described to use XML Schema to represent a SOAP data model. Thus, if I were to write a schema to represent my particular linked list, there is no guarantee that another person will read my schema and extract from it the same data model. Another way of thinking about the problem is to imagine writing a single XML Schema that will validate both of the instance documents shown in Listing 2 as well as every other possible valid formulation of the same graph according to SOAP Encoding rules. The task may be possible for this simple case but it becomes daunting and likely impossible in the general case. The difficulty of writing such a schema demonstrates the fact that it is a language unsuited for the task of describing models such as the SOAP data model. Even though WSDL is not mandating that when you use the encoded style of the binding, the XML must validate with the given schema, there still should be a set of unambiguous rules to go from an XML Schema to a SOAP data model. Otherwise, given such ambiguity, the implications for interoperability are disastrous. In essence, a set of rules is missing: how to describe SOAP data models in the WSDL such that everyone will see the same structure. XML Schema alone is not the solution. Current discussions around WSDL version 1.2 are addressing this problem. One proposed solution is that a new simple language be created for describing SOAP data models explicitly.

Back to top

Recommendations to developers

As practical advice in the current state of art of Web services, I have a few hints which I believe will help you write Web services that are accessible in the simplest and most efficient way by the largest number of developers. Keep in mind that these are nothing more than opinions based on observations. There are exceptions and you can sometimes rightly disagree with these ideas. The constant change in this technology also changes the pros and cons of each of these suggestions.

The first hint is simply to use WSDL. It will allow developers to generate proxies which let them focus upon the real work and not concern themselves with the XML DOM API. Since I suggest that you use WSDL, I will suggest techniques which increase the compatibility of your WSDL file with most high level Web service APIs. The first of these is to use the SOAP WSDL binding with XML Schema as the type system with literal usage. This will help avoid the ambiguities that arise from encoded usage. I suggest using the SOAP binding simply because it is the most commonly supported and there is no reason not to use SOAP as a message format in most cases. As for a transport choice, I won't suggest a particular transport because an appropriate choice of transport is very important for the usefulness of your Web service. The wrong transport can cause serious problems with scalability, implementation difficulty, security, and reliability. Be aware, however, that HTTP is the most commonly supported transport. So if HTTP is an appropriate choice, then I suggest using it instead of another similarly suited transport.

Back to top

Recommendations to the Web services community

I believe that to alleviate the complexity caused by such general standards with such complex interactions we should urge and support the creation of a set of Web service classes. Each class of Web service could consist of a description of required transports and bindings that must be supported along with some semantics to disambiguate the interaction of such technologies. Some examples of Web service classes might be WWW Web services which are perform the tasks for which CGI scripts have currently been employed, administrative Web services which might employ technologies such as Universal Plug and Play (UPNP) and Simple Network Management Protocol (SNMP), or data access Web services which could help create efficient Web services front ends for applications such as the Lightweight Directory Access Protocol (LDAP) or the Structured Query Language (SQL). Classes of Web services would share performance, state, and security requirements.

If a software product indicates that it is compatible with the administrative Web services requirements, you can be assured that it will interoperate with another software package making a similar claim. It turns out that a group known as the Web Services Interoperability Organization (WS-I) is currently developing what they call Web service profiles. These seem to have similar goals as to what I have described as Web service classes. The WS-I's "Basic Profile" draft was recently released. This profile is a great step towards advancing interoperability. It clears up simple ambiguities in the current standards and enforces a particular transport, type system, and encoding for compliance with the profile. Such recommendations are very important. So the WS-I is an important player in the maturation of Web services. The SOAPBuilders mailing list is also improving interoperability by ironing out the differences between current Web service toolkits.

Back to top

Putting it all together

Understanding that SOAP and WSDL are very general standards which address very specific pieces of the Web services problem is the first step in being able to evaluate the compatibility and scope of Web services software products. Be aware of the key extensibility points as discussed above. Each one presents you with a point at which compatibility problems may arise. Yet each of these extensibility points also gives the standards the ability to adapt to specific applications. For example, XML Schema might be a great type system for configuration information databases, but it might be awkward and inefficient for an image database. SOAP over HTTP might be great for e-commerce transactions but it will not work easily for publish/subscribe applications. Keep in mind that of the standards I have mentioned, only XML Schema has had significant peer review. SOAP and WSDL in their current forms are merely notes and working drafts. SOAP version 1.2 and WSDL version 1.2 will be soon official recommendations from the W3C. The good news is that because of the amount of interest and experimentation with the current SOAP and WSDL versions, these revised versions are likely to have resolved many of the simple ambiguities. Still, they will not reduce the generality of the standards and compatibility must still be ensured for each specific implementation in question.

Resources

• Look at the Web Services Interoperability Organization (WS-I), specifically their introduction to Web service profiles (PDF).
  
  
• Learn about the very important WS-I Basic Profile in First look at the WS-I Basic Profile 1.0. (developerWorks, October 2002)
  
  
• For more information about the problems with encoded usage read The Argument Against SOAP Encoding.
  
  
• Dig deeper into the issues of different WSDL bindings in Web service invocation sans SOAP. (developerWorks, September 2001)
  
  
• Learn about the activity of the W3C Web Services Description Working Group
  
  
• Get some practical information about WSDL in Deploying Web services with WSDL: Part 1. (developerWorks, November 2001)
  
  
• Clear up questions about WSDL from the source, the WSDL version 1.1 specification.
  
  
• For a peek at what's coming in the new specs, look at the WSDL version 1.2 working draft part 1 and the WSDL version 1.2 working draft part 2.
  
  
• Check out the previous 2 installments of this series:
  • Finding your way through Web service standards, Part 2 (developerWorks, October 2002)
  • Finding your way through Web service standards, Part 1 (developerWorks, October 2002)
  
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• So many WSDL bindings, so little time
• Recommendations to developers
• Recommendations to the Web services community
• Putting it all together
• 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.
• Demo: This demo shows you how easy it is to create a DB2 database for storing XML data.
• Buy: DB2 9 for Linux, UNIX and Windows

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers