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:23:13 GMT
This is something we really need to think long and hard about
before taking any steps towards - this is heading towards
duplicating the work already being done by the environment
in which Axis is running (ie. a servlet engine).  Once you start
talking about Axis managing sessions then you need to ask, ok,
so what happens when Axis goes down?  Shouldn't we store
this session stuff in a DB?  And what about cases where 2 Axis
engines access the same session context - how do we deal with
sync'ing em up?  Or what if the engines are running on two different
machine (due to load balancing) but you want sessions to
be available from all of those servers?
This is definately _not_ something we should think about for v1
(if at all) people are already working on these things and they're
called servlet engines, EJB containers...  I really don't think we
need to duplicate their work.
-Dug

----- Original Message -----
From: "Glen Daniels" <gdaniels@macromedia.com>
To: <axis-dev@xml.apache.org>
Sent: Saturday, May 26, 2001 7:01 PM
Subject: Re: Session support


> 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