geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Summary? was: Session API....
Date Sat, 11 Mar 2006 20:23:32 GMT
On Mar 9, 2006, at 4:09 AM, Jules Gosnell wrote:

> David Blevins wrote:
>
>> Sorry, was referring to this thread.  Seems like it's winding  
>> down  and just looking for a clear idea of what the current  
>> thinking is.
>
> Hi David - allow me to wind it up again :-)
>
> I am particularly interested in your thoughts/requirements about a  
> Session management API for OpenEJB... You seemed to have remained a  
> little quiet on this thread...

It's a tough topic to digest in the form of lots of little emails.  I  
really appreciate the time you put into this summary.

I think I'm getting a lot of what you are saying.  I have to admit, I  
still can't imagine it all in my head just yet.  I like the concept  
that clients can be made smarter or store information that will make  
the cluster that much more efficient.  But I'm not sure what you'd  
need me to do for clients that are out of our control and potentially  
written in an entirely different language, i.e. CORBA and Web Services.

Can you describe what considerations I'd have to add on my side of  
the fence to make that work?

-David


>
> Here we go:
>
>
> Guys,
>
> Firstly, I think a unified Session API is a good thing - it's
> something that I have been working towards in WADI for sometime.
>
> Secondly, I have many issues with this one :-)
>
> It may be that I have misunderstood aspects of this API and I am open
> to correction where this has happened.
>
> All observations are off the top of my head - since I until I actually
> try to put WADI behind this API, I am not going to discover the full
> breadth of my problems.
>
> To keep things as simple as possible, I am only going to go for the
> big money... I'll make 3 points, then illustrate them.
>
> 1)
>
> I would like to see a very clear distinction between what I call the
> 'Session API' (The API used between the container -
> Jetty/Tomcat/OpenEJB etc - and Geronimo, for Session creation,
> destruction and retrieval), what Greg is calling the 'Policy' SPI
> (The stuff that worries about things like the location of a Session
> and whether it is Local or Remote) and what I guess is your current
> 'Policy' implementation.
>
> I see the successful definition of the 'Session API' component as the
> most important of these. The 'Policy SPI' is going to be more
> contentious - your current API and implementation seem quite closely
> bound and present a number of issues for WADI.
>
> 2)
>
> I think that the issue of session colocation should not be exposed in
> the 'Session API' component. I see this very much as a pluggable
> implementation detail, that is irrelevant to the container using the
> API. The implementation behind the API will be in full control of
> creation of the Key, the Session, the Session lifecycle and Session
> storage. I do not see why you need to expose any detail of your
> internal mechanisms to the Session consumer.
>
> 3)
>
> I think that you are completely omitting one of the key players from
> this API. The Invocation. The goal of successful Session management is
> that Invocation and Session should meet somewhere in the cluster for
> the successful rendering/processing of a page/rpc/whatever. The
> Invocation carries all the information that you may wish to a)
> intercept and process elsewhere, b) pass onto the Session management
> layer to aid in its decision making upon creation, retrieval and
> invalidation of a Session. Depending on how responsibilities are split
> between client container and Session manager, the session management
> layer may actually want to modify the return values in this
> Invocation - adding removing session cookies/attributes, changing ttls
> upon this attribute, changing the value of this attribute or altering
> other information within the Invocation that is used to integrate it
> better with the Client at the other end of the wire. All these
> interactions should be opaque to the client-container
> (Jetty/TC/OpenEJB/...) and depend entirely on the implementation of
> the Client (or e.g. Http loadbalancer) and the session management
> layer.
>
> Illustrations :
>
> 1). I don't think that the Location of a Session if of any relevance
> to the Consumer. Jetty/TC/OpenEJB are simply interested in looking up
> a Session and using it. A number of classes in
> org.apache.geronimo.session talk in terms of Location. I see Location
> as an implementation detail. WADI will have trouble mapping to some of
> the assumptions that appear to be made in this part of the
> API. e.g. Locator.getSessionLocation() is not an efficient thing to do
> in WADI. It involves a round-trip to the owner of this section of the
> Location Map. When WADI wants to move a Session it sends a message to
> this node, which sends a message to the owner of the Session, which
> sends a message containing the Session to the node that made the
> request - 3 hops. This API would require a 4-hop trip - 1 rpc (2-hops)
> to find the location and one (another 2 hops) to retrieve it. There is
> actually a lot more detail involved here (another two hops are
> involved in locking/unlocking etc) in which this API would create
> further issue. Why bother to describe all implementations when the
> Session consumer has no requirement ?
>
> 2). I'll call on the KISS principle here. I think that by exposing the
> issues of colocation in the API, you are moving complexity from the
> implementation into the API. I think the priority should be to keep
> the API simple. At the creation of a Session the client container
> should pass the necessary information to the Session management impl
> so that it can take a decision about how it wishes to represent this
> Session. This choice of representation is very implementation specific
> and will have consequences for the granularity at which Sessions and
> their Attributes may be replicated, serialised, enumerated and
> iterated upon. By exposing an API we must necessarily provide one. Any
> one that we provide will be biased towards a particular impl. I think
> it is better to avoid this entirely by keeping this in the
> implementation.
>
> 3)
>
> (a) The API needs to make provision for the interception of this
> Invocation and its passing to the Session management layer for
> consideration. This is the point at which the implementation may need
> to make the decision whether to relocate the Invocation to the
> Session or the Session to the Invocation - what Greg, I think, calls
> the 'Policy'
>
> (b) e.g. WADI uses access to the Invocation to, amongst other things,
> rewrite the value of Http Session Cookies to tell Apache/ModJK about
> the Location of a Session, so that ModJK can route subsequent
> requests to the correct node. I think with the arrival of more
> intelligent load-balancer integrations, intelligent client-side
> stubs, session types and tiers that we need to ensure that the
> Invocation is encapsulated and made available to the Session
> management layer at every opportunity, so that sophisticated
> integration may be developed between Client and Session manager.
>
> That's enough for now :-)
>
>
> Jules
>
>
>
>>
>>
>> -David
>>
>> On Mar 7, 2006, at 9:36 AM, Dain Sundstrom wrote:
>>
>>> Looks good.
>>>
>>> -dain
>>>
>>> On Mar 6, 2006, at 12:49 AM, Greg Wilkins wrote:
>>>
>>>> Dain Sundstrom wrote:
>>>>
>>>>> My guess is we're going to need to add an event notification   
>>>>> system  to
>>>>> the Session APIs.  What do you think about just crib off of  
>>>>> the   servlet
>>>>> ones.  I think we could just smash the three session listener
>>>>> interfaces into something like this:
>>>>>
>>>>> public interface SessionListener extends Listener {
>>>>>     void valueBound(SessionEvent event);
>>>>>     void valueUnbound(SessionEvent event);
>>>>>     void attributeAdded(SessionEvent event);
>>>>>     void attributeRemoved(SessionEvent event);
>>>>>     void attributeRemoved(SessionEvent event);
>>>>
>>>>
>>>> I think you mean:
>>>>  void attributeReplaced(SessionEvent event);
>>>>
>>>>
>>>>>     void valueBound(SessionEvent event);
>>>>>     void valueUnbound(SessionEvent event);
>>>>>     void sessionCreated(SessionEvent event)
>>>>>     void sessionDestroyed(SessionEvent event)
>>>>> }
>>>>>
>>>>> public class SessionEvent extends Event {
>>>>>     Session getSession();
>>>>>     String getName();
>>>>>     String getValue();
>>>>> }
>>>>>
>>>>> We would bind a listener with a method on the Locator:
>>>>>
>>>>>     void addSessionListener(SessionListener listener);
>>>>>     void removeSessionListener(SessionListener listener);
>>>>
>>>>
>>>>
>>>>
>>>> that would certainly do it - the only change I'd like to see
>>>> is that the SessionEvent is
>>>>
>>>>
>>>>  public class SessionEvent extends Event {
>>>>      Session getSession();
>>>>      String getName();
>>>>      String getOldValue();
>>>>      String getNewValue();
>>>>  }
>>>>
>>>> As it is confusing for remove and replace what getValue() returns.
>>>>
>>>> Also as the bound/unbound events are actually called on the
>>>> value itself, you need both old and new values so you can call
>>>> unbind and bind during a replace.
>>>>
>>>> cheers
>>>
>>>
>>
>
>
> -- 
> "Open Source is a self-assembling organism. You dangle a piece of
> string into a super-saturated solution and a whole operating-system
> crystallises out around it."
>
> /**********************************
> * Jules Gosnell
> * Partner
> * Core Developers Network (Europe)
> *
> *    www.coredevelopers.net
> *
> * Open Source Training & Support.
> **********************************/
>


Mime
View raw message