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
[EMAIL PROTECTED]
(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
AxisInternalMessageExchange.zip
Description: Zip archive
