Folks,

I said in a previous note that I'd get around to the question of Callbacks. This note deals with the Callbacks.

Callbacks are different from conversations today. (Yes, I realize that there are proposals to change this) The principal difference is the need for a client to be able to distinguish each invocation it makes on an operation of a service reference. ie logically, the client needs to impose a callback ID on each invocation of the reference and be able to access this callbackID when it receives an invocation on the callback interface.

This clearly gives a problem if multiple threads are allowed to make forward calls on the service reference object held by the client. There is a time window between setting the callbackID and invoking the reference method - and this allows one thread to potentially interfere with another.

There seem to be two approaches to this:

1) Have the callbackID set as a thread local variable.

2) Change the design of callback interfaces so that there is a version of each operation which includes the callbackID as an additional parameter on each method, allowing the client to set the callbackID directly onto each invocation. The precedent for this approach is the existing JAX-WS approach to the asynchronous client API, which is generated by formula from the standard call-and-return API for a service.

Either of these approaches means that any given forward request can have a correct callbackID available on a per-invocation basis to the binding code that packages the request for tranmisssion form the client to the service.

Problem solved.

Yours, Mike.

Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU