Hi Hiram :-)
Hiram Chirino wrote:
On 3/9/06, *Jules Gosnell* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
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.
I think this generic Session API is trying to avoid getting into
protocol specifics
The Invocation type, that I am describing, is not bound to a specific
protocol (note that I mention both web and tiers above) - but an
abstraction over calls/rpcs/etc.. carried via a number of possible
transports : Http, OpenEJB, IIOP, various WS transports...
so it's main goal is to avoid defining a model for a Invocation.
If the Invocation were bound to a specific protocol, I would agree - but
it isn't.
I do believe that it's goal that It exposes enough information such
as where the session is located, so the protocol specific Session APIs
can be built on top of it.
So, we are beginning to reach a consensus here - the Session API is not
an API for Session Management, but an API for a State Manager that a
Session Manager might use. This is the conclusion that Greg and I came
to in our discussions.
Unfortunately, I think that this leaves half the problem in the client
container's domain. Jetty, Tomcat, OpenEJB, Axis etc already exist in
non-clustered form. What is needed is a Session Management API through
which clustered Session Managers can be plugged into these containers,
and others, and transparently and completely take over responsibility
for all clustering behaviour. What a State Management API provides is
not enough. The Container is left with the problem of talking to the
implementation behind this API about issues such as Location. This chunk
of Location-aware code may either be rewritten for each container, or
somehow shared between them. If you are sensible and go for the second
option, you find that half of your API (the piece concerning Location)
is not being used by the client Containers, but only by your piece of
shared code - i.e. it is drifting back from the API and into an area
where it does not actually need to be exposed at all....and that your
shared code needs to either be packaged with every client-container or
subsumed into your Session Manager - the latter being the most sensible
outcome.
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)
WADI could start caching that kind of location information and then it
would not need RPC to get the data. Seems like knowing the location
of a session would be crucial in making a desicion to redirect, proxy,
or move the session.
WADI does not need to RPC to get the data. This problem only arises for
WADI in trying to implement the proposed API.
WADI is designed as a Partitioned space, rather than a Shared cache,
with associated consistency and invalidation issues, specifically to
overcome the problems in scaling introduced by these issues. Introducing
a cache-based solution here would just introduce all the problems that
WADI is designed to resolve.
The point that I am trying to make is that this part of the API is not
one that needs to be exposed to a client container anyway.
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
I think that every protocol is going to make session management
decisions differently. Not every protocol can do a redirect for
example. They should be the ones in charge of deciding how to get the
invocation and the session to meet.
So you have hit the nail right on the head :-). This is why you need an
abstraction like Invocation. The Container passes an Invocation to the
SessionManager upon its entry and exiting the container. Each Invocation
subtype knows how to support a small number of operations i.e. relocate
itself to another node. This may be achieved through an Http Redirect or
HttpProxy for web, and one or more equivalents for other protocols...
The piece of Location-aware code described above (Greg's 'Policy') can
make the decision as to whether to ask the Invocation to reroute itself
to the node holding the Session, to summon the Session to the node on
which the Invocation has arrived, or to migrate both of them to be
combined elsewhere. The 'Policy' needs to know nothing specific about
the protocol encapsulated in the Invocation and the Container needs to
know nothing about how the Policy is written. The SessionManager is
assembled with pluggable policy outside the client-Container as e.g. a
GBean. The client-Container acquires a reference to the SessionManager
at startup and delegates all Session-related decisions to it
thenceforth. The client-Container need never even be aware of the
existence or type of the Policy as it is completely enapsulated by the
SessionManager.
--
Regards,
Hiram
Snell
Jonell
Gospel
Cornell
Ginelle
Edit...
Ignore all
Add to dictionary
PRC
PC
RC
RP
Ric
Edit...
Ignore all
Add to dictionary
tls
tels
ttys
Tl's
til's
Edit...
Ignore all
Add to dictionary
Punjab
Punjabi
Edit...
Ignore all
Add to dictionary
load balancer
outbalance
lovableness
lordliness
likableness
Edit...
Ignore all
Add to dictionary
generic
Gerick
Garrick
Gerek
Gerik
Edit...
Revert to "gereric"
AP Is
AP-Is
Apia
Apish
AIs
Edit...
Ignore all
Add to dictionary
Punjab
Punjabi
Edit...
Ignore all
Add to dictionary
(No suggestions)
Edit...
Ignore all
Add to dictionary
(No suggestions)
Edit...
Ignore all
Add to dictionary
PRC
PC
RC
RP
Ric
Edit...
Ignore all
Add to dictionary
decision
deicing
desiring
design
discoing
Edit...
Ignore all
Add to dictionary
co location
co-location
collocation
coloration
collocations
Edit...
Ignore all
Add to dictionary
management
managements
management's
Edit...
Revert to "managment"
decisions
sessions
cessions
session's
delusions
Edit...
Revert to "dessions"
In conclusion, the mismatch between WADI's approach and that of the
proposed API is that WADI is a SessionManager that takes responsibility
for all clustering related issues associated with Session management,
shields the client-container from even having to be aware that it is
running in a clustered environment and aims to allow the same set of
pluggable policies to be reused no matter what the underlying transport,
invocation or session implementation looks like, whereas the proposed
API seems only concerned with state management and seems happy to expose
clustering related issues to its client-containers where they may be
resolved in a number of different and inconsistant ways. I really
believe that state management is only half the problem and that unless
we take a more wholistic approach you are going to end up with a number
of confused container integrators who all have a slightly different idea
of how their container should be made cluster-aware.
Jules
--
"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.
**********************************/
