About Java RMI

[418928]

Hi everybody,

just some thoughts and doubts about Java RMI. If you have any comment
about it, I would appreciate it.

1) Why must a constructor of a remote object throw RemoteException? I
understand that this is because the constructor executes some code
related to RMI initialization (because it extends an RMI class). What I
don't see is why this exception is called RemoteException: as opposed
to what happens with remote methods, this exception in the constructor
is never thrown remotely (because the constructor is always called
locally by the server application).

2) I think it should be possible for a client to download a remote
stub. This should be done by defining an appropriate remote class
server. However, I'm not sure about how useful this would be. I can
only think of using this to allow the client to perform dynamic
invocations.

3) One of the reasons I've heard in favour of RMI against other
technologies like CORBA is that it uses HTTP to implement the name
service, so there is no problem with the use of firewalls (they say).
However, what about the remote invocations? These would use TCP and a
client could open a socket on any port at the local machine to connect
to a remote object... Am I right? Isn't some kind of HTTP tunneling
required? How can this be done? If you have any nice reference, please
let me know.

Thanks,
S.

 

[EJP]

1) Why must a constructor of a remote object throw RemoteException? I
understand that this is because the constructor executes some code
related to RMI initialization (because it extends an RMI class). What I
don't see is why this exception is called RemoteException: as opposed
to what happens with remote methods, this exception in the constructor
is never thrown remotely (because the constructor is always called
locally by the server application).

True. That's just the way it is. Actually it tends to throw
ExportException which as defined extends RemoteException.

2) I think it should be possible for a client to download a remote
stub. This should be done by defining an appropriate remote class
server. However, I'm not sure about how useful this would be. I can
only think of using this to allow the client to perform dynamic
invocations.

It is indeed possible. See the codebase feature. It's very useful in
situations where you don't have great control over the client
deployments, e.g. the Web, or large corporate deployments.

3) One of the reasons I've heard in favour of RMI against other
technologies like CORBA is that it uses HTTP to implement the name
service, so there is no problem with the use of firewalls (they say).

This is untrue, but see below.

However, what about the remote invocations? These would use TCP and a
client could open a socket on any port at the local machine to connect
to a remote object... Am I right? Isn't some kind of HTTP tunneling
required? How can this be done? If you have any nice reference, please
let me know.

RMI can use HTTP tunnelling for both the naming lookup and for general
RMI calls. As the naming lookup is a general RMI call too, this is no
surprise. See the RMI Specification for details.

There are firewall problems with practically any Web technology post
Telnet, FTP, and HTTP, and CORBA and RMI are not exempt.