RMI
Introduction RMI (Remote Method Invocation)
The Java allows us to develop distributed applications using RMI. Distributed computing refers to the
application design paradigm in which programs, the data they process, and the actual computations are spread
over a network either to leverage the processing power of multiple computers or due to the inherent nature of an
application computing different modules.
RMI (Remote method Invocation) allows object-o-object communication between different Java Virtual
Machines (JVMs).
JVMs can be distinct entities located on the same or separate computers –yet one JVM can invoke methods
belonging to an object stored on another JVM. This enables applications to call object methods located
remotely, sharing resources, and processing load across systems. Methods can even pass objects that a foreign
virtual machine has never encountered before, allowing the dynamic loading of new classes as required. This is
really a quite powerful feature.
Other Alternatives to RMI:• Sockets• EJB• CORBA• DCOM
Basic network programming with sockets is flexible and sufficient for communication between programs.
However, it requires all the involved parties to communicate via application-level protocols, the design of
which is complex and can be error prone. For example, consider a collaborative application like a simple chat
application for instance: for multiple clients to participate we would first need to design some sort of protocol,
and then use sockets to communicate in that protocol with the server. RMI, on the other hand, is a distributed
system that internally uses sockets over TCP/IP.
application design paradigm in which programs, the data they process, and the actual computations are spread
over a network either to leverage the processing power of multiple computers or due to the inherent nature of an
application computing different modules.
RMI (Remote method Invocation) allows object-o-object communication between different Java Virtual
Machines (JVMs).
JVMs can be distinct entities located on the same or separate computers –yet one JVM can invoke methods
belonging to an object stored on another JVM. This enables applications to call object methods located
remotely, sharing resources, and processing load across systems. Methods can even pass objects that a foreign
virtual machine has never encountered before, allowing the dynamic loading of new classes as required. This is
really a quite powerful feature.
Other Alternatives to RMI:• Sockets• EJB• CORBA• DCOM
Basic network programming with sockets is flexible and sufficient for communication between programs.
However, it requires all the involved parties to communicate via application-level protocols, the design of
which is complex and can be error prone. For example, consider a collaborative application like a simple chat
application for instance: for multiple clients to participate we would first need to design some sort of protocol,
and then use sockets to communicate in that protocol with the server. RMI, on the other hand, is a distributed
system that internally uses sockets over TCP/IP.
RMI Architecture
RMI’s purpose is to make objects in separate JVM’s look alike and act like local objects. The JVM that calls theremote object is usually referred to as a client and the JVM that contains the remote object is the server.
One of the most important aspects of the RMI design is its intended transparency. Applications do not know
whether an object is remote or local. A method invocation on the remote object has the same syntax as a method
invocation on a local object, though under the hood there is a lot more going on.
• In RMI the term “Server” does not refers to a physical server or application but to a single remote objecthaving methods that can be remotely invoked.Similarly the Term “Client” does not refer to a client m/c but actually refers to the object invoking a remote method on a remote object.
• The same object can be both a client and a server.
Although obtaining a reference to a remote object is somewhat different from doing so for local objects. Once
we have the reference, we use the remote object as if it were local. The RMI infrastructure will automatically
intercept the method call, find the remote object and process the request remotely. This location transparency
even includes garbage collection.
A remote object is always accessed via its remote interface. In other words the client invokes methods on the
object only after casting the reference to the remote interface.
The RMI implementation is essentially built from three abstraction layers:
• The Stub/Skeleton Layer• The Remote Reference Layer
•The Transport Layer
The following diagram shows the RMI Architecture:
The Stub/Skeleton Layer
This layer intercepts method calls made by the client to the interface reference and redirects these calls to a
remote object. Stubs are specific to the client side, whereas skeletons are found on the server side.
To achieve location transparency, RMI introduces two special kinds of objects known as stubs and skeletons
that serve as an interface between an application and rest of the RMI system. This Layer’s purpose is to transfer
data to the Remote Reference Layer via marshalling and unmarshalling. Marshalling refers to the process of
converting the data or object being transferred into a byte stream and unmarshalling is the reverse - converting
the stream into an object or data. This conversion is achieved via object serialization.
The Stub/ Skeleton layer of the RMI lies just below the actual application and is based on the proxy design
pattern. In the RMI use of the proxy pattern, the stub class plays the role of the proxy for the remote service
implementation. The skeleton is a helper class that is generated by RMI to help the object communicate with the
stub; it reads the parameters for the method call from the link, makes the call to the remote service
implementation object, accepts the return value and then writes the return value back to the stub.
In short, the proxy pattern forces method calls to occur through a proxy that acts as a surrogate, delegating all
calls to the actual object in a manner transparent to the original caller.
Stub
The stub is a client-side object that represents (or acts as a proxy for) the remote object. The stub has the same
interface, or list of methods, as the remote object. However when the client calls a stub method, the stub
forwards the request via the RMI infrastructure to the remote object (via the skeleton), which actually executes
it.
Sequence of events performed by the stub:• Initiates a connection with the remote VM containing the remote object
• Marshals (writes and transmits) the parameters to the remote VM.
• Waits for the result of the method invocation.
• Unmarshals (reads) the return value or exception returned.
• Return the value to the caller
In the remote VM, each remote object may have a corresponding skeleton.
Skeleton
On the server side, the skeleton object takes care of all the details of “remoteness” so that the actual remote
object does not need to worry about them. In other words we can pretty much code a remote object the same
way as if it were local; the skeleton insulates the remote object from the RMI infrastructure.
Sequence of events performed by the skeleton:
• Unmarshals (reads) the parameters for the remote method (remember that these were marshaled by the stub
on the client side)
• Invokes the method on the actual remote object implementation.
• Marshals (writes and transmits) the result (return value or exception) to the caller (which is then
unmarshalled by the stub)
The Remote Reference Layer
The remote reference layer defines and supports the invocation semantics of the RMI connection. This layer
maintains the session during the method call.
The Transport Layer
The Transport layer makes the stream-based network connections over TCP/IP between the JVMs, and is
responsible for setting and managing those connections. Even if two JVMs are running on the same physical
computer, they connect through their host computers TCP/IP network protocol stack. RMI uses a protocol
called JRMP (Java Remote Method Protocol) on top of TCP/IP (an analogy is HTTP over TCP/IP).
From the JDK 1.2 the JRMP protocol was modified to eliminate the need for skeletons and instead use
reflection to make connections to the remote services objects. Thus we only need to generate stub classes in
system implementation compatible with jdk 1.2 and above. To generate stubs we use the Version 1.2 option
with rmic.
The RMI transport layer is designed to make a connection between clients and server, even in the face of
networking obstacles. The transport layer in the current RMI implementation is TCP-based, but again a UDPbased
transport layer could be substituted in a different implementation.
This layer intercepts method calls made by the client to the interface reference and redirects these calls to a
remote object. Stubs are specific to the client side, whereas skeletons are found on the server side.
To achieve location transparency, RMI introduces two special kinds of objects known as stubs and skeletons
that serve as an interface between an application and rest of the RMI system. This Layer’s purpose is to transfer
data to the Remote Reference Layer via marshalling and unmarshalling. Marshalling refers to the process of
converting the data or object being transferred into a byte stream and unmarshalling is the reverse - converting
the stream into an object or data. This conversion is achieved via object serialization.
The Stub/ Skeleton layer of the RMI lies just below the actual application and is based on the proxy design
pattern. In the RMI use of the proxy pattern, the stub class plays the role of the proxy for the remote service
implementation. The skeleton is a helper class that is generated by RMI to help the object communicate with the
stub; it reads the parameters for the method call from the link, makes the call to the remote service
implementation object, accepts the return value and then writes the return value back to the stub.
In short, the proxy pattern forces method calls to occur through a proxy that acts as a surrogate, delegating all
calls to the actual object in a manner transparent to the original caller.
Stub
The stub is a client-side object that represents (or acts as a proxy for) the remote object. The stub has the same
interface, or list of methods, as the remote object. However when the client calls a stub method, the stub
forwards the request via the RMI infrastructure to the remote object (via the skeleton), which actually executes
it.
Sequence of events performed by the stub:• Initiates a connection with the remote VM containing the remote object
• Marshals (writes and transmits) the parameters to the remote VM.
• Waits for the result of the method invocation.
• Unmarshals (reads) the return value or exception returned.
• Return the value to the caller
In the remote VM, each remote object may have a corresponding skeleton.
Skeleton
On the server side, the skeleton object takes care of all the details of “remoteness” so that the actual remote
object does not need to worry about them. In other words we can pretty much code a remote object the same
way as if it were local; the skeleton insulates the remote object from the RMI infrastructure.
Sequence of events performed by the skeleton:
• Unmarshals (reads) the parameters for the remote method (remember that these were marshaled by the stub
on the client side)
• Invokes the method on the actual remote object implementation.
• Marshals (writes and transmits) the result (return value or exception) to the caller (which is then
unmarshalled by the stub)
The Remote Reference Layer
The remote reference layer defines and supports the invocation semantics of the RMI connection. This layer
maintains the session during the method call.
The Transport Layer
The Transport layer makes the stream-based network connections over TCP/IP between the JVMs, and is
responsible for setting and managing those connections. Even if two JVMs are running on the same physical
computer, they connect through their host computers TCP/IP network protocol stack. RMI uses a protocol
called JRMP (Java Remote Method Protocol) on top of TCP/IP (an analogy is HTTP over TCP/IP).
From the JDK 1.2 the JRMP protocol was modified to eliminate the need for skeletons and instead use
reflection to make connections to the remote services objects. Thus we only need to generate stub classes in
system implementation compatible with jdk 1.2 and above. To generate stubs we use the Version 1.2 option
with rmic.
The RMI transport layer is designed to make a connection between clients and server, even in the face of
networking obstacles. The transport layer in the current RMI implementation is TCP-based, but again a UDPbased
transport layer could be substituted in a different implementation.
RMI API :
Locating Remote Objects
Clients find remote services by using a naming or directory service. A naming or directory service is run on ahost and port number that the client is already aware of (for example a well-known port on a public host).
The RMI naming service, a registry, is a remote object that serves as a directory service for clients by keeping a
hash table like mapping of names to other remote objects. It is not necessary to have a single registry on a
particular physical host. An object is free to start its own registry. The behavior of the registry is defined by the
interface java.rmi.registry.Registry. RMI itself includes a simple implementation of this interface
called the RMI Registry. RMI Registry runs on each machine that hosts remote objects and accepts queries for
services, by default on port 1099.
In Simple terms, a remote object is associated with a name in the registry. Any time the client wants to invoke
methods on this remote object it obtains a reference to it by looking up the name. The lookup returns a remote
reference, a stub to the object.
RMI also provides the java.rmi.Naming class that serves as the client’s interaction point with the object
serving as the registry on the host for this lookup. This can be thought of as a client of the RMI Registry.
The naming class’s methods take, as one of their arguments, a name that is a URL-formatted
java.lang.String.
The following diagram shows how the client uses the java.rmi.Naming class to lookup the stub/proxy of the
remote object.
The program which creates the instance of the remote object also makes use of the java.rmi.Naming class to
bind the remote object to the RMI Registry.
The java.rmi.Naming class
This class behaves as a client to the RMI Registry. It is used on the server side as well as on the client side to
interact with the RMI Registry. On the server side it is used to bind the remote object to the RMI Registry. On
the client side it is used to lookup the remote object.
Methods
All the methods of this class are static.
• public static void bind (String name, Remote obj)
It binds the remote object to a string name. The name itself is in the RMI URL format.
• public static Remote lookup (String name)
It returns a reference, a stub, for the remote object associated with the specified name.
• public static void rebind (String name, Remote obj)
It rebinds (unbinds the name if it is already bound and binds it again) the specified name if it already in use
to a new remote object. This could be dangerous if different applications use the same name in the registry
but is helpful in development.
• public static void unbind (String name)
It removes the binding with specified name.
Once the client has a stub to the requested object, it can access the remote method transparently, just like local
methods.
The URL takes the form:
rmi://<host_name>[:<name_service_port>]/<service_name>
Where:
• host_name is a name recognized on the local area network (LAN) or a DNS name on the Internet.
• name_service_port needs to be specified only if the naming service is running on a port other than the default 1099
• service_name is the string name that the remote object is associated with in the registry.
bind the remote object to the RMI Registry.
The java.rmi.Naming class
This class behaves as a client to the RMI Registry. It is used on the server side as well as on the client side to
interact with the RMI Registry. On the server side it is used to bind the remote object to the RMI Registry. On
the client side it is used to lookup the remote object.
Methods
All the methods of this class are static.
• public static void bind (String name, Remote obj)
It binds the remote object to a string name. The name itself is in the RMI URL format.
• public static Remote lookup (String name)
It returns a reference, a stub, for the remote object associated with the specified name.
• public static void rebind (String name, Remote obj)
It rebinds (unbinds the name if it is already bound and binds it again) the specified name if it already in use
to a new remote object. This could be dangerous if different applications use the same name in the registry
but is helpful in development.
• public static void unbind (String name)
It removes the binding with specified name.
Once the client has a stub to the requested object, it can access the remote method transparently, just like local
methods.
The URL takes the form:
rmi://<host_name>[:<name_service_port>]/<service_name>
Where:
• host_name is a name recognized on the local area network (LAN) or a DNS name on the Internet.
• name_service_port needs to be specified only if the naming service is running on a port other than the default 1099
• service_name is the string name that the remote object is associated with in the registry.
Developing Applications with RMI
Steps for developing RMI applications are as follows:1. Defining the remote interface.
2. Implementing the remote interface.
3. Writing the code for registering the object.
4. Writing the client that uses the remote objects.
5. Generating stubs (client proxies) and skeletons (server entities).
6. Running the RMI Registry, server and client.
1. Defining the Remote Interface
An interface manifests the exposed operations and the client programmer need not be aware of the
implementation (the interface in this case also serves as a marker to the JVM). A remote Interface by definition
is the set of methods that can be invoked remotely by a client:
• The remote interface must be declared public or the client will get an error when it tries to load a remote
object that implements the remote interface.
• The remote interface must extend the java.rmi.Remote interface.
• Each method must throw a java.rmi.RemoteException (or a superclass of RemoteException)
• If the remote methods have any remote objects as parameters or return types, they must be interface types
not the implementation classes.
Note: java.rmi.Remote interface has no methods. It is just a marker interface.
Example: The example discussed in the following sections illustrates how to define and invoke methods on a
remote object.
We will define our Remote Interface (HelloInterface.java) as follows:
2. Implementing the Remote Interface
The implementing class is the actual class that provides the implementation for methods defined in the remote
interface. The java.rmi.server.RemoteObject extends the functionality provided by the java.lang.Object
class into the remote domain by overriding the equals(), hashcode() and toString() methods. The generic
java.rmi.server.RemoteObject is an abstract class and describes the behavior of remote objects.
The abstract subclass java.rmi.server.RemoteServer describes the behavior associated with the server
implementation and provides the basic semantics to support remote references.
java.rmi.RemoteServer has two concrete sub-classes
• java.rmi.server.UnicastRemoteObject
It designs a non-replicated remote object whose reference is valid only when the server is alive.
• java.rmi.activation.Activatable
It is the concrete class that defines behavior for on demand instantiation of remote objects.
In addition to one of the above classes, the class corresponding to the remote interface must implement one or
more interfaces that define the remote methods. A remote class can define any methods but only methods in the
remote interface can be invoked remotely.
3. Registering the Remote Object
Now that we have the interface and the implementation, we need to make this object available to clients by
binding it to a registry. This will allow the clients to look the object up on the host by a String name.
The stubs and skeletons (if any) are needed for registration. After all it is the object stub that is going to be
passed around from the registry to the clients.
4. Writing the Client that uses the Remote Object
The client performs a lookup on the registry on the host and obtains a reference to the remote object. Note that
casting to the remote object is critical. In RMI, clients always interact with the interface, never with the object
implementation.
5. Generating Stubs and Skeletons
Now that we have the remote interface and implementation, we can generate the skeletons and stubs (or only
stubs in java 1.2 or higher version) with the rmic tool after we have compiled the classes. Remember to set the
directory that you are working from in your classpath; you can then use the following line in a command
window:
rmic -v1.2 HelloServer
This will generate stub class “HelloServer_Stub.class”.
Note: It is worth keeping in mind that while starting the registry all classes and stubs must be available in the
classpath or the classpath should not be set at all, to support dynamic loading.
6. Running the RMI Registry, Client and the Server
The steps for running the RMI application are:
1. Start RMI Registry: Ensure that the following classes are present in the current folder or the classpath:
• HelloInterface.class
• HelloServer_Stub.class
Start the RMI Registry by giving the command:
rmiregistry
2. Start Server: Ensure that the following classes are in the current folder or the classpath:
• HelloInterface.class
• HelloServer.class
• HelloServer_Stub.class
• MyRMI.class
Run the MyRMI program.
D:sumit miin>java -Djava.rmi.server.codebase="file:///d:/sumit/rmi/bin/" org
.test.MyRMI
3. Run Client: Ensure that the following classes are in the current folder or the classpath:
• HelloInterface.class
• HelloServer_Stub.class
• HelloClient.class
Run the HelloClient program :)
No comments:
Post a Comment