Async in Axis

[James M Snell <ja...@us.ibm.com>]

Now that Axis 1.0 has been released, I and a number of other IBMers have 
started talking with David Chappell and the other Sonic folks about what 
we would like to in the way of support for async operations and JMS within 
Axis.  There are a number of things that we're currently looking at:

1. Changes to Axis internals that would uncouple the request/response 
handler flows
2. Closing the gaps that exist between WSIF and Axis particularly in the 
realm of the async operation and JMS providers
3. Establishing a JMS test harness
4. Figuring out how to expose async client API's given that JAX-RPC just 
don't do it

At the end of this note is a description of my proposal for how to get 
started on item #1. 

Regarding #2, I'll post some initial comments on Monday....

Regarding #3, we will be setting up a server that will run SonicMQ, 
MQSeries and some open source JMS provider (most likely OpenJMS unless 
others have a better suggestion).  This will allow functional tests for 
the JMS transport to be built and tested against multiple JMS 
implementations.  There is currently no timeline on this, but it is 
getting done.

Regarding #4, this is a much more difficult issue given that the 
"standard" interfaces (JAX-RPC) do not support async operations in any 
way.  We need to have a serious discussion about how to enable this.

===============================

Axis Internals

Currently within Axis 1.0, request and response handler flows are executed 
synchronously.  This limits our ability to properly leverage async 
transports and programming models.  After talking it over with the Sonic 
folks, we've agreed that some fairly significant changes should be made 
*internally* that would allow async request/response flows at two distinct 
layers -- 1) within the Engine and 2) within the Transport.

Attached is a proposed "Axis Internal Message Exchange Interface" that 
would sit between the Axis Call Object and the Axis Engine and between the 
Axis Engine and the Pluggable Transports.  This interface implements a 
send/receive event model that provides a huge amount of flexibility 
without adding much complexity.

Below is a simple example that shows basically how this interface works:

MessageContext context = <code to create MessageContext>
MessageExchange exchange = <code to create MessageExchange>
MessageExchangeStatusListener statusListener = 
  new MessageExchangeStatusListener() {
    public void onStatus(MessageExchangeStatus status) {
      if (
        status instanceof MessageExchangeStatus.MessageReceived) {
          MessageContext response = 
            exchange.receive( // get the specific message that was 
received
              status.getMessageExchangeCorrelator());
      } else if {
        status instanceof MessageExchangeStatus.MessageReceivedException) 
{
          // respond to the exception
      } else if (
        status instanceof MessageExchangeStatus.MessageSentException) {
          // respond to the exception
      }
    }
  };
exchange.setMessageExchangeStatusListener(statusListener);
exchange.send(context);

Again, *THIS IS NOT A CLIENT FACING API*.  This is a mechanism that would 
be entirely interal to Axis.  It would sit under the Call object and 
between the Axis Engine and the Transport.  Essentially, the code above 
replace the current AxisEngine.invoke(MessageContext) and 
Transport.invoke(MessageContext) operations.

Please review the code.  Get basic feel for how it is structured, then we 
can talk/debate the details, threading issues, etc and work from there to 
develop the right solution.



- James Snell
     IBM Emerging Technologies
     jasnell@us.ibm.com
     (559) 587-1233 (office)
     (700) 544-9035 (t/l)
     Programming Web Services With SOAP
         O'Reilly & Associates, ISBN 0596000952

     Have I not commanded you? Be strong and courageous. 
     Do not be terrified, do not be discouraged, for the Lord your 
     God will be with you whereever you go.    - Joshua 1:9