Server through RMI without registries

Question

I have a service object that can be connected via RMI. I am currently 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"); 

A registry on a server has only one use to reference a single server object. I thought that I could just as well do this on the server:

 UnicastRemoteObject.exportObject(remoteServer, 1234); 

But how can I connect to the server object from the client?

Answer 1

An RMI registry exists to solve the RMI bootstrap problem, and it’s just that you can only get a remote stub using a remote method call, and to make a remote method call you need a remote stub. The registry link provided by LocateRegistry.getRegistry() solves this problem (and is used inside Naming.lookup() if you use this API). [Note that this stub was not received using the remote method: it is synthesized locally using the host: port you provide. If they are not correct, you will not know until you use the registry stub.]

You have several options for solving the RMI bootstrap problem:

• Use the RMI registry.

• Use an LDAP server through JNDI with an LDAP provider.

• Use UnicastRemoteObject, serialize the stub obtained by exporting the object, and use a shared file or socket or sneakernet to make the stub available to clients.

• Use RMI activation; serialize the stub received when you registered the activated information and distribute it to all clients in the file along with the client application. From the point of view of the distribution of the stub, this is much simpler than (3), because the stub remains constant for the life of the application, while in (3) you must redo the stub with each export.

You can see that the registry is by far the easiest option. Please note that you only need to use it to solve the boot problem. When you have a stub, your own remote application methods can return additional objects: you do not need more than one remote object in the registry. You can consider this as a remote factory object.

Answer 2

It is impossible, but not very practical, because the registry associates the stub object of the exported object with the client (see http://www.developer.com/print.php/3455311 ). If you do not have another mechanism for this, you will be stuck. Using the registry in distributed systems has other advantages, so I would recommend keeping it for other reasons (location transparency, etc.).