I was printing out the
WSDL 2.0 Core Specification this morning and I was surprised to find that it's over 100 pages long. And it's a long, hard, coma-inducing read as well. Technically though, it shouldn't be surprising. The details of protocol bindings, interfaces, operations, and exception/fault definitions for web services must be precise, clear, and unambiguous for interoperability to work. In the end, it really is hard to create a flexible language to describe the world of possible web services.
But as Antoine de Saint-Exupery said, perfection in engineering is achieved not when there is nothing left to add, but when there is nothing left to take away. It does appear that WSDL, in its third incarnation, has bulked up heavily on complexity for the sake of robustness, instead of making it better by making it simple. In the end, it's a spec only a tool vendor could truly love and early comments on it have not been favorable.
I've been tracking some of the other web service description specifications recently, including some that are not yet specifications, but merely good ideas. Savas Parastitidas and his folks have the SOAP Service Description Language (SSDL), Norm Walsh has NSDL, there is the aforementioned WSDL 2, Rich Salz has talked about a basic SDL he calls RSWS, and even the eminent Tim Bray (co-inventor of XML) has chimed in recently about something he calls SMEX-D.
This last one, SMEX/SMEX-D is particularly interesting because it purports to be a full web service description language that is the "simplest possible way you could declare an exchange of XML messages", and more importantly, can describe both REST and SOAP (and other) services. This is very good because it reflects the real world of web services, and not purely an isolated standards body or tool vendor view.
Figure 1: The various service description languages: WSDL, SSDL, NSDL, RSWS, RSDL, WRDL
Going across the entire spectrum, there is
RSDL, the REST Service Description Language, just a twinkle in someone's eye, but much further along in the REST description language camp is
WRDL, which has a Python implementation already.
But in a design space where it's very important to actually have a problem to solve before creating a solution, what do these description languages actually do for us? Do they make using web services easier? Do they lower the barrier to use? Do they reduce coupling or enhance interoperability? The answers today are not clear.
At a basic level, machine-readable service description languages make it easy to map a web service into a local model, such as a proxy class in your favorite programming language. This is certainly useful if you are using a tool that can do this and the web services exclusively uses idioms that your local toolkit supports. So if your SDL confounds this, doesn't exist for the service you're using, or doesn't accurately describe the service, then what do you do?
The problem is that the more complex an SDL is, the more likely it can describe the nuances of a web service, while at the same time making it probable the mapping has errors. This makes the razor slice both ways. It raises the question of whether web services should just be self-describing in a simple way, like web services in the form of RSS, which are already providing services on a huge scale without a service description language, as Dare Obasanjo pointed out recently.
With certain folks questioning whether or not description languages should even be involved with code generation and with the proliferation of SDLs, it makes one wonder what service and client implementors should do.
In the next few posts, I hope to look at some WSDL 2 examples, what REST needs in terms of an SDL (if it needs one at all), and try to take a look at where this all should head in a perfect world.
Update: Much thanks to Tim Bray for the huge blog karma he bestowed on this post (to the point my server keeps going down). :-) Also, thanks for the thoughtful comments below. I will absorb them and update the diagram shortly with RDF added and reposition WSDL 2. Thanks!
Technorati: Enterprise Architecture, Computers and Internet, Programming, Web Services