axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "duglin" <dug...@yahoo.com>
Subject Re: Session support
Date Fri, 25 May 2001 19:20:51 GMT
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


Mime
View raw message