Hello Tom,
> 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.
OK, I see what you mean: difference between a bean and a service i.e.
between a cluster-view and a node-view.
Consequently, you suggest to have the public tree (cluster-view) being
replicated at each node and all the private (i.e. node-view) trees, local to
each node, being federated under the public tree. Right? (or we may as well
have the public (cluster) tree federated under each private local tree)
> > 2nd, this "where-could-i-find-such-a-bean..." mechanism is probably not
> > strict enough.
>
> What do you mean be this? How is it not 'strict' enough?
I meant too lazy => not enough optimized. But I may have missed your point!
> 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.
OK, I agree with need such local vs. global representation.
> > > The list of other live nodes would probably be best acheived
> by a regular
...
> > ...). (in fact, the failure detection mechanism is a basic layer of the
> > group communication problem)
> >
> > What do you think?
>
> I like this group communication thingy, except for that everyone I've
> heard explaining it seems to have advocated having a central controller,
> which gets messy in the case of the controller failing. I have tried to
> avoid this.
?!? the group communication scheme as generally implemented (like
javagroups) is completely redundant. At a particular moment you have some
kind of master that sequences the system. But, a completely distributed
failure detection subsystem will detect its death (or the death of any other
node). And if the "controler" dies, a distributed election mechanism
automatically takes place. There no single POF. Have I answered your concern
or am I (again ;) ) missing your point?
Cheers,
Sacha
