axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Jellinghaus <>
Subject Re: Session support
Date Fri, 25 May 2001 21:02:55 GMT
Yes, I guess I wasn't explicit: nothing in my proposal requires changing
anything in Axis whatsoever.  This is all at the handler level.  It sounds
like you're pretty much agreeing with my proposal -- I think most of what
you say is pretty much the same stuff I was proposing, albeit in slightly
different terms.  Check?

Anyway, I'll charge ahead :-)

At 03:20 PM 5/25/2001 -0400, duglin wrote:
>On the server side:
>    I don't think we need to change anything in Axis this should all be done
>by a handler on the Transport specific chain and that handler should place
>whatever session stuff it deems necessary into the MsgContext bag.  Then
>anyone else in the chain can add/modify whatever it wants by going to the
>bag.  When control is returned to the Transport specific output chain, or
>to the transport listener itself (in the http case) can then grab whatever
>wants from the MsgContext bag.  None of this requires anything beyond
>what's already there, except adding more code to the AxisServlet to put
>and pull info from the MsgContext.
>On the client side:
>  This again seems like something that should be handled within the
>transport chain Putting things into the HTTP headers and
>grabbing things from the HTTP headers and placing
>them in the MsgContext seems like Transport specific chain stuff.
>The HTTPCall object already has a MsgContext so when we reuse
>the same call object we should automagically still have the session info
>in there from the previous call.
>So, I guess I'm in favor of this support, but keep the logic/code changes
>to inside the transport specific handlers.
>----- Original Message -----
>From: "Rob Jellinghaus" <>
>To: <>
>Sent: Friday, May 25, 2001 2:40 PM
>Subject: Session support
>> OK, so a configurable listener daemon isn't a core part of Axis (and, I
>> sense, isn't on most folks' hot list for 1.0).  That's cool.  But what
>> would you say to session support???  :-)
>> I worked up a proposal for handling sessions and bounced it off of Glen.
>> Briefly, the proposal is:
>> - we add a sessionContext field to the MessageContext
>> - this sessionContext can be filled in on the server side by a handler
>> (either on the service chain, or by the service itself)
>> - the sessionContext gets passed back through the output chain, and
>> transformed into whatever is appropriate (either into a cookie /
>> rewritten-URL by the transport output handler / listener, or put directly
>> into the envelope by a service output handler)
>> - the client side output chain recreates the sessionContext from the
>> transport / envelope state
>> - the ServiceClient object (formerly named ClientCall, before that
>> HTTPCall) obtains the sessionContext from the outbound response's
>> MessageContext, and saves it for use in future calls
>> I diagrammed this at Glen's request.  Diagrams attached.
>> I think this has a few nice properties:
>> - It shares the Apache SOAP pattern of "use the same Call object to use
>> same session".
>> - It abstracts the session state away from the details of a particular
>> transport.
>> - It allows a lot of flexibility in arranging handlers to get the desired
>> session semantics.
>> Whatchall think?  Let's see how many overlapping design discussions we can
>> get going at once!!!  :-)
>> Cheers,
>> Rob
>Do You Yahoo!?
>Get your free address at

View raw message