Geronimo cluster API suggestion

[Filip Hanik - Dev Lists <de...@hanik.com>]

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

Re: Geronimo cluster API suggestion

[Greg Wilkins <gr...@mortbay.com>]

Filip,

sorry  - but I missed this post before I sent my own API suggestion.
However, I think the good news is that your API view is very much
the same as my API view....

We both start at Cluster and can discover meta data about Nodes.

Your Cluster provides a channel/message mechanism that I think would
be very useful for cluster coordination.

Mine expands about session and state

But I don't think these are mutually exclusive and I think the
two view can be merged without any significant clashes.

cheers

Re: Geronimo cluster API suggestion

[Jeff Genender <jg...@apache.org>]

Filip,

Thanks for the first pass on this...it looks interesting.

Jeff

Filip Hanik - Dev Lists wrote:
> 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
> 
> 
> 
> 
>