You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by Sanjiva Weerawarana <sa...@opensource.lk> on 2005/12/06 09:32:24 UTC
Re: [Axis2] Implications of WSRM interfaces on Axis2 ClientAPI
Hi Guys,
I'm cleaning up my mailbox a bit (long flight) and ran into this thread.
I see that it hasn't concluded. I like this last proposal by Chamikara -
have two "session" like hints that a user can assert via Call (or
another MEP client). In fact, we may need exactly something like this to
deal with garbage collection on the client side. Otherwise we have no
way to know when to remove a service context on the client side. (I'm
working on an analysis of garbage collection issues .. hopefully will
get it done today.)
Sanjiva.
On Sat, 2005-10-29 at 19:11 +0600, Chamikara Jayalath wrote:
> H Dims,
>
> If it is aboug moving something specific to RM into Axis2 I will also
> totally disagree. But if we look in a different point of view some of
> these constants convey a general idea that is not at all specific to
> RM.
>
> LAST_MESSAGE
>
> This simply indicate that the next invocation is the Last Message of
> the set of messages currently being invoked. This is not something
> specific to RM. RM module will use this to put the
> <wsrm:lastMessage /> tag. Some other module may use it to do its own
> operation that has to be done for the last message of a set of
> messages.
>
>
> SEQUNCE_KEY
>
> This simply is used to group messages that are aimed at the same
> destination. Even though the wsa:To is the same, if SEQUENCE_KEY (or
> we can rename this to MESSAGE_SET_ID) is different the messages can be
> identified as belonging to two different groups. Again this is not
> something specific to RM. Some other module that need to group
> messages can also use this.
>
>
> That was the idea. But if u guys do not see these as general enough to
> be moved to Axis2 Constants lets keep them in Sandesha2, till some
> other module that need the same concepts ask for it :)
>
> Thanx,
> Chamikara
>
>
>
>
> On 10/29/05, Davanum Srinivas <da...@gmail.com> wrote:
> Chamikara,
>
> In the generated code when RM module is engaged, we can
> generate what
> we want. Am -0 to this proposal. I don't agree that the
> constants
> should move to the core itself. If we start doing this we have
> to be
> consistent and do the same for wss4j, kandula and others.
>
> thanks,
> dims
>
> On 10/29/05, Chamikara Jayalath <ch...@gmail.com> wrote:
> > Hi All,
> >
> > Actually this is the way we have currently developed the
> client API for
> > Sandesha2. I hope following bit of code will clarify the
> issue.
> >
> > Call call = new Call(AXIS2_CLIENT_PATH);
> > call.engageModule(new QName("sandesha"));
> > call.setTo(new EndpointReference(toEPR));
> >
> call.set(org.apache.sandesha2.Constants.SEQUENCE_KEY,"sequence1");
> > //Optional
> > call.set
> (org.apache.sandesha2.Constants.OFFERED_SEQUENCE_ID,newUUID);
> > //Optional
> > Callback callback1 = new TestCallback ("Callback 1");
> > call.invokeNonBlocking("echoString",
> omElemennt1,callback1);
> > call.set(org.apache.sandesha2.Constants.LAST_MESSAGE,
> "true");
> > Callback callback2 = new TestCallback ("Callback 2");
> > call.invokeNonBlocking("echoString",
> omElement2,callback2);
> >
> >
> > All we are asking is to move the given constants from
> > org.apache.sandesha2.Constants to
> org.apache.axis2.Constants. So that the
> > client does not have to include the Sandesha2 jar file
> everytime he write
> > the client code.
> >
> > Thanx,
> > Chamikara
> >
> >
> > On 10/28/05, Eran Chinthaka <ch...@opensource.lk> 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 [mailto:pzfreo@gmail.com]
> > > Sent: Friday, October 28, 2005 9:24 AM
> > >
> > > To: axis-dev@ws.apache.org;
> > > sandesha-dev@ws.apache.org
> > > 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
> > >
> > > http://www.bloglines.com/blog/paulfremantle?id=16
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>
> --
> Davanum Srinivas : http://wso2.com/blogs/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail:
> sandesha-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [Axis2] Implications of WSRM interfaces on Axis2 ClientAPI
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Paul, Sanjiva, All,
I believe Sanjiava is talking abt something like this.
Call call = new Call ();
Options options = new Options ();
call.setOptions (options);
call.setOption (Constants.SEQUENCE_KEY,"sequence1");
..
..
..
call.invoke (envelope1);
call.invoke (envelope2);
options.setProperty (Constants.LAST_MESSAGE,"true");
call.invoke (envelope3);
//Now we can get rid of the ServiceContext
But this might be not enough to do the garbage collection properly. The use
of sequenceKey is to support grouping of messages. Consider following
example,
Call call = new Call ();
Options options = new Options ();
call.setOptions (options);
call.setOption (Constants.SEQUENCE_KEY,"sequence1");
call.invoke (envelope1);
..
call.setOption (Constants.SEQUENCE_KEY,"sequence2");
call.invoke (envelope2);
..
call.setOption (Constants.SEQUENCE_KEY,"sequence1");
options.setProperty (Constants.LAST_MESSAGE,"true");
call.invoke (envelope3);
..
call.setOption (Constants.SEQUENCE_KEY,"sequence2");
options.setProperty (Constants.LAST_MESSAGE,"true");
call.invoke (envelope4);
Since there can be several message groups, there will be several Last
Messages. When to garbage problem is still there :(
Going in to Pauls comment on removal of the LastMessage property, I believe
still we have to set this in the client API. This is because to finalize
things (to deallocate resource and to send the terminate) we still have to
know when the sequene end and only client knows this.
Thanx,
Chamikara
On 12/7/05, Paul Fremantle <pzfreo@gmail.com > wrote:
>
> In fact the problem of explicitly knowing the Last message may go away
> because the WS-RX committee voted last week to remove the LastMessage from
> the spec. However, you do need to know when the sequence has ended - the
> only thing was before you needed to know before you sent the last message --
> now at least you can decide after which is much easier.
>
> You still need the sequence key as well.
>
> I *think* I understand Chamikara's proposal - if I haven't got it wrong
> then I also like it. Chamikara can you please give us a code example?
>
> Paul
>
> On 12/6/05, Sanjiva Weerawarana <sanjiva@opensource.lk > wrote:
> >
> > Hi Guys,
> >
> > I'm cleaning up my mailbox a bit (long flight) and ran into this thread.
> >
> > I see that it hasn't concluded. I like this last proposal by Chamikara -
> > have two "session" like hints that a user can assert via Call (or
> > another MEP client). In fact, we may need exactly something like this to
> > deal with garbage collection on the client side. Otherwise we have no
> > way to know when to remove a service context on the client side. (I'm
> > working on an analysis of garbage collection issues .. hopefully will
> > get it done today.)
> >
> > Sanjiva.
> >
> > On Sat, 2005-10-29 at 19:11 +0600, Chamikara Jayalath wrote:
> > > H Dims,
> > >
> > > If it is aboug moving something specific to RM into Axis2 I will also
> > > totally disagree. But if we look in a different point of view some of
> > > these constants convey a general idea that is not at all specific to
> > > RM.
> > >
> > > LAST_MESSAGE
> > >
> > > This simply indicate that the next invocation is the Last Message of
> > > the set of messages currently being invoked. This is not something
> > > specific to RM. RM module will use this to put the
> > > <wsrm:lastMessage /> tag. Some other module may use it to do its own
> > > operation that has to be done for the last message of a set of
> > > messages.
> > >
> > >
> > > SEQUNCE_KEY
> > >
> > > This simply is used to group messages that are aimed at the same
> > > destination. Even though the wsa:To is the same, if SEQUENCE_KEY (or
> > > we can rename this to MESSAGE_SET_ID) is different the messages can be
> > > identified as belonging to two different groups. Again this is not
> > > something specific to RM. Some other module that need to group
> > > messages can also use this.
> > >
> > >
> > > That was the idea. But if u guys do not see these as general enough to
> > > be moved to Axis2 Constants lets keep them in Sandesha2, till some
> > > other module that need the same concepts ask for it :)
> > >
> > > Thanx,
> > > Chamikara
> > >
> > >
> > >
> > >
> > > On 10/29/05, Davanum Srinivas < davanum@gmail.com> wrote:
> > > Chamikara,
> > >
> > > In the generated code when RM module is engaged, we can
> > > generate what
> > > we want. Am -0 to this proposal. I don't agree that the
> > > constants
> > > should move to the core itself. If we start doing this we have
> >
> > > to be
> > > consistent and do the same for wss4j, kandula and others.
> > >
> > > thanks,
> > > dims
> > >
> > > On 10/29/05, Chamikara Jayalath < chamikaramj@gmail.com>
> > wrote:
> > > > Hi All,
> > > >
> > > > Actually this is the way we have currently developed the
> > > client API for
> > > > Sandesha2. I hope following bit of code will clarify the
> > > issue.
> > > >
> > > > Call call = new Call(AXIS2_CLIENT_PATH);
> > > > call.engageModule(new QName("sandesha"));
> > > > call.setTo(new EndpointReference(toEPR));
> > > >
> > > call.set(org.apache.sandesha2.Constants.SEQUENCE_KEY
> > ,"sequence1");
> > > > //Optional
> > > > call.set
> > > (org.apache.sandesha2.Constants.OFFERED_SEQUENCE_ID ,newUUID);
> > > > //Optional
> > > > Callback callback1 = new TestCallback ("Callback 1");
> > > > call.invokeNonBlocking("echoString",
> > > omElemennt1,callback1);
> > > > call.set(org.apache.sandesha2.Constants.LAST_MESSAGE,
> > > "true");
> > > > Callback callback2 = new TestCallback ("Callback 2");
> > > > call.invokeNonBlocking ("echoString",
> > > omElement2,callback2);
> > > >
> > > >
> > > > All we are asking is to move the given constants from
> > > > org.apache.sandesha2.Constants to
> > > org.apache.axis2.Constants. So that the
> > > > client does not have to include the Sandesha2 jar file
> > > everytime he write
> > > > the client code.
> > > >
> > > > Thanx,
> > > > Chamikara
> > > >
> > > >
> > > > On 10/28/05, Eran Chinthaka < chinthaka@opensource.lk >
> > 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 [mailto: pzfreo@gmail.com]
> > > > > Sent: Friday, October 28, 2005 9:24 AM
> > > > >
> > > > > To: axis-dev@ws.apache.org;
> > > > > sandesha-dev@ws.apache.org
> > > > > 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
> > > > >
> > > > > http://www.bloglines.com/blog/paulfremantle?id=16
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Davanum Srinivas : http://wso2.com/blogs/
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail:
> > > sandesha-dev-help@ws.apache.org
> > >
> > >
> >
> >
>
Re: [Axis2] Implications of WSRM interfaces on Axis2 ClientAPI
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Paul, Sanjiva, All,
I believe Sanjiava is talking abt something like this.
Call call = new Call ();
Options options = new Options ();
call.setOptions (options);
call.setOption (Constants.SEQUENCE_KEY,"sequence1");
..
..
..
call.invoke (envelope1);
call.invoke (envelope2);
options.setProperty (Constants.LAST_MESSAGE,"true");
call.invoke (envelope3);
//Now we can get rid of the ServiceContext
But this might be not enough to do the garbage collection properly. The use
of sequenceKey is to support grouping of messages. Consider following
example,
Call call = new Call ();
Options options = new Options ();
call.setOptions (options);
call.setOption (Constants.SEQUENCE_KEY,"sequence1");
call.invoke (envelope1);
..
call.setOption (Constants.SEQUENCE_KEY,"sequence2");
call.invoke (envelope2);
..
call.setOption (Constants.SEQUENCE_KEY,"sequence1");
options.setProperty (Constants.LAST_MESSAGE,"true");
call.invoke (envelope3);
..
call.setOption (Constants.SEQUENCE_KEY,"sequence2");
options.setProperty (Constants.LAST_MESSAGE,"true");
call.invoke (envelope4);
Since there can be several message groups, there will be several Last
Messages. When to garbage problem is still there :(
Going in to Pauls comment on removal of the LastMessage property, I believe
still we have to set this in the client API. This is because to finalize
things (to deallocate resource and to send the terminate) we still have to
know when the sequene end and only client knows this.
Thanx,
Chamikara
On 12/7/05, Paul Fremantle <pzfreo@gmail.com > wrote:
>
> In fact the problem of explicitly knowing the Last message may go away
> because the WS-RX committee voted last week to remove the LastMessage from
> the spec. However, you do need to know when the sequence has ended - the
> only thing was before you needed to know before you sent the last message --
> now at least you can decide after which is much easier.
>
> You still need the sequence key as well.
>
> I *think* I understand Chamikara's proposal - if I haven't got it wrong
> then I also like it. Chamikara can you please give us a code example?
>
> Paul
>
> On 12/6/05, Sanjiva Weerawarana <sanjiva@opensource.lk > wrote:
> >
> > Hi Guys,
> >
> > I'm cleaning up my mailbox a bit (long flight) and ran into this thread.
> >
> > I see that it hasn't concluded. I like this last proposal by Chamikara -
> > have two "session" like hints that a user can assert via Call (or
> > another MEP client). In fact, we may need exactly something like this to
> > deal with garbage collection on the client side. Otherwise we have no
> > way to know when to remove a service context on the client side. (I'm
> > working on an analysis of garbage collection issues .. hopefully will
> > get it done today.)
> >
> > Sanjiva.
> >
> > On Sat, 2005-10-29 at 19:11 +0600, Chamikara Jayalath wrote:
> > > H Dims,
> > >
> > > If it is aboug moving something specific to RM into Axis2 I will also
> > > totally disagree. But if we look in a different point of view some of
> > > these constants convey a general idea that is not at all specific to
> > > RM.
> > >
> > > LAST_MESSAGE
> > >
> > > This simply indicate that the next invocation is the Last Message of
> > > the set of messages currently being invoked. This is not something
> > > specific to RM. RM module will use this to put the
> > > <wsrm:lastMessage /> tag. Some other module may use it to do its own
> > > operation that has to be done for the last message of a set of
> > > messages.
> > >
> > >
> > > SEQUNCE_KEY
> > >
> > > This simply is used to group messages that are aimed at the same
> > > destination. Even though the wsa:To is the same, if SEQUENCE_KEY (or
> > > we can rename this to MESSAGE_SET_ID) is different the messages can be
> > > identified as belonging to two different groups. Again this is not
> > > something specific to RM. Some other module that need to group
> > > messages can also use this.
> > >
> > >
> > > That was the idea. But if u guys do not see these as general enough to
> > > be moved to Axis2 Constants lets keep them in Sandesha2, till some
> > > other module that need the same concepts ask for it :)
> > >
> > > Thanx,
> > > Chamikara
> > >
> > >
> > >
> > >
> > > On 10/29/05, Davanum Srinivas < davanum@gmail.com> wrote:
> > > Chamikara,
> > >
> > > In the generated code when RM module is engaged, we can
> > > generate what
> > > we want. Am -0 to this proposal. I don't agree that the
> > > constants
> > > should move to the core itself. If we start doing this we have
> >
> > > to be
> > > consistent and do the same for wss4j, kandula and others.
> > >
> > > thanks,
> > > dims
> > >
> > > On 10/29/05, Chamikara Jayalath < chamikaramj@gmail.com>
> > wrote:
> > > > Hi All,
> > > >
> > > > Actually this is the way we have currently developed the
> > > client API for
> > > > Sandesha2. I hope following bit of code will clarify the
> > > issue.
> > > >
> > > > Call call = new Call(AXIS2_CLIENT_PATH);
> > > > call.engageModule(new QName("sandesha"));
> > > > call.setTo(new EndpointReference(toEPR));
> > > >
> > > call.set(org.apache.sandesha2.Constants.SEQUENCE_KEY
> > ,"sequence1");
> > > > //Optional
> > > > call.set
> > > (org.apache.sandesha2.Constants.OFFERED_SEQUENCE_ID ,newUUID);
> > > > //Optional
> > > > Callback callback1 = new TestCallback ("Callback 1");
> > > > call.invokeNonBlocking("echoString",
> > > omElemennt1,callback1);
> > > > call.set(org.apache.sandesha2.Constants.LAST_MESSAGE,
> > > "true");
> > > > Callback callback2 = new TestCallback ("Callback 2");
> > > > call.invokeNonBlocking ("echoString",
> > > omElement2,callback2);
> > > >
> > > >
> > > > All we are asking is to move the given constants from
> > > > org.apache.sandesha2.Constants to
> > > org.apache.axis2.Constants. So that the
> > > > client does not have to include the Sandesha2 jar file
> > > everytime he write
> > > > the client code.
> > > >
> > > > Thanx,
> > > > Chamikara
> > > >
> > > >
> > > > On 10/28/05, Eran Chinthaka < chinthaka@opensource.lk >
> > 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 [mailto: pzfreo@gmail.com]
> > > > > Sent: Friday, October 28, 2005 9:24 AM
> > > > >
> > > > > To: axis-dev@ws.apache.org;
> > > > > sandesha-dev@ws.apache.org
> > > > > 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
> > > > >
> > > > > http://www.bloglines.com/blog/paulfremantle?id=16
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Davanum Srinivas : http://wso2.com/blogs/
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail:
> > > sandesha-dev-help@ws.apache.org
> > >
> > >
> >
> >
>
Re: [Axis2] Implications of WSRM interfaces on Axis2 ClientAPI
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Paul, Sanjiva, All,
I believe Sanjiava is talking abt something like this.
Call call = new Call ();
Options options = new Options ();
call.setOptions (options);
call.setOption (Constants.SEQUENCE_KEY,"sequence1");
..
..
..
call.invoke (envelope1);
call.invoke (envelope2);
options.setProperty (Constants.LAST_MESSAGE,"true");
call.invoke (envelope3);
//Now we can get rid of the ServiceContext
But this might be not enough to do the garbage collection properly. The use
of sequenceKey is to support grouping of messages. Consider following
example,
Call call = new Call ();
Options options = new Options ();
call.setOptions (options);
call.setOption (Constants.SEQUENCE_KEY,"sequence1");
call.invoke (envelope1);
..
call.setOption (Constants.SEQUENCE_KEY,"sequence2");
call.invoke (envelope2);
..
call.setOption (Constants.SEQUENCE_KEY,"sequence1");
options.setProperty (Constants.LAST_MESSAGE,"true");
call.invoke (envelope3);
..
call.setOption (Constants.SEQUENCE_KEY,"sequence2");
options.setProperty (Constants.LAST_MESSAGE,"true");
call.invoke (envelope4);
Since there can be several message groups, there will be several Last
Messages. When to garbage problem is still there :(
Going in to Pauls comment on removal of the LastMessage property, I believe
still we have to set this in the client API. This is because to finalize
things (to deallocate resource and to send the terminate) we still have to
know when the sequene end and only client knows this.
Thanx,
Chamikara
On 12/7/05, Paul Fremantle <pzfreo@gmail.com > wrote:
>
> In fact the problem of explicitly knowing the Last message may go away
> because the WS-RX committee voted last week to remove the LastMessage from
> the spec. However, you do need to know when the sequence has ended - the
> only thing was before you needed to know before you sent the last message --
> now at least you can decide after which is much easier.
>
> You still need the sequence key as well.
>
> I *think* I understand Chamikara's proposal - if I haven't got it wrong
> then I also like it. Chamikara can you please give us a code example?
>
> Paul
>
> On 12/6/05, Sanjiva Weerawarana <sanjiva@opensource.lk > wrote:
> >
> > Hi Guys,
> >
> > I'm cleaning up my mailbox a bit (long flight) and ran into this thread.
> >
> > I see that it hasn't concluded. I like this last proposal by Chamikara -
> > have two "session" like hints that a user can assert via Call (or
> > another MEP client). In fact, we may need exactly something like this to
> > deal with garbage collection on the client side. Otherwise we have no
> > way to know when to remove a service context on the client side. (I'm
> > working on an analysis of garbage collection issues .. hopefully will
> > get it done today.)
> >
> > Sanjiva.
> >
> > On Sat, 2005-10-29 at 19:11 +0600, Chamikara Jayalath wrote:
> > > H Dims,
> > >
> > > If it is aboug moving something specific to RM into Axis2 I will also
> > > totally disagree. But if we look in a different point of view some of
> > > these constants convey a general idea that is not at all specific to
> > > RM.
> > >
> > > LAST_MESSAGE
> > >
> > > This simply indicate that the next invocation is the Last Message of
> > > the set of messages currently being invoked. This is not something
> > > specific to RM. RM module will use this to put the
> > > <wsrm:lastMessage /> tag. Some other module may use it to do its own
> > > operation that has to be done for the last message of a set of
> > > messages.
> > >
> > >
> > > SEQUNCE_KEY
> > >
> > > This simply is used to group messages that are aimed at the same
> > > destination. Even though the wsa:To is the same, if SEQUENCE_KEY (or
> > > we can rename this to MESSAGE_SET_ID) is different the messages can be
> > > identified as belonging to two different groups. Again this is not
> > > something specific to RM. Some other module that need to group
> > > messages can also use this.
> > >
> > >
> > > That was the idea. But if u guys do not see these as general enough to
> > > be moved to Axis2 Constants lets keep them in Sandesha2, till some
> > > other module that need the same concepts ask for it :)
> > >
> > > Thanx,
> > > Chamikara
> > >
> > >
> > >
> > >
> > > On 10/29/05, Davanum Srinivas < davanum@gmail.com> wrote:
> > > Chamikara,
> > >
> > > In the generated code when RM module is engaged, we can
> > > generate what
> > > we want. Am -0 to this proposal. I don't agree that the
> > > constants
> > > should move to the core itself. If we start doing this we have
> >
> > > to be
> > > consistent and do the same for wss4j, kandula and others.
> > >
> > > thanks,
> > > dims
> > >
> > > On 10/29/05, Chamikara Jayalath < chamikaramj@gmail.com>
> > wrote:
> > > > Hi All,
> > > >
> > > > Actually this is the way we have currently developed the
> > > client API for
> > > > Sandesha2. I hope following bit of code will clarify the
> > > issue.
> > > >
> > > > Call call = new Call(AXIS2_CLIENT_PATH);
> > > > call.engageModule(new QName("sandesha"));
> > > > call.setTo(new EndpointReference(toEPR));
> > > >
> > > call.set(org.apache.sandesha2.Constants.SEQUENCE_KEY
> > ,"sequence1");
> > > > //Optional
> > > > call.set
> > > (org.apache.sandesha2.Constants.OFFERED_SEQUENCE_ID ,newUUID);
> > > > //Optional
> > > > Callback callback1 = new TestCallback ("Callback 1");
> > > > call.invokeNonBlocking("echoString",
> > > omElemennt1,callback1);
> > > > call.set(org.apache.sandesha2.Constants.LAST_MESSAGE,
> > > "true");
> > > > Callback callback2 = new TestCallback ("Callback 2");
> > > > call.invokeNonBlocking ("echoString",
> > > omElement2,callback2);
> > > >
> > > >
> > > > All we are asking is to move the given constants from
> > > > org.apache.sandesha2.Constants to
> > > org.apache.axis2.Constants. So that the
> > > > client does not have to include the Sandesha2 jar file
> > > everytime he write
> > > > the client code.
> > > >
> > > > Thanx,
> > > > Chamikara
> > > >
> > > >
> > > > On 10/28/05, Eran Chinthaka < chinthaka@opensource.lk >
> > 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 [mailto: pzfreo@gmail.com]
> > > > > Sent: Friday, October 28, 2005 9:24 AM
> > > > >
> > > > > To: axis-dev@ws.apache.org;
> > > > > sandesha-dev@ws.apache.org
> > > > > 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
> > > > >
> > > > > http://www.bloglines.com/blog/paulfremantle?id=16
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Davanum Srinivas : http://wso2.com/blogs/
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail:
> > > sandesha-dev-help@ws.apache.org
> > >
> > >
> >
> >
>
Re: [Axis2] Implications of WSRM interfaces on Axis2 ClientAPI
Posted by Paul Fremantle <pz...@gmail.com>.
In fact the problem of explicitly knowing the Last message may go away
because the WS-RX committee voted last week to remove the LastMessage from
the spec. However, you do need to know when the sequence has ended - the
only thing was before you needed to know before you sent the last message --
now at least you can decide after which is much easier.
You still need the sequence key as well.
I *think* I understand Chamikara's proposal - if I haven't got it wrong then
I also like it. Chamikara can you please give us a code example?
Paul
On 12/6/05, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>
> Hi Guys,
>
> I'm cleaning up my mailbox a bit (long flight) and ran into this thread.
>
> I see that it hasn't concluded. I like this last proposal by Chamikara -
> have two "session" like hints that a user can assert via Call (or
> another MEP client). In fact, we may need exactly something like this to
> deal with garbage collection on the client side. Otherwise we have no
> way to know when to remove a service context on the client side. (I'm
> working on an analysis of garbage collection issues .. hopefully will
> get it done today.)
>
> Sanjiva.
>
> On Sat, 2005-10-29 at 19:11 +0600, Chamikara Jayalath wrote:
> > H Dims,
> >
> > If it is aboug moving something specific to RM into Axis2 I will also
> > totally disagree. But if we look in a different point of view some of
> > these constants convey a general idea that is not at all specific to
> > RM.
> >
> > LAST_MESSAGE
> >
> > This simply indicate that the next invocation is the Last Message of
> > the set of messages currently being invoked. This is not something
> > specific to RM. RM module will use this to put the
> > <wsrm:lastMessage /> tag. Some other module may use it to do its own
> > operation that has to be done for the last message of a set of
> > messages.
> >
> >
> > SEQUNCE_KEY
> >
> > This simply is used to group messages that are aimed at the same
> > destination. Even though the wsa:To is the same, if SEQUENCE_KEY (or
> > we can rename this to MESSAGE_SET_ID) is different the messages can be
> > identified as belonging to two different groups. Again this is not
> > something specific to RM. Some other module that need to group
> > messages can also use this.
> >
> >
> > That was the idea. But if u guys do not see these as general enough to
> > be moved to Axis2 Constants lets keep them in Sandesha2, till some
> > other module that need the same concepts ask for it :)
> >
> > Thanx,
> > Chamikara
> >
> >
> >
> >
> > On 10/29/05, Davanum Srinivas <da...@gmail.com> wrote:
> > Chamikara,
> >
> > In the generated code when RM module is engaged, we can
> > generate what
> > we want. Am -0 to this proposal. I don't agree that the
> > constants
> > should move to the core itself. If we start doing this we have
> > to be
> > consistent and do the same for wss4j, kandula and others.
> >
> > thanks,
> > dims
> >
> > On 10/29/05, Chamikara Jayalath <ch...@gmail.com> wrote:
> > > Hi All,
> > >
> > > Actually this is the way we have currently developed the
> > client API for
> > > Sandesha2. I hope following bit of code will clarify the
> > issue.
> > >
> > > Call call = new Call(AXIS2_CLIENT_PATH);
> > > call.engageModule(new QName("sandesha"));
> > > call.setTo(new EndpointReference(toEPR));
> > >
> > call.set(org.apache.sandesha2.Constants.SEQUENCE_KEY
> ,"sequence1");
> > > //Optional
> > > call.set
> > (org.apache.sandesha2.Constants.OFFERED_SEQUENCE_ID,newUUID);
> > > //Optional
> > > Callback callback1 = new TestCallback ("Callback 1");
> > > call.invokeNonBlocking("echoString",
> > omElemennt1,callback1);
> > > call.set(org.apache.sandesha2.Constants.LAST_MESSAGE,
> > "true");
> > > Callback callback2 = new TestCallback ("Callback 2");
> > > call.invokeNonBlocking("echoString",
> > omElement2,callback2);
> > >
> > >
> > > All we are asking is to move the given constants from
> > > org.apache.sandesha2.Constants to
> > org.apache.axis2.Constants. So that the
> > > client does not have to include the Sandesha2 jar file
> > everytime he write
> > > the client code.
> > >
> > > Thanx,
> > > Chamikara
> > >
> > >
> > > On 10/28/05, Eran Chinthaka <ch...@opensource.lk> 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 [mailto:pzfreo@gmail.com]
> > > > Sent: Friday, October 28, 2005 9:24 AM
> > > >
> > > > To: axis-dev@ws.apache.org;
> > > > sandesha-dev@ws.apache.org
> > > > 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
> > > >
> > > > http://www.bloglines.com/blog/paulfremantle?id=16
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Davanum Srinivas : http://wso2.com/blogs/
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail:
> > sandesha-dev-help@ws.apache.org
> >
> >
>
>
Re: [Axis2] Implications of WSRM interfaces on Axis2 ClientAPI
Posted by Paul Fremantle <pz...@gmail.com>.
In fact the problem of explicitly knowing the Last message may go away
because the WS-RX committee voted last week to remove the LastMessage from
the spec. However, you do need to know when the sequence has ended - the
only thing was before you needed to know before you sent the last message --
now at least you can decide after which is much easier.
You still need the sequence key as well.
I *think* I understand Chamikara's proposal - if I haven't got it wrong then
I also like it. Chamikara can you please give us a code example?
Paul
On 12/6/05, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>
> Hi Guys,
>
> I'm cleaning up my mailbox a bit (long flight) and ran into this thread.
>
> I see that it hasn't concluded. I like this last proposal by Chamikara -
> have two "session" like hints that a user can assert via Call (or
> another MEP client). In fact, we may need exactly something like this to
> deal with garbage collection on the client side. Otherwise we have no
> way to know when to remove a service context on the client side. (I'm
> working on an analysis of garbage collection issues .. hopefully will
> get it done today.)
>
> Sanjiva.
>
> On Sat, 2005-10-29 at 19:11 +0600, Chamikara Jayalath wrote:
> > H Dims,
> >
> > If it is aboug moving something specific to RM into Axis2 I will also
> > totally disagree. But if we look in a different point of view some of
> > these constants convey a general idea that is not at all specific to
> > RM.
> >
> > LAST_MESSAGE
> >
> > This simply indicate that the next invocation is the Last Message of
> > the set of messages currently being invoked. This is not something
> > specific to RM. RM module will use this to put the
> > <wsrm:lastMessage /> tag. Some other module may use it to do its own
> > operation that has to be done for the last message of a set of
> > messages.
> >
> >
> > SEQUNCE_KEY
> >
> > This simply is used to group messages that are aimed at the same
> > destination. Even though the wsa:To is the same, if SEQUENCE_KEY (or
> > we can rename this to MESSAGE_SET_ID) is different the messages can be
> > identified as belonging to two different groups. Again this is not
> > something specific to RM. Some other module that need to group
> > messages can also use this.
> >
> >
> > That was the idea. But if u guys do not see these as general enough to
> > be moved to Axis2 Constants lets keep them in Sandesha2, till some
> > other module that need the same concepts ask for it :)
> >
> > Thanx,
> > Chamikara
> >
> >
> >
> >
> > On 10/29/05, Davanum Srinivas <da...@gmail.com> wrote:
> > Chamikara,
> >
> > In the generated code when RM module is engaged, we can
> > generate what
> > we want. Am -0 to this proposal. I don't agree that the
> > constants
> > should move to the core itself. If we start doing this we have
> > to be
> > consistent and do the same for wss4j, kandula and others.
> >
> > thanks,
> > dims
> >
> > On 10/29/05, Chamikara Jayalath <ch...@gmail.com> wrote:
> > > Hi All,
> > >
> > > Actually this is the way we have currently developed the
> > client API for
> > > Sandesha2. I hope following bit of code will clarify the
> > issue.
> > >
> > > Call call = new Call(AXIS2_CLIENT_PATH);
> > > call.engageModule(new QName("sandesha"));
> > > call.setTo(new EndpointReference(toEPR));
> > >
> > call.set(org.apache.sandesha2.Constants.SEQUENCE_KEY
> ,"sequence1");
> > > //Optional
> > > call.set
> > (org.apache.sandesha2.Constants.OFFERED_SEQUENCE_ID,newUUID);
> > > //Optional
> > > Callback callback1 = new TestCallback ("Callback 1");
> > > call.invokeNonBlocking("echoString",
> > omElemennt1,callback1);
> > > call.set(org.apache.sandesha2.Constants.LAST_MESSAGE,
> > "true");
> > > Callback callback2 = new TestCallback ("Callback 2");
> > > call.invokeNonBlocking("echoString",
> > omElement2,callback2);
> > >
> > >
> > > All we are asking is to move the given constants from
> > > org.apache.sandesha2.Constants to
> > org.apache.axis2.Constants. So that the
> > > client does not have to include the Sandesha2 jar file
> > everytime he write
> > > the client code.
> > >
> > > Thanx,
> > > Chamikara
> > >
> > >
> > > On 10/28/05, Eran Chinthaka <ch...@opensource.lk> 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 [mailto:pzfreo@gmail.com]
> > > > Sent: Friday, October 28, 2005 9:24 AM
> > > >
> > > > To: axis-dev@ws.apache.org;
> > > > sandesha-dev@ws.apache.org
> > > > 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
> > > >
> > > > http://www.bloglines.com/blog/paulfremantle?id=16
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Davanum Srinivas : http://wso2.com/blogs/
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail:
> > sandesha-dev-help@ws.apache.org
> >
> >
>
>
Re: [Axis2] Implications of WSRM interfaces on Axis2 ClientAPI
Posted by Paul Fremantle <pz...@gmail.com>.
In fact the problem of explicitly knowing the Last message may go away
because the WS-RX committee voted last week to remove the LastMessage from
the spec. However, you do need to know when the sequence has ended - the
only thing was before you needed to know before you sent the last message --
now at least you can decide after which is much easier.
You still need the sequence key as well.
I *think* I understand Chamikara's proposal - if I haven't got it wrong then
I also like it. Chamikara can you please give us a code example?
Paul
On 12/6/05, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
>
> Hi Guys,
>
> I'm cleaning up my mailbox a bit (long flight) and ran into this thread.
>
> I see that it hasn't concluded. I like this last proposal by Chamikara -
> have two "session" like hints that a user can assert via Call (or
> another MEP client). In fact, we may need exactly something like this to
> deal with garbage collection on the client side. Otherwise we have no
> way to know when to remove a service context on the client side. (I'm
> working on an analysis of garbage collection issues .. hopefully will
> get it done today.)
>
> Sanjiva.
>
> On Sat, 2005-10-29 at 19:11 +0600, Chamikara Jayalath wrote:
> > H Dims,
> >
> > If it is aboug moving something specific to RM into Axis2 I will also
> > totally disagree. But if we look in a different point of view some of
> > these constants convey a general idea that is not at all specific to
> > RM.
> >
> > LAST_MESSAGE
> >
> > This simply indicate that the next invocation is the Last Message of
> > the set of messages currently being invoked. This is not something
> > specific to RM. RM module will use this to put the
> > <wsrm:lastMessage /> tag. Some other module may use it to do its own
> > operation that has to be done for the last message of a set of
> > messages.
> >
> >
> > SEQUNCE_KEY
> >
> > This simply is used to group messages that are aimed at the same
> > destination. Even though the wsa:To is the same, if SEQUENCE_KEY (or
> > we can rename this to MESSAGE_SET_ID) is different the messages can be
> > identified as belonging to two different groups. Again this is not
> > something specific to RM. Some other module that need to group
> > messages can also use this.
> >
> >
> > That was the idea. But if u guys do not see these as general enough to
> > be moved to Axis2 Constants lets keep them in Sandesha2, till some
> > other module that need the same concepts ask for it :)
> >
> > Thanx,
> > Chamikara
> >
> >
> >
> >
> > On 10/29/05, Davanum Srinivas <da...@gmail.com> wrote:
> > Chamikara,
> >
> > In the generated code when RM module is engaged, we can
> > generate what
> > we want. Am -0 to this proposal. I don't agree that the
> > constants
> > should move to the core itself. If we start doing this we have
> > to be
> > consistent and do the same for wss4j, kandula and others.
> >
> > thanks,
> > dims
> >
> > On 10/29/05, Chamikara Jayalath <ch...@gmail.com> wrote:
> > > Hi All,
> > >
> > > Actually this is the way we have currently developed the
> > client API for
> > > Sandesha2. I hope following bit of code will clarify the
> > issue.
> > >
> > > Call call = new Call(AXIS2_CLIENT_PATH);
> > > call.engageModule(new QName("sandesha"));
> > > call.setTo(new EndpointReference(toEPR));
> > >
> > call.set(org.apache.sandesha2.Constants.SEQUENCE_KEY
> ,"sequence1");
> > > //Optional
> > > call.set
> > (org.apache.sandesha2.Constants.OFFERED_SEQUENCE_ID,newUUID);
> > > //Optional
> > > Callback callback1 = new TestCallback ("Callback 1");
> > > call.invokeNonBlocking("echoString",
> > omElemennt1,callback1);
> > > call.set(org.apache.sandesha2.Constants.LAST_MESSAGE,
> > "true");
> > > Callback callback2 = new TestCallback ("Callback 2");
> > > call.invokeNonBlocking("echoString",
> > omElement2,callback2);
> > >
> > >
> > > All we are asking is to move the given constants from
> > > org.apache.sandesha2.Constants to
> > org.apache.axis2.Constants. So that the
> > > client does not have to include the Sandesha2 jar file
> > everytime he write
> > > the client code.
> > >
> > > Thanx,
> > > Chamikara
> > >
> > >
> > > On 10/28/05, Eran Chinthaka <ch...@opensource.lk> 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 [mailto:pzfreo@gmail.com]
> > > > Sent: Friday, October 28, 2005 9:24 AM
> > > >
> > > > To: axis-dev@ws.apache.org;
> > > > sandesha-dev@ws.apache.org
> > > > 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
> > > >
> > > > http://www.bloglines.com/blog/paulfremantle?id=16
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Davanum Srinivas : http://wso2.com/blogs/
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail:
> > sandesha-dev-help@ws.apache.org
> >
> >
>
>