I'm going to be conducting a whirlwind survey of the various web service description languages (SDLs) over the next few weeks.
The goal: To uncover the real issues involved with web service description in terms of interoperability, ease of consumption, self-description, and abstraction of unimportant technical details. In other words to narrow down, in a Darwinian fashion, which ones readily foster service-orientation. This is a topic more than a few important people in the web services space have been thinking about lately, or actively trying to solve.
I'm going to start with WSDL 1.1 since that's the underpinning of WS-I Basic Profile and then start systematically looking at the most likely candidates we'll see in the web services space in the next few years. Since this is my survey, I'm going to play a few favorites as well, but mostly to keep it interesting.
Figure 1: WSDL 1.1: A Good Service Description Language? Compared To What?
To make a real world evaluation, and for folks to follow along, I'm going host all the work online here at hinchcliffe.org. The web service(s) used for the survey will be running here and I'll post the schemas and the clients that are built along the way. Hopefully this will offer transparency and make the results more authoritative since more eyes will be on the work as it goes along.
Much of my interest in web services is around interoperability and I find hetereogenous web services environments to be the most interesting, and most telling, ones that uncover the real possibilities and limitations of web service technologies. Unfortunately, many of the advantages and disadvantages of web services are often drowned out by the noise of bigger issues within a software project or architectural initative. But a clear and clean web services description model that makes service-orientation fundamentally easy would indeed provide genuine value to the world of WS architecture and development. Enough perhaps to make a difference and provide a real breakthrough. But as WS-* standards and ad hoc WS methods continue to proliferate, it's not clear how close we are yet or even if the problem is getting worse.
In the vein of understanding actual interoperability issues, I'm going to select two IT workhorse languages (Java and C#) and one new and upcoming language (Ruby) for clients of the canonical web service we'll develop. Then we'll try to apply each of the various SDLs to the development of the web service clients and see what happens. It will be a test of the languages, their web service stacks, and most importantly, the SDLs used. I anticipate that a pretty interesting story will unfold as we go along.
Along with the three platform clients we'll develop, the web service(s) they'll use, and SDLs we'll document them in, there is also the issue of which web service protocol to use. Should it be SOAP or should it be REST? The answer is that it will have to be both, to see what the service description languages can really support (and some only do one or the other). This means we'll have two different web services for our test, one in SOAP and one in REST. This is a lot of client, web service, and service description languages combinations, and so obviously we need to keep things simple.
And to keep things simple, we'll need to have a few ground rules. Here is what I am thinking:
1) Use XML documents for messaging, not RPC.
2) The web service contract must use XSD or Relax NG schemas to describe the message.
3) Target SOAP 1.1 and REST (using the hypermedia application state model, not just XML over HTTP.)
4) Use a canonical order placement web service to place an order and check on status.
5) To avoid tight coupling, clients will not use a proxy but communicate at the next available level of abstraction.
6) Clients must interact with the service using purely what is found in the service description.
7) For each SDL, the client must be implemented in Java, C#, and Ruby.
8) Each web service client must place an order, wait 10 seconds, and check on the status.
9) The list of SDLs to try to use is: WSDL 1.1, WSDL 2, NSDL, SSDL, WRDL, RSWS, WADL, Resedel, SMEX-D, RDF, RDF Forms, OWL/OWL-S, WSML, and WDL.
When possible, I will work directly with the folks who have created the service description language and make sure it's being applied properly. I'm in the process of creating the SOAP 1.1/WSDL 1.1 version of the order web service now. It is hosted at:
http://hinchcliffe.org/order.asmx
This service will continue to change and evolve without warning, so check the service contract if you are actually going to use it. More documentation will follow and as well as blog updates as frequently as I can manage. Hopefully we'll all learn a lot and draw some useful conclusions about the real state of web service description languages today.
Technorati: Enterprise Architecture, Computers and Internet, Programming, Web Services