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 05:35:15 GMT
The point here is that the EJB will need some incoming information to
determine what EJB key to work with.  I would store that information (the
EJB key) in the SESSION_CONTEXT field in the bag.  That *is* the relevant
session information in the EJB case.  Did you look at the diagrams in my
original email?  They clearly show session state being kept in the
provider, and referenced based on the sessionID (== EJB key) passed in in
the MessageContext.

If you don't put the EJB key in the bag, then what state *do* you pass via
the MessageContext (from the transport chain) to the EJB provider, to
determine what EJB key to use?

Basically, I am thinking of MessageContext.SESSION_CONTEXT as a field for
holding whatever state the *provider* needs to determine the message's
session.  If there is some transport-specific conversion of this
provider-specific SESSION_CONTEXT, then the input/output transport chains
can easily do that transformation (and store the results in
HTTPConstants.HTTP_SESSION_CONTEXT or whatever we like).

I think we're in, not violent, but certainly serious agreement here :-)

Cheers,
Rob

At 10:17 PM 5/26/2001 -0400, duglin wrote:
>When it comes to EJBs keep in mind that session support
>might need to be done differently.  I don't see EJB sessions
>being done as a transport handler, but rather done within
>the pivot point's handler.  EJB services would have an EJB
>dispatcher (in v2 it was the EJB pluggable provider) and
>that dispatcher would have to look for the EJB session
>information (ie. ejb key) someplace (probably in a header
>or in the v2 case in the target object uri).  In this scenario
>there would be no need to use any session fields in the
>bag because the fact that we're dealing with an EJB instead
>of just a normal java class is (and should remain) hidden to
>everyone but the dispatcher (or at most the service specific
>chain handlers).
>-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 9:48 PM
>Subject: Re: Session support
>
>
>> The first example I check in (or send to the list, which is as close as I
>> can come until my apache account shows up) will be a totally roll-your-own
>> session example.  Then I will work on integrating it with servlet session
>> handling.  After that I will at least figure out enough about EJB session
>> support to know that it *can* work.  Any specific recommendations for
>other
>> high-priority providers?  (no promises -- I haven't got tons of space on
>my
>> home machine for app server type testing, and I have some other
>> priorities....)
>>
>> Cheers,
>> Rob
>>
>>
>> At 08:49 PM 5/26/2001 +0900, Yuhichi Nakamura wrote:
>> >
>> >Rob,
>> >I just wondered how server-side handlers work when they got a meesage
>> >with a familiar session id.  I know that session management is a very
>> >common
>> >concept especially in HTTP case.  Some example are really appreciated.
>> >Best regards,
>> >
>> >Yuhichi Nakamura
>> >IBM Tokyo Research Laboratory
>> >Tel: +81-462-73-4668
>> >
>> >
>> >From: Rob Jellinghaus <robj@unrealities.com> on 2001/05/26 06:02
>> >
>> >Please respond to axis-dev@xml.apache.org
>> >
>> >To:   axis-dev@xml.apache.org, axis-dev@xml.apache.org
>> >cc:
>> >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