RMI allows objects in one Java virtual machine to invoke methods on objects residing in another JVM. It uses distributed objects, where a client proxy marshals method invocations into messages and unmarshals reply messages. A server skeleton unmarshals invocations and forwards replies. RMI supports both static and dynamic invocation. Examples of RMI include DCE remote objects, which extend RPCs to support remote method invocation, and Java RMI, which integrates distributed objects into Java for high distribution transparency.

1. REMOTE METHOD INVOCATION
By,
M. Sabiha
MCA 2nd Year
120419862042

2. What is RMI?

3. • RMI stands for Remote Method Invocation.
• It is a mechanism that allows an object residing in
one system (JVM) to access/invoke an object running
on another JVM.
• It is used to build distributed applications and
provides remote communication between Java
programs.
• It resides in java.rmi package.

4. Distributed Objects

5. • When a client binds to a distributed object, an
implementation of the object’s interface, called proxy, is
loaded into the client’s address space.
• A proxy marshals method invocations into messages and
unmarshal reply messages to return to the result of the
method invocation to the client.
• Incoming invocation requests are first passed to a server
stub, called skeleton, which unmarshals them to proper
method invocations at the object’s interface at the
server.
• Server stub is also responsible for marshalling replies and
forwarding reply messages to the client-side proxy.

7. Compile Time v/s Run Time Objects
1. Compile-time Objects: Language-level objects like Java
& C++ from which proxy and skeleton are automatically
generated.
2. Run-time Objects: Can be implemented in any language
but require use of an object adapter* that makes the
implementation as an object.
*Object adapter is like a wrapper in which all the
objects are bind together and it will open the particular
object’s related data file which represents the object’s
current state.

8. Persistent and Transient Objects
• Persistent Object: Continues to exist even if it is
currently not contained in the address space of a
server process. It is independent on its current
server.
• Transient Object: Exists only as long as the server
continues to exist, i.e., as soon as the server stops ,
the transient object vanish.

9. Binding a Client to an Object

10. There are two types of binding that can be done on
an object at the client-side:
1. Implicit Binding: Offers a simple mechanism to the
client that allows it to directly invoke methods using
only a reference to an object.
2. Explicit Binding: Calls a special function at the
client-side to bind the object before it can invoke
the methods. It generally returns a pointer to a
proxy, i.e., to the client stub, then after that it will
locally become available.

11. Example of Implicit and Explicit Binding
(a) Distr_object* obj_ref; //Declare a system-wide object reference
obj_ref = …; //Initialize a reference to a distrib. obj.
obj_ref do_something(); //Implicitly bind and invoke a method
(b) Distr_object* obj_ref; //Declare a system-wide object reference
Local_object* obj_ptr; //Declare a pointer to local objects
obj_ref = …; //Initialize a reference to a distrib. obj.
obj_ptr = bind(obj_ref); //Explicitly bind and get ptr to local proxy
obj_ref do_something(); //Invoke a method on the local proxy

12. Implementation of Object References
Object reference must maintain enough information
to allow a client to bind to an object. A simple object
reference would include:
i. Network address of the machine where the
original object resides.
ii. End-point identifying the server that manages
the object (Eg. Local port assigned by the server
OS).

13. Purpose of Location Server
• This approach requires encoding the server ID
into the object reference which is generally
not a good idea because server should not be
moved to another machine without
invalidating all the references to the objects it
manages.
• For this purpose we require a location server
which keeps the track of the machine where
the object’s server is currently running .
• Now, the object reference can contain the
network address of the location server along
with a global identifier for the server.

14. Static v/s Dynamic Remote Method
Invocations

15. Static Invocation
• We can make use of an object-based language such as
Java, that will handle stub generation automatically.
• This approach of using predefined interface definitions is
referred to as static invocation.
• Static invocations require that the interfaces of an object
are known when the client application is being
developed.
• It also implies that if interfaces change, then the client
application must be recompiled before it can make use of
the new interfaces.

16. Dynamic Invocation
• Composing a method invocation at run-time is referred
to as a dynamic invocation.
• It generally takes a form such as
invoke(object, method, input_parameters, output_parameters);
where object identifies the distributed object, method is
a parameter specifying exactly which method should be
invoked, input_parameters is a data structure that holds
the values of that method’s input parameters, and
output_parameters refers to a data structure where
output values can be stored.

17. Parameter Passing

18. Pass by Reference
• RMI lets you get "references" to remote objects, and
since it has to be requested ahead of time, passing
one of your objects to the server will result in a copy.
• The drawback of pass by reference is that you can
pass around remote objects by reference, but you
cannot pass local objects back to the server as
references.

19. Pass by Value
• When invoking a method with an object reference as
parameter, that reference is copied and passed as a value
parameter, only when it refers to a remote object.
• In this case, the object is literally passed by reference.
• However, when the reference refers to a local object, that
is an object in the same address space as the client, the
referred object is copied as a whole and passed along
with the invocation. In other words, the object is passed
by value.

21. Example 1: DCE Remote Objects

22. Distributed Computing Environment
• DCE is one of the first distributed systems
constructed as middleware on top of existing
operating systems.
• DCE objects are interesting as they form a direct
refinement of the RPC-based client-server model,
and thus forming a shift from remote procedure calls
to remote method invocations.

23. The DCE Distributed-Object Model
• Distributed objects have been added to DCE in the form
of extensions to their Interface Definition Language (IDL),
along with C++ language bindings.
• Two types of distributed objects are supported.
i. Distributed dynamic object is an object that a server
creates locally on behalf of a client which is
accessible only to that client.
ii. Distributed named objects are by a server to have it
shared by several clients. Named objects are
registered with a directory service so that a client
can look up the object and subsequently bind to it.

25. DCE Remote Object Invocation
• Each remote object invocation in DCE is done by means of an RPC.
• Because a server may have thousands of objects to serve, DCE offers the
possibility to place objects in secondary storage instead of keeping all
objects active in the main memory.
• When an invocation request comes in, the server first retrieve the object
from secondary storage and place it into the server’s address space.
• After the object is placed into main memory, the invocation can take
place.
• Distributed objects in DCE has no mechanism for transparent object
references. In this case, a client can use a binding handle associated with
a named object.
• A binding handle contains an identification of an interface of the object ,
the transport protocol used for communicating with the object’s server,
and the server’s host address and endpoint.

26. Example 2: Java RMI

27. • In DCE, distributed objects have essentially been
added as a refinement of RPCs.
• In Java, distributed objects have been integrated into
the language to keep as much of the semantics of
non-distributed objects as possible.
• In other words, the Java developers have aimed for a
high degree of distribution transparency.

28. Java Distributed-Object Model
• Java adopts remote objects as the only form of distributed
objects. [i.e., objects whose state only resides on a
single machine]
• Java allows each object to be constructed as a monitor by
declaring a method to be synchronized.
• However there are problems with distributed synchronization.
• Thus, Java RMI restricts blocking on remote objects only to
the proxies.
• This means remote objects cannot be protected against
simultaneous access from processes operating on different
proxies by using synchronization methods.
• Explicit distributed locking techniques must be used.

29. Java Remote Object Invocation
• Any primitive or object type can be passed as a parameter to
an RMI provided the type can be marshaled, i.e., it must be
serializable.
• Platform dependent objects such as file descriptors and
sockets cannot be serialized.
• A remote object is built from a server class and a client class.
• Proxies are serializable in Java.
• This means proxies can be marshaled.
• In actually an implementation handle is generated, specifying
which classes are needed to construct the proxy.
• The implementation handle replaces the marshaled code as
part of a remote object reference.
• This passing of proxies as parameters works only because
each process is executing the same Java virtual machine.