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.

It's Déjà Vu All Over Again

Heard of Thrift? It's a Facebook-developed system that allows services to be defined in a language-independent manner.

Didn't we do this already, a while back?

It's slated for contribution to Apache too.

RESTafarianism and EMF

I had the pleasure to share a drink and a chat last night with Ed Merks, the EMF Project lead. One of the interesting things that he brought up was his efforts to extend the EMF URIHandlers to be more REST-like. He mentions this in a blog entry - you will find the reference after the picture of the hibiscus. There are some more techcore details at the Bugzilla entry that hosts the patch.

This work is a big thing for EMF, in my opinion. Putting this together with a simple HttpService instance in an OSGi container can give you the basis for remotely manipulable models, with most of the work done by EMF itself. This opens up the field for Rich Internet Applications (blach - another buzzword) that can interact with hosted EMF models without having to depend on having an EMF library on the client side.

The Artix Repository product that IONA ships has done something very similar, but we have created the RESTful interactions outside of EMF. It's cool to see this kind of capability moving into the core.

This is not WSDL

Recently in IONA, in an informal moment in the coffee area, a number of us sat down with sore heads and decided that we would all feel better if WSDL wasn’t so hard to use. Not in those exact words, but I’m writing for a mixed audience here. In March, I was out at EclipseCon, and got to visit the Yahoo office (where old webservices comrades Mark Nottingham and Hugo Haas now toil). During lunch in the canteen, we talked about lots of things, but one of them was how we would all feel better if WSDL wasn’t so hard to use.

There are of course lots of WSDL editors out there in the wide world. At Eclipse, there is the WTP graphical WSDL editor. Many products, such as XMLSpy and IONA’s own Artix Designer incorporate ways to reduce the agony of dealing with WSDL.

For me though, none of editors I’ve tried have made the nut. As a developer I want a clean way to make WSDL that deals with all of the crud that needs to be there (like pointy-bracket syntax for example). What I don’t want is a weird graphic metaphor with links and dragging and dropping, thanks. Just let me type it, like code, give me some syntax support and some useful conventions and then let some other agency worry about generating the XML vocabulary.

Here is the sort of thing that I would like to be able to type in and have it converted to WSDL for me, with some sensible defaults, etc:

We could also code in some conventions (like that version in the interface) to help people along, so for example:

would cause an error because someone has changed the method signature in a minor version upgrade. They should have used version 2.0 instead. There’s little limit to the fun we could have with this :-)

By the way, the string type that you see there is, by convention, the XML Schema string type. Same goes for the float. You can use imported types just by using the prefix approach that XML already has - pfx:myType.

I haven’t mentioned the bindings aspect of the WSDL specifically. To me, that part is a big target for an extensible set of wizards or tailored binding editors and not something that feels like it should be accessible to code-like definition.

WSDL to *

It's expected that once you have an interface language, like WSDL or CORBA IDL, that you will have a suite of tools that allows you to generate stubs, skeletons, starting code, tests and so forth from the basic interface description in the implementation language of your choice. This is a very important productivity element for any developer, as having to code up server skeletons by hand is just an outrageously dull task.

When I was putting together CORBA systems, I used a tool called idlgen which saved huge amounts of time by generating complete test suites with randomized data, and allowed you to produce stubs, skeletons and mainline code in a jiffy. In my current work, I'm using EMF to represent a suite of models, from which I generate implementation code.

But there's one thing that's starting to bug me about some code generation tools, and here I'm talking about one particular tool that is almost always called wsdl2java, and that is there are so many of them. Everyone! Stop writing new wsdl2java tools and just write a wsdl2star tool instead! Take wsdl4j or Woden as your model and write some backend processing that allows people to develop Velocity templates, or write JavaScript/E4X code to generate the necessary. Wrap all of this up in a single Open Source project and kick-off a community of Open Source script/template developers so that other projects can contribute their code generation incantations (there's your regression test suite too, by the way).

Is there someone doing this already? Let me know if you find them!

Service Modeling Language

Recently I received a couple of emails linking to the SML specification. I read it a couple of times, and came away with no idea what it was about :-) Luckily, I got a chance to talk to Harm Sluiman, one of the authors of the specification. It turns out that the use of the word Service in the title of the spec is misleading. It’s nothing to do with services specifically. Instead, what it appears to offer is a described means to connect and associate XML documents, with a set of constraints that govern the connectibility. Since this piece of work is very fundamental, it looks to me like it presages something else coming down the pipe. Looking at the list of companies involved, and knowing the effort it takes to construct a white binder agreement between IBM and MSFT, it looks like this is going to turn into a big deal.