Ladies and Gentlemen,
from our talk at Dublin clustering BOF, clustering is not always about
state replication, there are other aspects of it, and its those I am
focusing on here, as state replication is already being talked about in
another thread, so it has enough coverage in the Session API threads.
This API is aimed for any underlying implementation to allow different
components to know of each other, my most simple example was the
InitialContext, to be able to fail over between two Geronimo instances,
the initial context on the client could either
a) - hard code the locations of the Geronimo VM(s)
b) - dynamically discover the locations of the Geronimo VM(s)
c) - being able to receive node information from "a" Geronimo VM
jboss does option A and B, and I am not sure about C,
but its the C option i am trying to address, as that would allow for
heterogeneous clusters, as not every VM would have the same services
deployed, and the client shouldn't have to know what services are
deployed where.
So the invocation would be something like
InitialContext ic = new InitialContext(properties); (properties could be
any of options A,B,C from above)
Context ctx = (Context)ic.lookup(sub context);
SomeRemoteStub stub = ctx.lookup("my/remotestub");
in a non clustered scenario, the ic.lookup always happens on the node
initialized in the "new InitialContext(properties);" call, and the "ctx"
is just talking to that same node.
However, in a heterogeneous cluster, all three, "ic", "ctx" and "stub"
could be cluster-aware, and make decisions through that.
Simple example, we want to lookup ejbX on a cluster with servers
serverA..serverZ, ejbX is only deployed on serverD..serverF.
InitialContext ic = new InitialContext("serverA, serverG, serverT");
//hand pick a few servers if automatic discovery is disabled(option C)
EjbX ejbX = ic.lookup("my/company/ejbX");
because ic, is cluster aware, and it is able to determine what services
run on what parts of the cluster, it can fetch the stub from serverD, or
it retrieves the stub from serverA who retrieved it from serverD.
and now the ejbX stub is pinned to serverD (or it can be load balanced,
up to the EJB implementation, see next line)
if the ejb stub is cluster aware, means it can also fail over to serverE
or serverF if serverD goes down.
remember, there is no state replication in these examples, simply an
intelligent way to distribute load, also, there is no mention of how
this is actually implemented, just the API used.
So after this long rant, and for those still with me, thanks for your
patience, I see a need for an API where components like
JNDI/EJB/monitoring etc would have the need for some sort of API to
retrieve information about the cluster (or group if you wish to call it
that), so no matter what the underlying clustering implementation is.
The API I am proposing is aimed to be useful and simple for both the
cluster provider and the cluster user. So no fancy mechanism that
tribes,activecluster,appia,jgroups implement are exposed in here, but
all of them could implement this API. Components like JNDI,monitoring
can decide to use this API, which any underlying implementation would be
required to support, or they could plug in directly to the implementation.
I believe the main benefit of this API, could be to have one cluster
notion for the VM, instead of one per component.
Quick Explanation of the API:
Cluster - One instance per VM
Node - represents the location and state of a VM
Channel - a communication channel in a cluster, a cluster can support
more than one active channel, so that components wouldn't have to listen
in on each other's chatter
Message - a message to be sent (this is not a serializable message,
implementations and components can send byte[] if they want, it will
just be kept in this message)
http://people.apache.org/~fhanik/geronimo-cluster-api.zip
That's all folks
Filip
