What is Remote Method Invocation (RMI)?

● Remote Method Invocation (RMI) is a Java API that allows objects residing in
one JVM (Java Virtual Machine) to invoke methods on objects residing in
another JVM, potentially on different machines over a network.
● RMI enables distributed computing in Java by providing a mechanism for
remote communication and method invocation between Java objects.
● RMI allows developers to build distributed applications where objects on
different machines can interact with each other as if they were local objects.
● It provides a transparent mechanism for communication, hiding the
complexities of network programming and enabling remote objects to be
treated similar to local objects.

Stub and skeleton

Stub
● A stub (also known as a proxy or a client-side proxy) is a local representative
or a surrogate object that acts as an intermediary between a client and a
remote object.

1
● The stub provides a transparent way for the client to invoke methods on the
remote object as if it were a local object, even though the actual object
resides in a different address space or on a remote machine.
● The stub is generated automatically by the RMI system based on the remote
interface implemented by the remote object.
● It serves as a local proxy that encapsulates the details of network
communication, parameter marshaling, and remote method invocation.
● The client interacts with the stub as if it were interacting with the actual
remote object.
● When a client wants to invoke a method on the remote object, it does so by
calling the corresponding method on the stub.
● The stub then handles the following tasks:

1. Marshaling: The stub converts the method parameters into a format suitable
for transmission over the network. It serializes the parameters into a byte
stream that can be sent to the remote object.

2. Network Communication: The stub is responsible for establishing the

network connection with the remote object, or it may reuse an existing
connection. It transmits the marshaled parameters and method invocation
request to the remote object.

3. Unmarshaling: On the remote side, the received method invocation request

is unmarshaled by the remote object's skeleton, which extracts the
parameters from the byte stream and prepares them for the actual method
invocation.

4. Method Invocation: The remote object's skeleton invokes the actual method
on the remote object with the unmarshaled parameters. The method
executes on the remote machine, and any results or exceptions are
generated.

2
 5. Marshaling of Results: If the method produces a result, the result is marshaled
by the skeleton and sent back to the stub in a serialized form.

6. Unmarshaling of Results: The stub receives the serialized result from the
remote object's skeleton and unmarshals it back into the appropriate data
type.

7. Return to the Client: Finally, the stub returns the result to the client, as if the
method was invoked directly on the remote object.

● The stub provides the client with a seamless and transparent interface to
interact with the remote object, without the need to deal with the intricacies
of network communication or remote method invocation details.
● It abstracts away the complexities and presents a local object-like interface to
the client, enabling remote objects to be treated as if they were local objects.

Skeleton
● A skeleton (also known as a server-side stub) is an intermediary component
that resides on the server side and acts as a bridge between the client-side
stub and the actual remote object.
● It is responsible for receiving method invocation requests from clients,
dispatching those requests to the appropriate remote object, and returning
the results or exceptions back to the client.
● The skeleton plays a crucial role in the RMI system by handling the following
tasks:

1. Unmarshaling: When the client-side stub sends a method invocation request

over the network, the skeleton receives the request and unmarshals the
parameters contained within the request. Unmarshaling involves extracting
the serialized data and converting it back into appropriate data types that the
remote object understands.

3
2. Dispatching: Once the parameters have been unmarshaled, the skeleton is
responsible for identifying the appropriate remote object that should handle
the method invocation. It locates the target object using information such as
object references, names, or other identification mechanisms.

3. Method Invocation: After locating the target object, the skeleton invokes the
requested method on the remote object, passing the unmarshaled
parameters. The actual method execution takes place within the remote
object's JVM.

4. Marshaling of Results: If the method execution produces a result, the

skeleton marshals the result into a serialized form suitable for transmission
over the network. This involves converting the result into a byte stream.

5. Return to the Client: The serialized result is then sent back to the client-side
stub, which will be responsible for unmarshaling the result and providing it to
the client code.

● The skeleton acts as a mediator between the client-side stub and the remote
object, handling the low-level details of network communication, parameter
conversion, and method dispatching.
● It allows the client to interact with the remote object in a transparent manner,
abstracting away the complexities of remote communication.
● It's important to note that in modern Java RMI, the explicit use of skeletons is
not required.
● The RMI system automatically generates and manages the skeleton
internally.
● The stub and skeleton components are generated during the RMI object
registration process based on the remote interface and are hidden from the
developer's direct control.

4
5