All We Want For Christmas is a WSDL Working Group
Dear Santa Claus,
We have both been very good this year. We've done our best to promote peace and understanding among web service developers around the world. We have run into some problems, however, with the Web Service Description Language (WSDL). In case you aren't familiar with WSDL, it's an XML-based language that captures the mechanical information a client needs to access a web service: definitions of message formats, SOAP details, and a destination URL. (Of course the client also needs to understand the semantics of particular messages, but that information is still imparted the old-fashioned way, i.e., documentation.) WSDL files are often interpreted by software, which uses the metadata they contain to generate client-side proxy code for accessing a service. This is appealing to developers who do not want to program in raw XML.
We agree with most people in the web service community that something like WSDL is necessary. However, we have a number of issues with WSDL as it stands today, and we are hoping that you can fix them. Here is our list:
WSDL models endpoints in terms of portTypes, abstract definitions of what a web service can do. Each portType is defined as a set of operations involving the exchange of abstract messages. Bindings are concrete definitions of how a portType's operations are invoked using a particular format and transport protocol, e.g., SOAP and HTTP. This would be fine except that SOAP bindings are defined as having one of two styles: document or RPC. Document style implies that a service is a message-oriented endpoint. RPC style implies that a service is a function-oriented endpoint. Given that function-oriented endpoints are still accessed via SOAP messages (as the SOAP specification puts it, "A method invocation is modelled as a struct"), this distinction is completely arbitrary and unnecessary.
Unfortunately it permeates the WSDL language, introducing meaningless differences that only serve to confuse developers. We don't know if this is too much to ask, Santa, but it would be great if you could do away with this distinction so that, after Christmas, we could all define our web service in terms of the messages they exchange, leaving it to individual developers to map those messages to method call stacks, if desired. This technique works fine: Microsoft's ASP.NET web service infrastructure creates document style endpoints (by default) but maintains the RPC programming model.
Should Santa grant Tim and Martin their wishes? Have they wished for too little? Have your say in our forum. |
| Post your comments |
And as long as we're on the topic of arbitrary distinctions, Santa, you could make us very happy by straightening out WSDL's approach to describing messages. First, it would be nice if WSDL mandated the use of XML Schema for describing messages. The current version of the specification does not require the use of XSD or any other particular type system. If XSD were mandatory, we could do away with the message construct and define a portType's operations directly in terms of schema type definitions. The message construct is simply a poor man's XSD compositor.
Now look, Santa, we know what you may be thinking: Yes, we have a predilection for XML Schema (as our November column explained), but what about all those nice people who like to use the encoding rules defined by SOAP Section 5? Doesn't mandating the use of XSD hinder them? Shouldn't they get what they want too?
In the spirit of the holidays, we'd have to agree absolutely. However, mandating the use of XML Schema to describe messages doesn't preclude the use of the section 5 rules. If someone wants to map from a programmatic type system to SOAP, they can apply the section 5 rules when they generate the Schema definitions for their messages. Then, in their WSDL documents, they can still describe operations in terms of Schema types, albeit ones that reflect SOAP Section 5.
The beauty of this approach is that it doesn't preclude people from deriving Schema types anyway they like, but it would drastically simplify the descriptions of endpoints. In addition to dumping the message construct in favor of XSD complexType definitions, it would allow us to do away with the distinction between SOAP bindings that make literal use of XSD types and encoded use of XSD types. A literal SOAP binding describes an endpoint entirely in terms of XSD types. An encoded SOAP binding describes an endpoint in terms of a combination of XSD types and "well-known" encoding rules. (The amount of time and effort the members of the SOAPBuilders community have put into defining what the SOAP Section 5 encoding rules actually mean in concrete terms belies the claim that they are well-known.) If all of a portType's operations were defined solely in terms of Schema types, some of which might reflect the SOAP encoding rules, there is no need to describe endpoints differently at the WSDL level.
If you could rid us of the distinction between literal and encoded SOAP bindings, Santa, we'd really appreciate it, especially if you got rid of the distinction between document and RPC SOAP bindings too. Ultimately, the fact that there are really four possible ways to define a SOAP binding in WSDL makes life miserable for people implementing web service toolkits and for people trying to make them work together without providing any benefit. Since all we ever send on the wire are XML messages embedded in SOAP envelopes, why complicate things by defining four possible ways to say the same thing? WSDL is just being too clever for its own good.
Okay, Santa, let's move on to something else. Many people have drawn the analogy between WSDL and the Interface Definition Languages (IDLs) used by CORBA, COM and other RPC technologies. More specifically, they observe the parallel between portTypes in WSDL and interfaces in IDL. There is, however, an important difference. In classic RPC models, including COM and CORBA, the wire representation of a method invocation includes not only the input parameters, but information that uniquely identifies the interface and operation being invoked. While WSDL defines web service endpoints in terms of portTypes (interfaces) and operations, it does not define a standard way to pass that information on the wire.
So why is this a problem? What if you define two operations with exactly the same wire representation? For instance, what if you defined a document/literal SOAP binding for a portType with two operations that use the same XSD global element declaration to define the format of their input messages? Or what if you defined a service that implements two RPC/encoded bindings for two portTypes in the same namespace and with duplicate operation names? In either case, a SOAP endpoint would be hard pressed to figure out what to do unless it receives information about the portType and operation being invoked.
More from Rich Salz |
If you haven't run into this problem yourself, Santa, it is probably because today's web service toolkits steer around it. For instance, because most toolkits generate WSDL definitions from server-side source code, they simply ensure these situations never arise. They always create unique mappings of native operations to WSDL, and if for some reason they cannot, they raise an error. This approach works in simple cases. But if we start defining WSDL portTypes independent from implementations, which is the point of interfaces, these problems are very likely to arise. In short, if portTypes and operations are really to be considered first class constructs in the web services world, there really should be a standard way to pass information about them on the wire when a method is invoked. The most obvious way to do this is with an as-yet-to-be-defined custom SOAP header (which would make an excellent stocking stuffer).
Actually, Santa, forget about our list. We just realized that all we really want for Christmas is a WSDL working group. If you can get us one of those, we'd be very happy. Then we could just send our list to it...
Thank you and Merry Christmas!
Tim & Martin
XML.com Copyright © 1998-2006 O'Reilly Media, Inc.