axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Jellinghaus <r...@unrealities.com>
Subject Re: Session support
Date Sun, 27 May 2001 18:07:59 GMT
At 09:59 PM 5/27/2001 +0900, Yuhichi Nakamura wrote:
>I just look at StatefullEJB in ApacheSOAP.  I got the idea.
>First of all, HTTP session should be supported, and is supported already.
>(Right?)

Wrong!  There's no current Axis support for HTTP sessions (cookies, etc.).
If I'm wrong about this please let me know!  Adding such support is pretty
much all I'm trying to do.

>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.

Keep me posted.  In some sense, many providers (i.e. EJB providers) *are*
stateful (i.e. they have state relating to sessions in them).  All I'm
trying to do is to create a general mechanism for routing session-related
information from the transport to the provider.  I'm *not* trying to create
any notion of session where none yet exists; I'm just trying to lit
information about the already-existing sessions (transport session /
provider session) be routed through Axis.  (Still waiting for James to
explain why that's something that can be dealt with solely at the app
server level....)

And yes, this is all very much along the lines of StatefulEJB.

Cheers,
Rob



>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