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