axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Daniels" <>
Subject RE: [Axis2] Implications of WSRM interfaces on Axis2 ClientAPI
Date Fri, 28 Oct 2005 14:33:18 GMT
Hi Paul:

Great message!  As I read it you're asking for three things:

1. Ability to pass SequenceKey in client API

2. Last message marker in client API

IMO, neither of these needs to be put as first-class concepts into the
Axis2 Call class, because we have easy-to-use mechanisms which allow
this kind of stuff by setting arbitrary properties.  We're talking about
the difference between:

  call.invokeBlocking("op", omElement, sequenceKey);


  call.set("myRM.SequenceKey", sequenceKey);
  call.invokeBlocking("op", omElement);

It's a little more typing, but it's *much* cleaner architecturally to do
the second style.  Let's keep the Axis2 core APIs as simple and
independent of "aspects" like reliability/transactions/security as
possible, and just make sure that it's easy to pass and receive
information to/from Modules via both the client and server APIs.  Going
the first route heads down what I fear is a slipperly slope to adding
transactional context, etc., directly to our APIs when the point of
Axis2 is to be able to compose these things arbitrarily.

Note also that the original idea of Modules was to not only deploy
Handlers, but also to do cool stuff like:
- Recognizing particular WSDL extensions (i.e. policies) and activating
- Affecting WSDL generation (writing policies/extensions) for services
- Affecting codegen of stubs

We're not there yet with any of this, but that last one would give you
what you're looking for from generated stubs at least.  The idea would
be when the RM Module saw that RM was in use for a given WSDL, it would
not only cause the correct handler deployments at runtime, it would also
be able to change the client APIs - so for a non-databound stub you
could have:

interface MyStub {
  OMElement someOperation(OMElement input, SequenceKey sequenceKey);

3. MessageTracker

I need to think about this a little more, but again I can see doing most
of this without adding more machinery.  If you need to pass something to
the RM engine, you can always do it like this:

  call.set("RM.messageTracker", myMessageTracker);
  call.invokeNonBlocking("op", omElement, callback);

And if you need info at callback time, you've got access to the
MessageContext and the RM engine can put stuff in there for you.

So my preference is not to put this kind of stuff into the base APIs but
use it as a test of how well our base APIs (designed for just this kind
of flexibility) can handle adding arbitrary extra functionality via


> -----Original Message-----
> From: Paul Fremantle [] 
> Sent: Friday, October 28, 2005 9:24 AM
> To:;
> Subject: [Axis2] Implications of WSRM interfaces on Axis2 ClientAPI
> I've been thinking about how Sandesha and Axis 2 should 
> interact and how people can code to Axis2 with the idea in 
> mind that they might be reliable later. I've just been asked 
> a couple of times how can the code find out if a message has 
> been delivered. 
> This is an interesting issue. I used to believe it that RM 
> shouldn't have any impact on the Axis2 client api in normal 
> usage, because I want to be able to turn on or off WSRM 
> without having to change my application code. 
> But there are some aspects that require some interaction with 
> the application. The first one is knowing how to associate 
> messages with a particular reliable sequence. For example, I 
> may have multiple stubs running in an application server on 
> behalf of multiple clients. I could aggregate all the 
> requests into a single sequence, which will be more efficient 
> in terms of the protocol, and the overhead of managing large 
> numbers of sequences. But if the endpoint is doing ordered 
> delivery, it now may end up holding up messages from one 
> client while messages for another are delivered, which might 
> not be the desired behaviour.
> Sandesha uses a simple idea called a SequenceKey. The key is 
> simply a marker that the application code can use to help 
> create the right underlying sequences. If there are multiple 
> stubs or Call objects that use the same SequenceKey, then as 
> long as they are targeted at the same endpoint, Sandesha will 
> aggregate them into the same sequence. On the other hand, if 
> you have two stubs with different SequenceKeys going to the 
> same endpoint, they will each have their own sequence.
> I think this is a great model, it is simple and clean and 
> effective. In fact I think it is so good, that we should 
> always code this way - even if we aren't using RM yet. If the 
> SequenceKey Constant was in the base Axis2 ClientAPI, we 
> could code now with this in mind, so when we want RM, just 
> flick the switch. Of course if you don't set a SequenceKey, 
> the Sandesha can have a default behaviour.
> The same applies to the idea of a LastMessage. Sandesha lets 
> you mark a message as being the last in a sequence. This is 
> something that generally only the application designer can 
> know, so again I think it would be great to promote the 
> LastMessage constant onto the standard ClientAPI.
> The final issue is letting the application know how the RM 
> delivery is getting on. In general we would like to trust 
> that every message is delivered successfully, but things 
> happen. There will be occasions where timeliness is also 
> important. I see two potential approaches for this. The first 
> is to expose via a management interface a view of the whole 
> sequence. So in Java, we could make the sequence manageable 
> via JMX. And if we make the SequenceKey part of that 
> management, then the application could use it to help map 
> from the application logic into the underlying sequence. 
> However, there is a more fundamental model, which is when 
> I've made a non-blocking call, I want to know whether that 
> made it through. And in fact this is something that is useful 
> even without RM. Take a simple HTTP case: if the call is 
> truly non-blocking, it could execute the initial send on a 
> new thread, and then I will want to know whether there was an 
> HTTP 202 return or some other. I may also want to know other 
> information from a non-blocking call - such as the messageId 
> that was allocated to the outbound message.
> So this also seems to be a model we could promote to the base 
> Call API in Axis2 (and elsewhere).
> Currently the Axis2 API is 
> void invokeNonBlocking(op, element, callback) 
> My suggestion is to add a new return parameter:
> MessageTracker invokeNonBlocking(op, element, callback)
> The MessageTracker would only track the outgoing message - 
> the callback object tracks the response. 
> A simple interface might be something like: 
> public interface MessageTracker {
>      public boolean isAcked();
>      public String getMessageID();
>      public boolean isReliable();
>      public boolean isUndeliverable();
> }
> The isAcked() is fairly clear. If this was a non-reliable 
> interaction, this would just indicate that there was a 202 
> from the server. In the reliable instance this would indicate 
> the message had been acked. 
> The isUndeliverable() would indicate that the message will 
> never be delivered. In the case of non-reliable, this would 
> be where there was a fault on the send. In the case of 
> reliable, this would mean the sequence was terminated or 
> closed before this message was acked.
> The isReliable() could be used to find out if some reliable 
> messaging standard is in use, to help make sense of the ack state.
> And as I point out earlier, this could be useful even for 
> non-reliable requests, because we could make the nonBlocking 
> call not even wait for the request to be sent, and still 
> track whether it succeeded. 
> Paul
> PS This is a slightly modified version of a blog entry 

View raw message