WS-CAF in New Orleans

The WS-CAF committee has been meeting in New Orleans this week. Unfortunately due to previous commitments I couldn't make it in person, which meant I had to take part via teleconference. Not exactly the easiest to do: phone's were definitely not meant for day-long meeting; roll on the invention of some form of holographic avatar.

Anyway, despite the fact that several of us had to endure the telephone line frequency response of 300 Hz to 3400 Hz for two days, we made excellent progress. We've pretty much closed up all of the issues related to WS-Context (thanks to Kevin Conner for working on the schema and WSDL). With a little luck we'll be able to move that to another committee draft within the month. (Apparently the change in OASIS rules recently has had a knock-on effect on names such as "committee draft" and "committee standard" which I've yet to fully understand, but I know what I mean even if OASIS staff might argue.) I've said before that with hindsight, WS-Context is probably the most important and potentially influential specification of the entire WS-CAF stack. It was never intended to be, but as is often the case, the simplest things that get overlooked initially turn out to be the most important.

I'm not saying that coordination or transactions aren't important, but the applicability of context to Web Services (and any distributed architecture) is so much wider. As more Web Services specifications come along, it's easy to see how they are using a form of context without necessarily being explicit about it. Hopefully this is just an education thing and once WS-Context becomes a standard and we are able to evangelise about it more and more, there'll come a time when WS-Context is used as naturally as SOAP and WSDL. One of my next posts will be about a paper I helped write with Greg on this subject.

I'm also contributing to the OASIS SOA-RM technical committee on this and other aspects of WS-CAF, so that's another way of expanding the influence of context as a principle and WS-Context as a concrete example.

As far as the New Orleans work went though, we also made excellent progress with WS-CF (the coordination framework). I'm confident we're close to being able to finalise this and put it up for public review. The model is a little more focused now that it was when we first submitted the specifications. It's down to pure registration and groupings, with coordination as something that can be layered on top. As with WS-Context, I think this helps to increase its applicability and I suspect that Greg and I may be writing a paper on this eventually.

So that left transactions. I gave a presentation overview (again) of the models and we agreed that the first thing to do was separate our 3 models into individual specifications. This has a lot of merit, not least of which is the fact that it's easier to manage and easier for people to decide what aspects of transaction management they want to implement and still be able to say in a straightforward manner what they conform to. We've also decided that the first model we need to concentrate on is WS-ACID. This is primarily intended to interoperability of existing transaction processing systems, and I'm really looking forward to a future interoperability workshop where we can demonstrate transaction interoperability Arjuna-to-Oracle-to-IONA (for example).