axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glen Daniels" <gdani...@macromedia.com>
Subject Re: Session support
Date Sat, 26 May 2001 23:01:22 GMT
Actually, I'd make a slightly stronger statement here.

There are (and, IMO, need to be) changes to the higher level Axis
architecture to support sessions.  They are necessary because you want a
good session abstraction that allows your service to save "session-related"
stuff someplace common (the SessionContext that Rob mentioned).  Otherwise
you have to have some way of knowing which pieces of data in the
MessageContext bag are associated with the session in some custom way,
right?

I think it should work just about as Rob outlined it.  It's up to anyone on
the entire server-side input chain (transport, global, or service) to pull
some 'key' out of the message and associate that with a particular
SessionContext.  That could be an HTTP header, a SOAP header, a part of the
URL.... The Axis framework should provide a place to store SessionContexts,
and a way to look them up and expire them.

Then a session-aware service just calls getSessionContext() on the
MessageContext to obtain a place where it can put session data.  Some
handler on the output chain (again, service, global, or transport) knows how
to map that to a "specific" sessionID form.

So while sending the right transport-related stuff is up to the transport, I
think we want a transport-independent session management system.  It's
simple, elegant, and extensible.

--Glen

----- Original Message -----
From: "Rob Jellinghaus" <robj@unrealities.com>
To: <axis-dev@xml.apache.org>; <axis-dev@xml.apache.org>
Sent: Friday, May 25, 2001 5:02 PM
Subject: Re: Session support


> 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 :-)
> Cheers,
> Rob
>
> 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
> >it
> >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.
> >
> >-Dug
> >
> >----- Original Message -----
> >From: "Rob Jellinghaus" <robj@unrealities.com>
> >To: <axis-dev@xml.apache.org>
> >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
> >the
> >> 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 @yahoo.com address at http://mail.yahoo.com
> >
> >
> >
>


Mime
View raw message