Sponsored Link •
Sean Neville: 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.
Bill Venners: So if I'm a remote object, I want to discover all my peer remote objects of the same class. So the cluster self-organizes?
Sean Neville: It would. We wanted a small automatic lookup or discovery mechanism to allow peer remote objects to find each other.
Bill Venners: In other words, when I first come up, I will try to find my peers and get their stubs.
Sean Neville: That's right. As a remote object you'll have your own stub, but as a clustered remote object you'll also have my stub and everyone else's stub who belongs to the same cluster.
Bill Venners: And they'll have my stub somehow.
Sean Neville: That's right. When a client gets a remote reference to me after I've performed discovery, then I can give him all the stubs I know about, which is a collection that might include your stub in addition to mine. Then he has all the stubs locally and can choose you without actually coming to me. The way he would choose stubs depends on a plugged-in algorithm. The algorithm is a serializable object that is passed along with the stub collection.
Bill Venners: It's like a strategy.
Sean Neville: Exactly. So the algorithm is established ahead of time during the remote object development. The algorithm is pluggable and wide-open to being changed, but in cases like EJB, it turns out that really only a handful of specific algorithms tend to be desirable. For stateful session beans, for example, we provide a very specific algorithm.
Remote object clustering is an aspect of the EJB invocation mechanism. When you deploy an EJB into a container and the client looks up that EJB via JNDI, if the client is remote then the client actually gets a remote reference to that container -- in our case, this remote container reference is actually an invocation broker, a remote object sitting in the container. Locally, it appears that the client has an object that implements all the methods implemented in the EJB, but actually the client has a stub to the container. Every time the client invokes a method, the invocation is passed to the container and a series of aspects, or intercepting filters, manipulate the call. Eventually the invocation arrives at the correct instance, the bean implementation instance, and the invocation result then flows back through the container on the way back to the remote client.
That invocation broker, which you could think of as the front controller for the EJB container, is a remote object. So if we could apply our generic remote object clustering aspect to that particular object, then we would automatically have clusterable containers.
Bill Venners: I understand how you planned to get load balancing with the pluggable algorithm, but how did you plan to get failover?
Sean Neville: We grouped together clusterable exceptions. The algorithm, in addition to choosing the stub, would handle the invocation. The algorithm would make the call and handle certain returned exceptions. For example, a remote exception would be interpreted in a particular way. The algorithm could then failover to a different stub.
Bill Venners: So the algorithm itself could pick a different stub.
Sean Neville: That is one way it could happen. And it is the principal way it does happen. There is another way failover can occur: Our web, EJB, and web service containers, as I mentioned, are composed from a set of intercepting filters, or handlers. One of these interceptors in the EJB container is aware of clusterable invocations. So failover could be handled at that level instead, and the advantage there is that some state could be saved and a rollback possibly avoided; if you were already in the container, you could go to another if necessary in the same transaction. But it's true that failover is mostly handled in the algorithm.