Tom Cook wrote (abbreviated):
> I think that this last point is one which is being lost on some
> people. It means that there can be no central controller. Everything
> must work in a completely distributed way. I have tried to describe how
> this might work. For instance, there can not be a 'master' jndi
> repository, which is replicated, nor can there be a 'master' transaction
> manager, message queue... anything. This is why the private/public JNDI
> tree became necessary, so that some services could retain an identity at
> each node, while beans are federated across the nodes, and a lookup on
> them may return an instance at any node.
> Having thought this through a little more, what I really meant was that
> objects in JNDI should be treated differently depending on whether they
> are services or EJBs. A service should have an identity at each node
> within the cluster. For a 10-node cluster, there will be 10 transaction
> managers, which are co-operating to provide distributed
> transactions. Each one still retains it's own identity. So there is a
> transaction manager in each 'private' JNDI, which is not visible to the
> client anyway. Then there are beans, which have to exist as one entity
> across all the nodes. Do you see what I am saying? There are two
> different sorts of clustering happening here. One is that of many
> individuals working independantly to provide a service, the other is one
> corporate body making up a service. The 'public/private' thing might be a
> bit confusing, it was just a way of implementing this.
Can't this public/private distinction be collapsed into a scoped model where
each object can specify which nodes of the cluster it wants to be replicated
to when it binds? For example, a "private" service would bind to one node
whereas a "public" one would bind to all (or possibly a global scope to
allow for membership changes).
This adds a third possibility where an object could bind to a subset of
nodes, say 2 out of 3. This would directly support configurations where an
application was only deployed on a subset, for example, without have to poll
the node in turn. It would also allow for a master-slave configuration (like
Weblogic's SFSB replication) to be implemented on top [to avoid confusion, I
emphasize this is a voluntary M/S deployment for a specific service running
on top of a federated implementation].
Jeremy
