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?

Powers

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.

Verbenaceous

I've come upon this problem again (#11399908), and this time can't use the registry. I could use method 3, but if the client has the interface and host/port of the service, can it maybe synthesize a stub itself? – Powers

@BartvanHeukelom In theory yes, in practice not really. Why can't you use the Registry? – Verbenaceous

Great hint (3) that its just the serialized stub that needs to be somehow transported to the client. Never understood it from the docs that it that easy. Nowadays zookeeper would be a good option too. – Tatter

For (3) it is worth noting that setting system property java.rmi.server.hostname seems to be the only way to get a stub which can connect from one machine to another instead of just on localhost. – Tatter

@Tatter Only if the DNS of the exporting host is misconfigured, or there is a public/private IP address issue. – Verbenaceous

Answer 2

Not impossible, but not terribly practical because the registry communicates the stub object of the exported object to the client (see http://www.developer.com/print.php/3455311). If you don't have another mechanism for that, you'll be stuck. Use of a registry in distributed systems has other benefits, so I'd actually recommend keeping it for other reasons (location transparency, etc).

Litalitany

Vista: That's not correct, and it's not what the link you provided says either. All the Registry does is solve the bootstrap problem: you can only get a remote stub as the result of a remote method, for which you need a remote stub ... – Verbenaceous

Vista: No. The bootstrap problem is the provision of the initial stub object to the client, as your link says. You said 'class', which is entirely incorrect. The Registry does not supply classes. Your second statement about a 'NEW stub class' for a 'NEW instance of the object' doesn't make any sense either. – Verbenaceous

@EJB: If the issue is between use of class vs object, I agree with you and I've corrected that. The bulk of my point is where the stub originates from and the necessity of the registry, which was the clearly the spirit of the question. BTW, I cannot edit my comment above, so I'm deleting it. – Litalitany

Answer 3

Client uses an rmi URL like rmi://localhost:2020/server

see https://mcmap.net/q/1171683/-communication-between-two-separate-java-desktop-applications

Soliz