JavaOne WS-CAF face-to-face

We've just finished our WS-CAF face-to-face meeting. It was hosted by Oracle and arranged to coincide with JavaOne so we could maximise attendance. In the end we had a majority of the TC turn up in person and several dialed in to the conference call.

We made good progress on WS-Context and WS-CF, progressing the former to a second Public Review Draft and the latter is almost ready for it's first Public Review draft. Since the Dublin face-to-face meeting at the end of last year, we've spent most of our time working on WS-CF, and now only consistency of the WSDL and schema remain. With any luck that shouldn't take more than a few days and then, assuming the TC agrees, we can move this towards it's Public Review Draft.

Public Review is one step away from standarisation, so I'm very pleased with the way things have gone so far. The power of any specification really comes when it's standardised and adopted by others, either in product or in other specifications/standards that are themselves ultimately adopted into product. We've seen a lot of interest in WS-Context over the past year or so and I think this is reflected in what the other members of the TC have seen as well.

The rest of the time in the meeting was spent going over the WS-ACID specification. This is a really important step towards completing the entire composite application framework and in particular for addressing the critical issue of reliability in Web Services business flows. Since WS-ACID is based on traditional transaction processing concepts such as two-phase commit and synchronizations there wasn't much to discuss in terms of the actual model. The likes of Sun, Oracle, IONA and ourselves all have sufficient experience in this area to know that what we currently have in the specification looks about right.

The issues that did arise included:

(i) if and how we might define some policies for services to identify themselves as being transaction aware. The lack of a standard in the area of policy makes this difficult, but Greg has written a document on this, so hopefully we can still make progress.

(ii) if and how we might define some isolation policies for participants/resource managers. The often talked about isolation policy for ACID transactions is serializability (essentially a concurrent execution of transactions is made to appear as though those transactions executed in some serial manner). However, other approaches do exist, including read-committed and read-uncommitted. Other specifications don't say anything about different isolation levels, so there was a discussion about whether or not it is needed here. We decided that it was a feature worth looking at supporting using policies, so we'll see where this leads us.

(iii) supporting transaction enlistment inflow: rather than an importing domain (one which received a transactional request) registering participants directly with a remote coordinator immediately, information about the participants (their EPRs) are sent back in the context associated with the response and the receiver does the registration. This is an optimisation, but it may save several upcalls, particularly if the coordinator is co-located with the requester.

(iv) shared and unshared transaction support for asynchronous transactions. In a shared transaction model, clients and servers share an end-to-end transaction: when a client invokes an operation on a service and does so in the scope of a transaction, that service may enlist participants in the same transaction the client started. The unshared model is used in store and forward transports (e.g., message queues). In this model, the communication between client and server is broken into separate requests, separated by (typically reliable) transmission between routers. In this model, multiple shared transactions are used where each is executed to completion before the next one begins. There was a lot of good discussion around this and we're going to see if there is something we can do in this space. It took us a long time to address the topic in the OTS so I'm not expecting a rapid resolution.

Overall we had a great meeting and the specifications look in a good state. In many ways it was very laid back, but I suppose that's California for you!