Fwd: Redefine Session Context -> Message Sequence Context| WAS [Axis2] Implications of WSRM interfaces on Axis2 ClientAPI

[Srinath Perera <he...@gmail.com>]

Hi All;

I think in the RM Client API discussion we are talking about
composition of messages that are in higer level than MEPs. For an
example in RM or Sec-Conversation we could want to invoke set of
operations securly and/or Reliably. So we need to capture a Sequence
of messages that would span over number of MEPs.

I think we need to capture this in our Context hierachy! and then only
provide the Clinet API support.

In that case we need to incoperate the "Message Sequnce" in to our
context hierachy. I think the "Message Sequence" is our loosly defined
Session context.

I think life of develepers and users would be much better if Axis
automatically group the messages in a MessageSequnce together in the
same way we did to the MEP.

thoughts

Srinath




On 10/30/05, Eran Chinthaka <ch...@opensource.lk> 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 <ja...@opensource.lk> 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" <he...@gmail.com>
> To: <ax...@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 <ja...@opensource.lk> 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" <he...@gmail.com>
> To: <ax...@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
>
>
>
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org

Re: Redefine Session Context -> Message Sequence Context| WAS [Axis2] Implications of WSRM interfaces on Axis2 ClientAPI

[Paul Fremantle <pz...@gmail.com>]

Steve

When I said "as one way" I meant one way that a customer can *choose* to
make the association. I 100% agree that Axis should not hide stuff in
ThreadLocal without the coder choosing to.

Paul

On 10/31/05, Steve Loughran <st...@apache.org> wrote:
>
> Paul Fremantle wrote:
> > Srinath
> >
> > Sounds perfect to me. In fact, it seems to me that maybe we want some
> > different ways of creating the association. For example, we may wish to
> use
> > ThreadLocal as one way. But in general you are completely right - lets
> not
> > think of this as a two rather RM specific markers, but think about how
> to
> > start and end a context.
>
>
> ThreadLocal scares me. What if I create the message in the GUI thread
> but queue it to the workers for execution?
> which thread would be used. This is not hypothetical BTW, it is exactly
> how I do long-haul in-out operations.
>
> -steve
>

Re: Redefine Session Context -> Message Sequence Context| WAS [Axis2] Implications of WSRM interfaces on Axis2 ClientAPI

[Steve Loughran <st...@apache.org>]

Paul Fremantle wrote:
> Srinath
> 
> Sounds perfect to me. In fact, it seems to me that maybe we want some
> different ways of creating the association. For example, we may wish to use
> ThreadLocal as one way. But in general you are completely right - lets not
> think of this as a two rather RM specific markers, but think about how to
> start and end a context.


ThreadLocal scares me. What if I create the message in the GUI thread 
but queue it to the workers for execution?
which thread would be used. This is not hypothetical BTW, it is exactly 
how I do long-haul in-out operations.

-steve

Redefine Session Context -> Message Sequence Context| WAS [Axis2] Implications of WSRM interfaces on Axis2 ClientAPI

[Paul Fremantle <pz...@gmail.com>]

Srinath

Sounds perfect to me. In fact, it seems to me that maybe we want some
different ways of creating the association. For example, we may wish to use
ThreadLocal as one way. But in general you are completely right - lets not
think of this as a two rather RM specific markers, but think about how to
start and end a context.

I wish I'd thought of that :-)

Paul

On 10/30/05, Srinath Perera <he...@gmail.com> wrote:
>
> Hi All;
>
> I think in the RM Client API discussion we are talking about
> composition of messages that are in higer level than MEPs. For an
> example in RM or Sec-Conversation we could want to invoke set of
> operations securly and/or Reliably. So we need to capture a Sequence
> of messages that would span over number of MEPs.
>
> I think we need to capture this in our Context hierachy! and then only
> provide the Clinet API support.
>
> In that case we need to incoperate the "Message Sequnce" in to our
> context hierachy. I think the "Message Sequence" is our loosly defined
> Session context.
>
> I think life of develepers and users would be much better if Axis
> automatically group the messages in a MessageSequnce together in the
> same way we did to the MEP.
>
> thoughts
>
> Srinath
>
>
>
>
> On 10/30/05, Eran Chinthaka <ch...@opensource.lk> 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 < jaliya@opensource.lk> 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" <he...@gmail.com>
> > To: <ax...@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 <ja...@opensource.lk> 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" <he...@gmail.com>
> > To: <ax...@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
> >
> >
> >
> >
> >
> >
> >
> >
>