axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Fremantle <>
Subject Re: [Axis2] Implications of WSRM interfaces on Axis2 ClientAPI
Date Fri, 28 Oct 2005 17:24:42 GMT

I wasn't clear. Sorry. I also agree with Glen's comments :-)

What I'm actually asking is that we move

from: org.apache.sandesha.Constants.ClientProperties
String LAST_MESSAGE = "lastMessage";
String CALL_KEY = "callKey";

into org.apache.axis2.Constants.

I am talking about using the property model, so +1 to Glen absolutely. I was
really meaning that unless we can make these part of the core ClientAPI,
then we can't support switching RM on later.

As for #3, I agree that Glen's model would work too. I prefer mine, because
it seems a basic thing to track how a request is going in the same way the
Callback object is a core part of the method signature not a property.


On 10/28/05, Eran Chinthaka <> wrote:
> A BIG +1 from me for Glen's comments.
> As Glen explained the base API should be as simple as possible and it
> should not depend on any of the things like security/transaction/RM, etc,
> Paul, why do you wanna do that (I know you must be having a good reason),
> when you can do the same thing using call.setProperty(key,value) ? Are you
> suggesting Axis2 to give integrated or first class support to RM ?
> -- Chinthaka
> Glen Daniels wrote:
> 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);
> and
>   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
> appropriately
> - 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
> extensions.
> --Glen
>    -----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