My understanding of ActiveSpace is that it supports two state clustering
abstractions :
- Cache - a Map-like API
- Space - a JavaSpace like paradigm (also allowing a pub/sub model)
WADI provides a third model, I have been trying unsuccessfully, to think
of a nice name for it - lets call it a 'Meet' (in WADI it is currently
called a 'Contextualiser').
You give a Meet a Session ID and a self-contained Invocation
(HttpReq/Res pair, OpenEJB Invocation, etc...). It guarantees that, if
the Session is known, the Invocation will be run against it, but,
importantly, it does not say anything about where in the cluster this
may occur. i.e. Invocation and Session will 'meet' somewhere in the
cluster. It is important to maintain location independance as this
enables the cluster to decide for itself the most efficient way to get
this done and opens up opportunities for state-balancing and intelligent
invocation routing etc (customer prioritising etc...).
Perhaps this model can be implemented on top of a CacheCommand? If so,
we don't really need the 'Meet' - it just becomes syntactic sugar.
So, it should be fairly simple to implement a LocalMeet, i.e. a Meet
where the Invocation is always run locally, by throwing the Meet API
around an ActiveSpace Cache - as this will always migrate the Session to
the Invocation.
This would be worthwhile, because we would be able to plug e.g. an AS
ClusteredCache straight into Jetty/Tomcat/OpenEJB, using WADI as the
integration. We will also get Transactions, via AS' TransactionalCache.
WADI's current implementation of a Meet implements a form of partitioned
cache. The benefit of this is that a cluster can support more sessions
than can be held on any single node (a constraint that applies if every
node holds a copy of every session). The downside is that this approach
is much more complex.
By implementing a LocalMeet on top of AS Cache impls, we can quickly
provide a simpler impl than WADI's default, which is able to immediately
fill demand in smaller sized clusters, whilst we continue to work on the
large-scale solution in WADI.
The final difference between WADI and and AS (impl) is that WADI locks
pessimistically, whereas, my understanding is that, existing AS impls
lock optimistically (I understand that the AS API does not mandate any
particular locking approach, but I am talking about impls available to
us today). Provided that you can guarantee that all concurrent
invocations will always land on the same node, an optimistic approach
should be enough. In the web world, certain higher end http load
blancers can provide this guarantee and in the EJB world, we can
certainly do the same. This means that an AS based solution, integrated
with various containers via WADI code, will, in many cases, be sufficient.
Finally, as discussed with James on numerous occasions, we should look
at how WADI's pessimistic locking and PartitionManager might be
componentised so that they can be plugged into AS to provide Cache and
Space users, who are not interested in location-independance, with a
pessimistic approach and/or a partitioned clustering substrate...
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.
**********************************/