axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "duglin" <dug...@yahoo.com>
Subject Re: Session support
Date Sun, 27 May 2001 02:05:34 GMT
I would prefer if we made this session stuff transport specific,
so please place this "bag" ID in the HTTP constants.  Having
it global like this will make it harder when/if we ever have
to deal with multiple transports at one time.
-Dug

----- Original Message -----
From: "Rob Jellinghaus" <robj@unrealities.com>
To: <axis-dev@xml.apache.org>; <axis-dev@xml.apache.org>
Sent: Saturday, May 26, 2001 8:48 PM
Subject: Re: Session support


> My first stab at this introduces only one new property name into the
> MessageContext:
>
> static public String SESSION_CONTEXT = "session.context";
>
> i.e. now there is one new property in the bag (as Doug calls it) for
> whatever session info wants to be stored there.  (could be a
sub-hashtable,
> could be just a String in the initial implementation.)
>
> I'll do only this until more is proved necessary.  (and certainly only
this
> in the first checkin.)
>
> Cheers!
> Rob
>
>
> At 07:01 PM 5/26/2001 -0400, Glen Daniels wrote:
> >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
> >> >
> >> >
> >> >
> >>
> >
> >
> >


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


Mime
View raw message