WSDL Revisited

Waay back in May last year, I wrote a little blog entry taking WSDL and associated tools to task. You can imagine my delight when my esteemed colleague Guillaume Nodet sent me a link to a Google Code project called Relax-WS.

The author states

WSDL is a key technology for SOA, and yet creating and editing these files is about as much fun as straightening all the noodles in a bowl of spaghetti with a pair of tweezers.

and goes on to promise

all good, right and true, in my opinion. I would go even further on the last quote there and say that Relax-WS should aim to provide the simple, programmer-friendly syntax, but should also lose any metadata that is not necessary and add metadata where it is missing from WSDL.

One comment I have on the Relax-WS approach is a reaction to the sample code that is on the front page

service Hello {
  port {
    operation SayHello {
      in {
        element name {xsd:string}
      }
      out {
        element message {xsd:string}
      }
    }
  }
}

What's wrong with this, you might ask? It's clear and concise. Indeed it is, say I, and there is nothing at all wrong here, but the bit that makes me somewhat uncomfortable is the use of the service term there. Once you start to mention services, you are looking at a crossover from definition of schema and operation to a service provider definition, which necessarily leads on to having concrete pseudo-physical resource details in the Relax-WS file. What's a pseudo-physical resource? It's an artifact that has a constraints on a machine - so things like ports, databases, file systems, etc fall under this category. If you nail down your pseudo-physical resources at development time, then you are in for a reduced amount of fun when it comes to deployment. Ideally, you bind all those pp-resource details at the last minute (delay your decisions -- a lean maxim), so when you are developing you should set up the capability to discover those details at start up time from a fixed place, rather than baking them in.

A good example would be coding a Spring application for the ServiceMix 4 kernel, burning in the configuration into the bundle, and then binding it to a little properties file that contains the pp-resource specifics for the particular [virtual] machine upon which it is to be hosted.

Anyway - fair play to the author of Relax-WS for taking this on. I'm sure there will be take-up of the project.