Java RMI - UnicastRemoteObject: what is the difference between UnicastRemoteObject.exportObject() and extends UnicastRemoteObject?

Question

i'm preparing for an exam and I'm having a question that I hope someone here could answer me.

It's about RMI and remote objects. I wonder why there is so much difference between these two implementations. one is extending the UnicastRemoteObject whereas the other is exporting the object as an UnicastRemoteObject.

I don't really get the difference

Interface:

public interface EchoI extends Remote {
   public String echo() throws RemoteException
}

This is the server code (version 1):

public class EchoImpl extends UnicastRemoteObject implements EchoI {
    public EchoImpl {
        super();
    }

    public static void main (String[] args) {
        try {
            LocateRegistry.createRegistry(Registry.REGISTRY_PORT);
            StoreHouse storehouseImpl = new StorehouseImpl();
            Naming.rebind("//localhost/StoreHouse.SERVICE_NAME", storehouseImpl);
            System.out.println("Server ready");
        } catch (RemoteException e) {
            e.printStackTrace();
        } catch (MalformedURLException e) {
            e.printStackTrace();
        }
    }

    public String echo() {
        return "echo";
    }
}

and this would be version 2:

public class EchoImpl implements EchoI {
    public static void main (String[] args) {
        EchoI echoService = new EchoImpl();
        EchoI stub = (EchoI) UnicastRemoteObject.exportObject(echoService, 0);
        Registry registry = LocateRegistry.getRegistry();
        registry.bind("echoService", stub);
        ...
    }
}

My question is: what is the difference between these two?

In thefirst version the registry is explicitly created, furthermore the remote object is created within a rebind?

I'm really curious, why in the first I need to create the registry myself but do not need to export the object explicitly and just rebind it using Naming. Is that object already bound to the registry before, or could I use bind instead? And what happens, if the object was not previously bound and a rebind is excecuted?

In the second version, the registry seems to be already created. Why is binding to naming the same as binding to an registry directly?

This is, what I think:

• the first class direclty implements the interface UnicastRemoteObject which means, that at runtime the registry is created and the object is automatically exported to the RMI registry.
• as the object is already bound to the registry, a rebind instead of a normal bind must take place.
• the latter does all this explicitly.

Autolysis

Answer 1

java.rmi.server.UnicastRemoteObject is used for exporting a remote object with Java Remote Method Protocol (JRMP) and obtaining a stub that communicates to the remote object.

For the constructors and static exportObject methods below, the stub for a remote object being exported is obtained ...

There you should follow the Javadoc

Delrosario

btw, your server code version 1 confused me, locateRegistry wouldn't work because it's not declared – Delrosario

thanks for your reply, but it does not really clear things up for me.... do you like the code better as it is now? – Autolysis

;-) Now the compiler likes your code better, the result is the same the object is registered under the provided name in the RMI registry and is accessible by clients. The only difference is that rebind is more fault tolerant than bind (If already bound). I will upvote your question to attract more guys – Delrosario

thanks again - so the first version is somewhat safer, right? in almost all tutorials a RMI object is exported in the latter manner, but IMO I prefer the first version over the other... – Autolysis

As already mentioned they're equivalent the difference is rebind would not throw an AlreadBoundExeption, I also prefer your first option. In your exam you could describe one way and mention that there's another option. – Delrosario

well, I've rocked the examination - thx for your input anyway... :-) – Autolysis

This answer is practically meaningless, especially the second paragraph. It explains nothing, and doesn't answer the question. – Pustulate

Answer 2

There are two questions here.

1. You can either extend UnicastRemoteObject or call UnicastRemoteObject.exportObject(). Which you do is up to you. The first is simple and automatic; the second means you can extend another class.

2. You can either use an external RMI Registry or create it yourself inside your server JVM. Again which you do is up to you, there are advantages both ways.

   These two questions have no interaction.

3. If you extend UnicastRemoteObject you also get the benefit of 'remote semantics' for the hashCode() and equals() methods, such that all stubs appear to be identical to the remote object that exported them, but this is of no practical use on the client side, and is really only there to support the RMI implementation itself.

Pustulate

Answer 3

You can call the UnicastRemoteObject.exportObject() instead of extending the UnicastRemoteObject in a scenario where you need to extend any other class. Overall effect is the same I think.

See this

Kissel

Poor quality link with at least two major errors. -1 – Pustulate

Answer 4

Firstly, binding & rebinding remote object using Naming class and Registry class is not relevant to scenarios of whether or not a class is extending UnicastRemoteObject. See here for the differences.

Secondly, the difference between the class extending UnicastRemoteObject is that if the object of that type is used as a stub, then you'll not need to call UnicastRemoteObject.exportObject to obtain the stub anymore for binding with registry. In your version 1, the StorehouseImpl must have extended the UnicastRemoteObject, and in fact, there's no need for EchoImpl to extend UnicastRemoteObject for your version 1 as there is no instance of EchoImpl is registered as a remote object to the registry.

Thirdly, you mention what'd happen if rebind is executed without bind is executed beforehand. As explained in the javadoc here, if no key name has been inserted, it will behave in the same way as if first time bind is executed.

Sanitary

The Registry does not determine whether an object needs to be remote. It could be a callback passed directly to the client. – Pustulate