Registered: Mar, 2002
Re: Clustering J2EE with Jini
Posted: Oct 22, 2002 11:26 AM
> > I'm confused as how the remote container improves
> > availability and fault-tolerance in general. Isn't
> > a single point of failure? Seems to me the
> > on chosing the right stub ought to be performed at
> > the client. I'm not a J2EE expert; maybe this
> > possible?
> I'm not quite sure I understand your question, but
> you're right that one remote container is a single
> point of failure. What they cluster is multiple
> instances of this single point of failure, which
> makes it a multiple point of failure. That sounds
> worse, but it's better. In other words, you have
> multiple containers running on multiple hosts, each
> of which offers the same EJB for example. When the
> client gets a "smart proxy" to that conceptually
> single EJB, that smart proxy actually is implemented
> such that it holds references to the remote object
> stubs of all the equivalent but separate
> implementations of the EJB running in the different
The way it sounded in the article was that the proxy in the client only held one stub to a remote container. The container contained multiple stubs to the actual service. Worse, it sounded as if all communication went through that container.
> My understanding is that the algorithm is sent along
> with the smart proxy to the client and runs in the
> client to select one of the stubs. So the algorithm
> that selects a stub does indeed run in the client's
This is good.
> VM, but on the other hand, the client apparently
> can't supply its own algorithm. Perhaps that's what
> you meant in your comment, that the client should be
> able to supply its own algorithm.
> I believe they get high availability from having
> multiple containers, and fault tolerance because they
> can to some degree do failover to a different
> container right from within the smart proxy.
If, indeed selection is done at the smart proxy in the client, then all is well.