axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yuhichi Nakamura" <NAKAM...@jp.ibm.com>
Subject Re: Session support
Date Sun, 27 May 2001 12:59:24 GMT

I just look at StatefullEJB in ApacheSOAP.  I got the idea.
First of all, HTTP session should be supported, and is supported already.
(Right?)
As for EJB (and stateful Java object also?), we may have to first consider
requirements and some use cases.  The idea you mentioned seems
fine, but I want to make sure with a proper discussion.  So far I consider
that services (handler chains) are stateless, aka session less.  We can
make them statefull just by adding a property (object id).  Well...
I am not sure if this is ok in ANY cases.  Let me consider.

Best regards,

Yuhichi Nakamura
IBM Tokyo Research Laboratory
Tel: +81-462-73-4668


From: "duglin" <duglin@yahoo.com> on 2001/05/27 20:38

Please respond to axis-dev@xml.apache.org

To:   <axis-dev@xml.apache.org>
cc:
Subject:  Re: Session support



  Rob your code (that pulls data - whether you call it session stuff
or not - and places it in the "bag") is fine I don't think there's a
problem with that.  Personally, I just don't think you can have a
"sessionContext" field since there is no concept of "session" in
Axis.  All of the fields you want to pick-up are either transport
dependent (ie servletContext) and should have transport dependent
names in the bag, or are transport independent and have more
specific names than "session", like ejbKey.   Yes "ejbKey" is sort
of like a "session" but that data (to Axis) isn't session/context
information - that's information that will be used by the dispatcher
to make sure that the WebService will be executed properly because
the WebService might have the notion of a session.   It might seem
like a fine line but it is there.  Please look at the v2 ejb code to see
how it isolates the ejbKey stuff within the pluggable provider - I see
something very similar in Axis.  Remember, when someone switches
their WebService from a java class to an EJB it would really be nice
if all they had to do was change the disptach handler from
JavaRPCDispatcher
to EJBDispatcher and nothing else.  The EJBDispatcher would not
only grab the method invocation stuff from the body but would also
grab the ejbKey from a header as well.  I don't see any transport or
global chain changes being required (ideally service specific too but that
could be an implementation choice).
  Introducing the notion of a session (beyond the MsgContext
variable itself) inside of Axis has some very serious issues around it,
and they are introduced by Glen's proposal not yours.  For yours I
think I just have a problem with the naming of things because it
could lead to confusion.  Does "SESSION_CONTEXT" mean the
incoming transport session or the outgoing transport session, or some
other session that might have been used someplace else in the chain?
-Dug

----- Original Message -----
From: "Rob Jellinghaus" <robj@unrealities.com>
To: <axis-dev@xml.apache.org>; <axis-dev@xml.apache.org>
Sent: Sunday, May 27, 2001 1:41 AM
Subject: Re: Session support


> Wow, this is spiraling quite a bit.
>
> The ONLY point of my changes was to provide some way of conveying session
> information sent over a transport (i.e. a cookie, a rewritten URL, a SOAP
> header) through Axis to a provider (i.e. the interface to an app
server!).
> Perhaps I don't understand the way an app server would utilize Axis (and
if
> so, please enlighten me ASAP, or point me at a reference whence I can
> enlighten myself).  But at the moment I don't see how transport-specific
> session state (cookie, SOAP header, whatever) could make it to a provider
> (EJBProvider, RPCProvider, etc.) if Axis doesn't *somehow* pass
*something*
> through the chains.
>
> (Additionally, Apache SOAP provides application, session, and per-message
> lifetimes for services, even when running outside an app server.  Are we
> saying that Axis will not have even this level of functionality?)
>
> Really, you guys, this is not very much code!  Maybe I should have just
> written it and submitted it so people could see how small it is?  It
> affects *very* few files and is totally modularized.
>
> Anyway, I'll quit in this thread for now, I'll submit it ASAP, and you
guys
> can take a look and decide whether I'm right in calling it small and
> simple.  If you can convince me it's totally not necessary, please do!
And
> either way I will be on to something more useful within three days.
>
> Cheers,
> Rob
>
> At 08:48 PM 5/26/2001 -0700, James M Snell wrote:
> >Y'all let's keep this simple:  Axis needs to only do one thing -- parse
> >incoming messages and delegate the handling of those message to
something
> >else.  Sure, we need to make Axis flexible and pluggable, but let's not
> >reinvent the whole damn app server model here.  Sessions can be managed
by
> >the application server.
> >
> >- James Snell
> >     Software Engineer, Emerging Technologies, IBM
> >     jasnell@us.ibm.com (online)
> >     jsnell@lemoorenet.com (offline)
> >
> >Please respond to axis-dev@xml.apache.org
> >To:     <axis-dev@xml.apache.org>
> >cc:
> >Subject:        Re: Session support
> >
> >
> >
> >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
> >
> >
> >
> >
> >


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





Mime
View raw message