Oisín Hurley's Weblog

I'm in Logan Airport, on my way back to Dublin after a hectic few days in Cambridge at the EclipseWorld 2006 conference. I went over there with a job to do: as the the PMC Lead for the SOA Tools Platform (STP) project, I had a talk to give, updating the attendees with the status of the project. I think it went over pretty well - our presentation (pdf link) was chock-full of details of the STP sub-projects and included a number of demos of the code contributions.

Wayne, I thank you most sincerely and look forward to working with you. I've subscribed you to the stp-dev mailing list too :-)

What a start to a new year - finding ones phyzz adorning the front page of The Server Side! Steve and myself did a piece before the holiday where we spoke about the company we work for and some of our favourite topics. link

Now I know what the phrase you have a great face for radio really means.

I just read Beth Gold-Bernstein's blog entry entitled Categorizing Web Services in which she proposes the development of Service Patterns to provide a recipe-style approach to SOA development. I would certainly recommend to her that she visit the Enterprise Integration Patterns, get the book and read it cover to cover. There's enough patterns in there to be going on with - the book is quite information-dense, but if you go to the website there is a breakout of each of the patterns.

Beth also states that these patterns should be embodied in tModels for storage in UDDI registry. I can only attribute the continued existence of UDDI to some kind of dancing bear syndrome - while I don't agree with everything that Peter Lacey says in his criticism of web services, I think he is spot on with the UDDI comments. Rather than continuing to lipstick this pig, I think that it's time the industry looked at a SOA-coherent and standardized repository API. Not something that is infinitely flexible or can be repurposed to anything (an ex-colleague of mine used the public UDDI servers to store his bookmarks), but something that has Services, Intermediaries, Policies and the like as first-class items and allows them to be tagged, typed and corralled into workflows. Then the patterns would make more sense.

Well, it shipped nearly a couple of weeks now, and I've been taking a bit of breather and getting back in touch with some other things that get left by-the-by as we went through the release process. Bjorn and the legal team deserve great praise for their mammoth efforts in getting everything lined up for those of us who delivered projects.

From the perspective of SOA Tools, it's a time to gather our wits and make some plans, with the help of the community. I'm glad to say that over the last few months, there has been a considerable amount of interest in the project from a number of organizations that wish to contribute code and expertise. The PMC's challenge is how to make sure that all these prospective committers can work together in a way that is conducive to developing the best open source tools and frameworks.

Enter the Incubator. This is to be an STP sub-project (it's in pre-proposal phase right now), which I hope will address our challenge. It works like this -- a number of organizations decide they would like to contribute some code, but in each case, they have code that does the same or similar things. The best thing for the project is that the committers come together, bring their solutions to the table, re-architecting if necessary, and producing a joint vision for the merged code. The 'table' in that metaphor is the Incubator sub-project. Once the technical vision has been constructed and agreed upon, and a draft plan put in place, any work that has taken place in the Incubator is ready to 'graduate', that is, move to full STP sub-project status.

It's also time to let us know what you would like to see happening in the current areas of the project - let us know on the dev list or the newsgroup!

I'm waiting for my flight to Frankfurt to attend the Eclipse Summit Europe that is being held in sunny Ludwigsburg, in Germany. Due to a typical pebkac error, I'll be staying in 3 hotels over the 5 days that I will be there :)

The Euro Summit is an interesting conference - the content is usually good, the venues conducive to meeting people and of course the German beer is without peer. This adds up to a fun-filled few days. During the conference, Adrian from STP will be updating us on what's new and noteworthy on the project, and of course bringing us up to date on the old material too. One of the evenings will contain an STP BoF, although the date has to be confirmed.

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.