The Artima Developer Community
Sponsored Link

Clustering J2EE with Jini
A Conversation with Sean Neville, Part I
by Bill Venners
October 21, 2002

<<  Page 4 of 4


Coming to Jini

Sean Neville: We started experimenting with how we would create the discovery mechanism. We had done some prototype work on discovery based on messaging, and we had built the EJB and JNDI subsystems, two sets of services we wanted to cluster.

When we were at that stage, I attended a three-day J2EE summit in August 2001, where you, Richard Oberg, and others were talking about Jini. To be honest, I had looked at Jini a long time prior, but had never really done anything with it. It was kind of out of sight, out of mind until the summit last year. Once it was in front of me again, at that summit, it was obvious that Jini had already solved the problem of automatic discovery using multicast. It also solved some potential problems we didn't know we would face.

Bill Venners: Like what?

Sean Neville: Well, packet storm was one. We naively didn't even consider that an issue.

So then I started playing with Jini again. I ripped out our discovery mechanism, and in its place I established a Jini lookup service that we used as a delegate inside a service I dubbed the "cluster manager."

When you fire up the JRun server, you're firing up the service microkernel that starts a list of services. These services can be nested. If a particular service starts, then all its child services start before you move on to the next service in the hierarchy. Services can be represented in an XML structure, and that is a handy way to conceptualize it: starting services is like going through a DOM (document object model) where each element represents a service. Each service has a lifecycle; so you go through the tree once, and you initialize all the services and their children. Then you go through the tree again, and you actually start all the services. That lifecycle lets us handle some interdependencies between services.

So one of those core services is this cluster manager that, when it fires itself up, internally fires up a Jini lookup service. The cluster manager can be considered a wrapper around the Jini lookup service.

Bill Venners: Is the Jini lookup service running inside the container?

Sean Neville: It is running inside the server, in the same process. It is not really running in a container, but is managed by the service microkernel and can be managed through JMX. The Jini lookup service is its own uber-service. It is a top-level service.

Once the lookup service is running, any service that happens to be a remote object can find it, because the lookup service has already started. The service can discover the lookup service and tell the lookup service it is there.

Bill Venners: Does it use the Jini multicast discovery protocol?

Sean Neville: It uses the multicast discovery protocol, and the unicast option. So you can statically specify which hosts should be in the cluster if you so desire.

Bill Venners: So if I actually have five of these servers running in the same local area network, I could find all five lookup services in all five of those hosts?

Sean Neville: That's right.

Bill Venners: Or if I just wanted to contact one, I could by mentioning the host in some XML configuration file?

Sean Neville: Exactly. Frequently, services will be nearby on the same subnet, but for whatever reason -- often operational and not technical -- multicast won't be permitted. In that case, you'd use unicast to get the nearby ones.

There's also something called the cluster group, which allows you to set up a named cluster, and join only those peers that belong to the same group. When you get to the lookup service, you query it to see if there are any remote objects similar to yourself that are interested in the same named group, and you immediately grab their stubs. You also register for events. If a remote object finds this lookup service later and it matches, you are notified and then you can grab its stub. If a previously-discovered peer changes groups, or drops out entirely, you also receive an event. We use the Jini event mechanism to implement this.

Bill Venners: When I come up, the reason I look for a Jini lookup service is because that is how I discover my peers. I look them up by type in the lookup service. I also register that I want to be notified if a new peer stub appears, and if one goes away I suppose, so I can keep up to date on what peers exist.

Sean Neville: That's exactly right. The list of stubs is constantly updated, so it stays live.

I have my peer collection, which may be updated as the cycle spins. That's what we use Jini for. From that point on, from the client invocation angle, Jini isn't involved. It is really straight RMI-IIOP from the client view. Jini is our own internal implementation mechanism for creating smart, self-organizing stubs.

Talk Back!

Have an opinion about clustering, remote objects, JRun, or Jini? Discuss this article in the News & Ideas Forum topic, Clustering J2EE with Jini


The Jini Community, the central site for signers of the Jini Sun Community Source License to interact:

Information on Macromedia JRun is at:

<<  Page 4 of 4

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use