JavaOne 2009

I am presenting two sessions in the JavaOne this year.

BOF-4394 Case Study: Managing a Large Web Service Project Based on Java™ Technology
TS-4993 Dealing with Asynchronicity in Java™ Technology-Based Web Services

The inspiration for the first one came from one of my colleagues in Oracle, Vaibhav Lole, who was leading a web service project and kept asking me all sorts of questions during the project. I have invited him to share the experience with us and learn from other developers who come to our session.

The second one is a repeat from the last year. We wanted to add new stuff for a change but after doing lots of editing and trying to keep the number of slides within limit, we could not do the justice. I'll try to describe some of the major issues in this blog that I want the community to share with me.

1. Can we make WS-AT work with One-way calls and requests with non-anonymous replyTo?

Problem with the one-way call is that the service is supposed to return immediately (after doing some basic stuff) to release the http connection so that the client can proceed. And then the server continues processing the request. If the transaction context is passed to such a call then the client will not know when to commit. Also, the transaction will be active at the server side in a different thread probably which is kind of weird for the transaction as traditionally the transaction context is associated with only ONE thread. To add to the problem further, if the one-way/async request is stored in the JMS queue then the async message listener will not see the message until the transaction is committed. So, if the client's transaction waits for the response for the async request before it commits, it will never receive the response.

We have two solutions for this problem:

a. Do not support WS-AT for one-way/async calls. This is what is done by some vendors. If you use such a system, your applications transaction control is broken the moment you start using one-way/async calls.

b. Lets interpret the meaning of transaction for one-way/async calls in a different way.
If a one-way/async call is made, the transaction context from WS-AT must be passed if server allows that.

The server should 'record' the request 'within the current transaction'. For example, saving the request message in the database or JMS queue should be done within the running transaction.

When the WS-AT transaction is committed in the client's side, the 'recording' of the request message is also committed at the server side.

If the client's side transaction fails, the message recording at the server side rolls back.

The actual processing of the request happens outside the client's transaction but only after the successful commit of the client's transaction.

If something goes wrong in the execution of async operation, we cannot 'rollback' the client's transaction (as it is already committed), but service may provide other compensating methods for that purpose.

In my opinion, we should go by the second option as completely disabling WS-AT for one-way calls gives us nothing but the broken applications. Making the server 'promise' that the async operation will get executed ONLY if the client's transaction is a committed is a BIG step forward.

More to come later..