You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Rob Jellinghaus <ro...@unrealities.com> on 2001/05/25 20:40:31 UTC
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
Re: Session support
Posted by Rob Jellinghaus <ro...@unrealities.com>.
After reading this & your other message, I see your main concern: there's
no such thing as a generic notion of "session". (and the word "context"
was also confusing you; I definitely *didn't* mean it to be transport
specific.) I'll rename the global constant to MessageContext.SESSION_STATE
and I'll be ready to move it down to something like EJBProvider.EJB_KEY if
it turns out to be problematic.
Cheers,
Rob
At 07:13 AM 5/27/2001 -0400, duglin wrote:
>If there are transport independent things (ie. userId, ejbKey)
>then yes those can go into the msgContext bag and the constants can
>be global. SessionContext itself (ie. "servletContext") is
>transport specific and should not be in the global constants
>and that's why I don't like the idea of a "SESSION_CONTEXT"
>field in the bag - that one _is_ transport dependent.
>-Dug
>
>----- Original Message -----
>From: "Rob Jellinghaus" <ro...@unrealities.com>
>To: <ax...@xml.apache.org>; <ax...@xml.apache.org>
>Sent: Sunday, May 27, 2001 1:30 AM
>Subject: Re: Session support
>
>
>> Then there would be no way to write generic handlers that deal with
>> sessions independent of what transport is being used. Right now it'll be
>> easy to write (say) an RPCDispatcher (actually, RPCProvider) that can deal
>> with holding session state regardless of which transports use it. If we
>> have per-transport session state, that's not possible.
>>
>> In general, the notion of a session is *not* coupled to the notion of a
>> transport. If there *is* transport-specific session state, we can
>> certainly *also* have HTTPConstants.SESSION_CONTEXT in addition to
>> MessageContext.SESSION_CONTEXT, but my preference would be that (as much
>as
>> feasible) we try to keep the transport-specific stuff restricted to the
>> transport chain handlers only.
>>
>> Cheers,
>> Rob
>>
>> At 10:05 PM 5/26/2001 -0400, duglin wrote:
>> >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" <ro...@unrealities.com>
>> >To: <ax...@xml.apache.org>; <ax...@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" <ro...@unrealities.com>
>> >> >To: <ax...@xml.apache.org>; <ax...@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" <ro...@unrealities.com>
>> >> >> >To: <ax...@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
>
>
>
Re: Session support
Posted by duglin <du...@yahoo.com>.
If there are transport independent things (ie. userId, ejbKey)
then yes those can go into the msgContext bag and the constants can
be global. SessionContext itself (ie. "servletContext") is
transport specific and should not be in the global constants
and that's why I don't like the idea of a "SESSION_CONTEXT"
field in the bag - that one _is_ transport dependent.
-Dug
----- Original Message -----
From: "Rob Jellinghaus" <ro...@unrealities.com>
To: <ax...@xml.apache.org>; <ax...@xml.apache.org>
Sent: Sunday, May 27, 2001 1:30 AM
Subject: Re: Session support
> Then there would be no way to write generic handlers that deal with
> sessions independent of what transport is being used. Right now it'll be
> easy to write (say) an RPCDispatcher (actually, RPCProvider) that can deal
> with holding session state regardless of which transports use it. If we
> have per-transport session state, that's not possible.
>
> In general, the notion of a session is *not* coupled to the notion of a
> transport. If there *is* transport-specific session state, we can
> certainly *also* have HTTPConstants.SESSION_CONTEXT in addition to
> MessageContext.SESSION_CONTEXT, but my preference would be that (as much
as
> feasible) we try to keep the transport-specific stuff restricted to the
> transport chain handlers only.
>
> Cheers,
> Rob
>
> At 10:05 PM 5/26/2001 -0400, duglin wrote:
> >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" <ro...@unrealities.com>
> >To: <ax...@xml.apache.org>; <ax...@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" <ro...@unrealities.com>
> >> >To: <ax...@xml.apache.org>; <ax...@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" <ro...@unrealities.com>
> >> >> >To: <ax...@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
Re: Session support
Posted by Rob Jellinghaus <ro...@unrealities.com>.
Then there would be no way to write generic handlers that deal with
sessions independent of what transport is being used. Right now it'll be
easy to write (say) an RPCDispatcher (actually, RPCProvider) that can deal
with holding session state regardless of which transports use it. If we
have per-transport session state, that's not possible.
In general, the notion of a session is *not* coupled to the notion of a
transport. If there *is* transport-specific session state, we can
certainly *also* have HTTPConstants.SESSION_CONTEXT in addition to
MessageContext.SESSION_CONTEXT, but my preference would be that (as much as
feasible) we try to keep the transport-specific stuff restricted to the
transport chain handlers only.
Cheers,
Rob
At 10:05 PM 5/26/2001 -0400, duglin wrote:
>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" <ro...@unrealities.com>
>To: <ax...@xml.apache.org>; <ax...@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" <ro...@unrealities.com>
>> >To: <ax...@xml.apache.org>; <ax...@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" <ro...@unrealities.com>
>> >> >To: <ax...@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
>
>
>
Re: Session support
Posted by duglin <du...@yahoo.com>.
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" <ro...@unrealities.com>
To: <ax...@xml.apache.org>; <ax...@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" <ro...@unrealities.com>
> >To: <ax...@xml.apache.org>; <ax...@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" <ro...@unrealities.com>
> >> >To: <ax...@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
Re: Session support
Posted by Rob Jellinghaus <ro...@unrealities.com>.
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" <ro...@unrealities.com>
>To: <ax...@xml.apache.org>; <ax...@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" <ro...@unrealities.com>
>> >To: <ax...@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
>> >
>> >
>> >
>>
>
>
>
Re: Session support
Posted by duglin <du...@yahoo.com>.
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" <gd...@macromedia.com>
To: <ax...@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" <ro...@unrealities.com>
> To: <ax...@xml.apache.org>; <ax...@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" <ro...@unrealities.com>
> > >To: <ax...@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
Re: Session support
Posted by Glen Daniels <gd...@macromedia.com>.
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" <ro...@unrealities.com>
To: <ax...@xml.apache.org>; <ax...@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" <ro...@unrealities.com>
> >To: <ax...@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
> >
> >
> >
>
Re: Session support
Posted by Rob Jellinghaus <ro...@unrealities.com>.
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" <ro...@unrealities.com>
>To: <ax...@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
>
>
>
Re: Session support
Posted by duglin <du...@yahoo.com>.
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" <ro...@unrealities.com>
To: <ax...@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