Server via RMI without registry

Question

I have a service object that can be connected to via RMI. Currently I'm doing this:

Server

Registry r = LocateRegistry.createRegistry(1234);
r.bind("server", UnicastRemoteObject.exportObject(remoteServer, 0));

Client

RemoteServer s = LocateRegistry.getRegistry("example.com", 1234).lookup("server");

The registry on the server has only one use, to link to the single server object. I figured I might just as well do this on the server:

UnicastRemoteObject.exportObject(remoteServer, 1234);

But then how would I connect to the server object from the client?

Answer 1

The RMI Registry exists to solve the RMI bootstrap problem, which is simply that you can only get a remote stub via a remote method call, and to perform a remote method call you need a remote stub. The Registry reference provided by LocateRegistry.getRegistry() solves this problem (and is used internally by Naming.lookup() if you are using that API). [Note that this stub isn't obtained via a remote method: it is synthethized locally using the host:port you provide. If they aren't correct you won't find out until you use the Registry stub.]

You have several choices to solve the RMI bootstrap problem:

1. Use the RMI Registry.

2. Use an LDAP server via JNDI with the LDAP provider.

3. Use UnicastRemoteObject, serialize the stub obtained when you export the object, and use a shared file, or a socket, or sneakernet, to make the stub available to clients.

4. Use RMI Activation; serialize the stub obtained when you registered the activatable, and distribute to all clients in a file, along with the client application. From the point of view of stub distribution this is a lot simpler than (3) because the stub remains constant for the life of the application, whereas in (3) you have to redestribute the stub on every export.

You can see that the Registry is certainly the simplest option. Note that you only have to use it to solve the bootstrap problem Once you have a stub, your own application remote methods can return further objects: you don't need more than one remote object in the Registry. You can consider that as a remote object factory.