Question

State whether each of the following is true or false. If false, explain why. a) Not starting the RMI registry before attempting to bind the remote object to the registry results in a RuntimeException refusing connection to the registry. b) Every remote method must be part of an interface that extends java.rmi.Remote. c) The stubcompiler creates a stub class that performs the networking which allows the client to connect to the server and use the remote object’s methods. d) Class UnicastRemoteObject provides basic functionality required by remote objects. e) An object of a class that implements interface Serializable can be registered as a remote object and receive a remote method call. f) All methods in a Remote interface must have a throws clause indicating the potential for a RemoteException. g) RMI clients assume that they should connect to port 80 on a server computer when attempting to locate a remote object through the RMI registry. h) Once a remote object is bound to the RMI registry with method bind or rebind of class Naming, the client can look up the remote object with Naming method lookup. i) Method find of class Naming interacts with the RMI registry to help the client obtain a reference to a remote object so the client can use the remote object’s services.

Short answer

a) False; b) True; c) False; d) True; e) False; f) True; g) False; h) True; i) False.

Step-by-step solution

Analyze statement a

Statement a is false. Not starting the RMI registry results in a RemoteException, not a RuntimeException. The error typically indicates that the registry can't be contacted because it isn't running.

Analyze statement b

Statement b is true. In Java RMI, every remote method must be part of an interface that extends `java.rmi.Remote` because it defines the remote methods that can be called from a client.

Analyze statement c

Statement c is false. Since Java SE 5, stubs are generated dynamically at runtime using dynamic proxies rather than by compiling using a stub compiler (such as `rmic`). Therefore, there is no stubcompiler that creates a stub class in modern Java RMI.

Analyze statement d

Statement d is true. `UnicastRemoteObject` provides the necessary infrastructure for remote communication and can be used to export remote objects, making them available to accept incoming remote calls.

Analyze statement e

Statement e is false. Implementing `Serializable` makes an object capable of being serialized for transmission, but does not automatically allow an object to be registered as a remote object. Remote objects must implement an interface that extends `Remote`.

Analyze statement f

Statement f is true. All methods in a `Remote` interface must specify a `throws RemoteException` in their declarations to handle possible communication issues during remote method invocation.

Analyze statement g

Statement g is false. RMI clients do not assume port 80; rather, they connect to the RMI registry, which usually listens on port 1099 by default unless specified otherwise.

Analyze statement h

Statement h is true. Once a remote object is registered with the RMI registry using `bind` or `rebind`, clients can locate it using `Naming.lookup` to get a reference to the remote object.

Analyze statement i

Statement i is false. There is no `find` method in class `Naming`. The correct method for obtaining a remote object reference is by using `Naming.lookup`.

Key concepts

RemoteException

In Java RMI, a "RemoteException" is fundamental because it handles specific problems that arise when dealing with remote method calls. When an RMI-based server or client tries to process a method call or return a result, network-related issues can occur.
These might include problems like the network being down, the server being difficult to reach, or even an error in the network protocol. In such cases, "RemoteException" is thrown to highlight such communication issues.

• It's a checked exception, meaning it must be declared in a method's "throws" clause if that method can encounter it.
• Helps identify problems due to the "remoteness" factor, separating them from typical local code errors.

Just imagine it as a signal that something went wrong during the remote communication process, informing developers about potential network failures.

java.rmi.Remote

The "java.rmi.Remote" is a crucial interface in the Java Remote Method Invocation (RMI) framework. This interface serves as a marker, indicating that an object can be accessed remotely. To make use of the Java RMI's remote capabilities, a class needs to implement an interface that extends this basic "Remote" interface.
This specification ensures that any object that provides remote services declares its methods as part of an interface extending "Remote".

• Remote interfaces outline what can be called by the client.
• It's part of RMI's strategy to separate the contracts that clients need from the actual implementations on the server side.

Remote method declarations in such interfaces must always anticipate and incorporate a "RemoteException" in their signatures.

UnicastRemoteObject

"UnicastRemoteObject" is a class offering a straightforward mechanism to facilitate remote object communication. When a remote object is intended to interact (either from or to another JVM), "UnicastRemoteObject" steps in to provide essential services.
By extending this class, a developer allows the object to be exported, enabling it to accept remote calls on its methods. Some essential points:

• It supports the unicast (single-node) remote object model which is the most standard approach.
• Automatically helps in handling the lifecycle of a remote object, like initialization into the RMI runtime.

Thus, it simplifies the implementation of remote objects that clients will be able to interact with over a network.

Serializable

The "Serializable" interface plays an integral part in Java's object communication. It is, however, not directly involved with making an object a part of RMI's remote object system. "Serializable" simply ensures that an object can be converted into a byte stream and vice versa, allowing it to be transferred over a network or stored in a file system.
This capability is important because RMI may need to transfer objects between JVMs when invoking remote methods. Quick points about "Serializable":

• It's a marker interface, meaning it has no methods or fields.
• Its aim is solely to tag that an object’s state can be serialized and deserialized.

Implementing "Serializable" makes objects ready for fundamental transfer operations, but remote objects require additional provisions.

Dynamic Proxies

"Dynamic Proxies" in Java provide a dynamic mechanism to create proxy instances that implement specified interfaces. Within the context of RMI, when stubs (proxies that stand in for remote objects) are needed, rather than statically generating them, they can be dynamically created at runtime using these proxies.
This provides a more efficient and flexible way to handle remote interface method calls. Why use dynamic proxies?

• Eliminates the need for explicit stub generation, thereby avoiding the hassle of using a stub compiler.
• Allows for modifications and enhancements in the way method calls are handled, without direct changes in the core interfaces.

This modern approach leverages Java's reflection capabilities to handle RMI tasks seamlessly.

Remote Method Invocation

The heart of Java RMI is "Remote Method Invocation", where the fundamental idea is to enable method calls on an object located in another JVM or even another physical machine. With RMI, developers allow objects to interact over a network in a manner similar to local object calls.
RMI handles method invocation, the transmission of arguments, and the return of results all seamlessly. Components of RMI include:

• Remote interfaces defining accessible methods.
• Stubs and skeletons assisting in communication and method dispatching.
• RMI registry which helps locate the remote objects.

RMI abstracts the networking challenges, letting developers focus on coding the business logic rather than communication intricacies.