geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <ju...@coredevelopers.net>
Subject Re: Summary? was: Session API....
Date Sat, 11 Mar 2006 22:33:39 GMT
David Blevins wrote:

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

If you can have a go at answering the questions I have posed about 
[Open]EJB in my other posting on this thread, I will merge your answers 
into the model I am carrying around in my head and dump it into an email 
as soon as I can. Then we can investigate and discuss the differences 
between WADI's approach to these problems and the proposed Session API.

Looking forward to it,

Jules

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


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