"When you deploy a remote object, it needs a way to locate all similar remote objects on the cluster. The cluster would include whatever hosts the admin decided to link together. By default, if the admin did nothing, we wanted the cluster to include all the nearby hosts reachable via multicast. So whatever that network neighborhood cluster was, we needed a particular remote object to find its buddy on another system within the cluster based on class lookup. The lookup could possibly be based on some other information in the template, but it would mainly be based on the class. We wanted those objects to automatically find each other and exchange stubs," says Sean Neville in this Artima.com interview:

http://www.artima.com/intv/cluster.html

I'm confused as how the remote container improves availability and fault-tolerance in general. Isn't it a single point of failure? Seems to me the strategy on chosing the right stub ought to be performed at the client. I'm not a J2EE expert; maybe this isn't possible?

Sean

> I'm confused as how the remote container improves
> availability and fault-tolerance in general. Isn't it
> a single point of failure? Seems to me the strategy
> on chosing the right stub ought to be performed at
> the client. I'm not a J2EE expert; maybe this isn't
> 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 containers.

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 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.

> > I'm confused as how the remote container improves
> > availability and fault-tolerance in general. Isn't
> it
> > a single point of failure? Seems to me the
> strategy
> > on chosing the right stub ought to be performed at
> > the client. I'm not a J2EE expert; maybe this
> isn't
> > 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
> containers.

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.

Nope.

> 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.

Thanks,
Sean

> 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.
>
It is confusing because there really are two levels of stubs. I actually went back in my previous post and replaced one of the "stubs" with "smart proxy" to make it clearer. The client really does hold one stub to one remote container, which I was calling a smart proxy. But that smart proxy stub actually contains inside it all of the peer stubs to equivalent remote objects and an algorithm that chooses one of the peer stubs and does failover if necessary.

All the communication does go through the container of the one peer stub that is selected by the algorithm. That's how the container can take care of things like transactions and security so the EJB writer doesn't need to worry about them. But all communication does not go through the container from which the smart proxy stub came from unless the algorithm happens to pick that same container's peer stub.

While talking about clustering, J2EE and Jini, I will ask You to remeber about the JavaSpaces, a part of Jini.
Please, refer to the following sources:

http://www.gigaspaces.com/download/GSClusterWhitePaper.pdf

http://www.onjava.com/pub/a/onjava/2002/07/17/tomcluster.html

Great interview Bill, thanks for sharing.

One question about the algorithm strategy used. At the time the client gets the serializable algorithm, he only has references to stubs available at that time. If new servers / containers join the cluster, does the algorithm know about these? In other words, can the algorithm update itself to know about new stubs once he's been obtained by the client?

Perhaps the chance of this occuring is too small to deal with, but I was just curious if this problem was considered and how it was addressed.

Thanks again.

-ryan

> One question about the algorithm strategy used. At
> the time the client gets the serializable algorithm,
> he only has references to stubs available at that
> time. If new servers / containers join the cluster,
> does the algorithm know about these? In other words,
> can the algorithm update itself to know about new
> stubs once he's been obtained by the client?
>
> Perhaps the chance of this occuring is too small to
> deal with, but I was just curious if this problem was
> considered and how it was addressed.
>
Sean did indeed describe a way in which the stub list can be updated with each method invocation on the smart proxy stub. The details of this are in part II of the interview, which will appear next week. In short, what they do is attach information such as an updated proxy list to a message object that goes back and forth for each remote method invocation. Come back next week for the full story in Sean's words.

Hi Sean,

> I'm confused as how the remote container improves
> availability and fault-tolerance in general. Isn't it a
> single point of failure? Seems to me the strategy on
> chosing the right stub ought to be performed at the
> client. I'm not a J2EE expert; maybe this isn't possible?

There are options to run multiple JINI VMs as well.

Much simpler for J2EE is to simply cluster the J2EE application. This is what we do with Coherence -- see http://www.tangosol.com/coherence.jsp -- which runs inside the J2EE application server and automatically detects new J2EE server instances as they come up and automatically detects when they go down (these are events that the application can listen to.) Furthermore, when you are using Coherence, the entire cluster works together to become one giant "space" for your data, with no single points of failure or single points of bottleneck.

Peace,

Cameron Purdy
Tangosol, Inc.