The problem comes when we have to group messages that does not exactly fit into any mep. For example users can define a group that expand several meps. In this case there is no way to detect the Last Message using the mep. Also it is very possible for a sequence to end in the middle of a mep. So we cannot use the MEP to detect the end of the sequence and thats why the LAST_MESSAGE property has to be set.
Other thing is currently the call.set () method set the properties directly to the configuration context. So even though we set it in the call the property is not limited to the call and the property value can servive throught multiple number of Call objects and MessageSenders (by sharing the configuration context). Your argument could have been valid if call.set () method set properties in the operationContext instead of the configurationContext.
Thanx,
Chamikara
On 10/30/05, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
This is just a thought came to my mind about the LastMessage.
Facts :
1.ON-OUT MEP is very clear about the messages. Server receives a message (client sends a message), Server sends out a message (Client receives a message).
2. Call API represents IN-ONLY MEP interaction.
==>it shoould be used to send a message and get the response back.
So I feel there is no notion of Last Message w.r.t. Call api, at least logically. You have ONLY two message, one goes out and one comes in. So I see there is no reason to add a way for the Call to set a last message. Some one from higher level should handle that.
Just a thought.
Paul Fremantle wrote:Guys
I agree we don't want to add RM specific APIs to Axis2. However, as I think
my long post, and Chamikara's much neater append point out, there is a way
of looking at these as being general concepts in WS and not specific RM
concepts. In fact the Key concept is something that the Sandesha guys
invented and is not part of the RM spec. I believe that the same Key and
Last Message concepts could also help when you switch on
WS-SecureConversation. They are just basic ideas about how WS works when not
everything is a single call and we start building conversations.
What is driving this is a belief in COMPOSABILITY. Composability should mean
not having to change my code for a given WS-* standard. But it also means
that the core model has to support composability. WS-Security was lucky, we
didn't need to change any code, but its also inefficient, so we've had to
invent SecureConversation. I think that the idea of sequences and
conversations are generic new change the core model of WS and should be
reflected in the Axis2 API.
Paul
On 10/29/05, Jaliya Ekanayake <[EMAIL PROTECTED]> wrote:
I agree, that we don't need RM methods without RM. jar, but if we analsye
the common requirements from RM or WS-SecCon etc, we may endup with
maximum
5-10 new setters for the call API. Afterall these moduels are intended for
axis and it will be easy and clear for the users to use them in the Call
API
rather than having another Context or some other Object to transfer
properties.
Thanks,
Jaliya
----- Original Message -----
From: "Srinath Perera" <[EMAIL PROTECTED]>
To: <axis-dev@ws.apache.org>
Sent: Saturday, October 29, 2005 10:11 AM
Subject: Re: [Axis2] Implications of WSRM interfaces on Axis2 ClientAPI
why u need RM methods when u do not have RM jar in the classpath?
On 10/29/05, Jaliya Ekanayake <[EMAIL PROTECTED]> wrote:
This is what we have in Sandesha 1.0. It introduce this new RMContext
that
requires the jar to be in the classpath.
Thanks,
Jaliya
----- Original Message -----
From: "Srinath Perera" <[EMAIL PROTECTED]>
To: <axis-dev@ws.apache.org>
Sent: Saturday, October 29, 2005 7:37 AM
Subject: Re: [Axis2] Implications of WSRM interfaces on Axis2 ClientAPI
I am 0- on moving the constants to the core
how about following
Call call = new Call();
call.engageModule("RM");
RMContext rcontext = (RMContext)call.getExtentionContext(RM_MODULE);
//return the RMContext from extension registry
RMContext will have RM specific methods and provide way to monitor the
RM
IMHO once the user enable RM, user is not allowed to set sequence id
ect .. at the first message RM will automatically call create sequence
..ect and provide sequenceIDs/UUID for the messages. Once the RM is
started Axis and RM control what happen .. User can quary status via
RMContext .. He may have a terminateSequence method() .. for premature
termination
Thanks
Srinath
