Java Remote Method Invocation

Java RMI

RMI is a cross between remote procedure call and mobile objects
A server-side object is created, along with a stub object
Both the server-side object and the stub implement a "well known" interface
The server-side object remains on the server, and receives and executes remote method calls
The stub is moved as a mobile object to a client
The client makes calls on the stub which makes remote calls on the server-side object

Downloading classes

Both the client and the server object implement an interface known to both
The class files for this interface must be in the CLASSPATH of both the client and the server
If you don't know the interface, you can't use RMI
The class files for the stub will usually be loaded from a different machine to the client's machine
The class files for the stub are usually placed on an HTTP server <

Generating stubs

You start with an interface specification for e.g. Service.java
You write an implementation that implements the service
```
public class ServiceImpl implements Service {...}
```
Compile the service javac *.java
The tool rmic will generate stubs from an implementation object
```
      rmic ServiceImpl
      
```
A common option is to use the Java 1.2 version
```
      rmic -v1.2 ServiceImpl
      
```
After creating the class file ServiceImpl_Stub it must be copied to a directory where an httpd server can deliver it to clients
```
      cp ServiceImpl_Stub.class /var/httpd/html/classes/ServiceImpl_Stub.class
      
```

RMI requirements on interfaces

To use RMI, you start with an interface that both client and server will know about
This interface must also satisfy some requirements for RMI
- The interface must extend the Remote interface
- Every method must be declared to throw a RemoteException
e.g.
Later:
- Your implementation does not have to throw any exceptions: they will be thrown by the stub. But you have to declare them anyway
- The parameters and result in any implementation must either be remote objects too, or implement java.io.Serialisable

Remote object implementation

An implementation must implement the "well known" remote interface
It usually subclasses java.rmi.server.UnicastRemoteObject
It must have a zero args constructor
e.g.

Remote object server

Every remote object must have a server
The role of the server is
- create the object
- export it to the RMI runtime system - this is done automatically by the zero args constructor
- make it publically visible in some way
- stay alive to respond to calls on the object - this is done automatically by the RMI runtime because it spawns another thread during construction
- Let the client know where the class files are stored. This is done by setting the property java.rmi.server.codebase to a URL
e.g.

Client

The client must locate the service in some way
Once it has done this, it can make calls on the client
e.g.

Advertising and finding objects

One way that can be used is the RMI registry
This is a simple database of remote objects
One registry must run on each machine that is exporting objects (damaged security model)
The registry should be run with a classpath that does not include the implementation files, or it tries to deliver them from its own class files instead of the remote ones

Objects are advertised using the static method


      Naming.rebind(String advertisedName, Object obj);

Objects are found using the RMI protocol
- This uses urls of the form
```
	    rmi://host/advertisedName
	    
```
  (Note: the host should not be localhost since that will break as soon as you use two or more machines)
- Then a request is made to the registry
```
	    Object Naming.lookup(String url)
	    
```
The registry is started by
```
      rmiregistry
      
```

Security

RMI downloads remote objects which run within the client's JVM
This code could do malicious things
A security manager protects against harmful code
The RMISecurityManager should be used when dealing with remote code

Complete example code

Interface
Implementation
Server
```
      
  
```


  
      Client
  
      
  
  
      Permissive policy file (save as policy.all)
      
grant {
    permission java.security.AllPermission "", "";
};
      
  
  
      Run in separate windows each of the following commands
      
      rmiregistry
      java -Djava.rmi.server.codebase=... Server
      java -Djava.security.policy=policy.all Client






 Non-remote objects 



  
      A remote method call may have parameters or result
      that are themselves objects
  
  
      The parameter may be a variety of objects
      
	
	    It could be the stub for a server-side object
	
	
	    It could be a client-side object that has a stub
	    that can be exported
	
	
	    It could be a client-side object that is
	    Serialisable
	
	
	    It could be a client-side object that does not have an
	    exportable stub and does not implement Serialisable -
	    this is an error and will either throw an exception or
	    pass a null object
	
      
  
  
      The result may be
      
	
	    A server-side object with a stub that can be exported
	
	
	    A server-side object that implements Serialisable
	
	
	    A server-side that does neither - this is an error
	
      
  




 Example 


A FireStation may have a method
    FireEngine raiseAlarm(FireEvent evt)

A home may get a stub for a fire station, to raise alarms when a fire event
occurs. In return, it gets a fire engine.








 Under the hood - UnicastRemoteObject 



  
      A remote object usually inherits from this class, or calls
      exportObject() on it
  
  
      When an object is exported, a server is set up to listen to
      remote requests for the object
  
  
      The server reads requests from the network, unmarshals them,
      calls methods on the remote object, marshals the result
      and sends it back
  
  
      The class also creates a stub object using reflection
  





 Under the hood - stub object 



  
      An RMI server programmer never sees the stub object
  
  
      Special code in the Java runtime looks out for remote objects
      and substitutes the stub object - this is a bit strange
  
  
      For example, in Naming.rebind(Remote), the
      stub is substituted and sent to the naming service
  





 JRMP 



  
      JRMP is Java Remote Method Protocol
  
  
      It defines the wire format for RMI messages
  






 Alternative mechanisms 



  
      RMI is similar to CORBA and other remote method/procedure call systems
  
  
      So it should be possible to have RMI-like mechanisms in these other systems
  
  
      RMI-IIOP is RMI for CORBA, using the CORBA wire format IIOP
  
  
      Jeri (Jini extensible remote invocation) is a cleaned-up version of RMI
      that can use lots of different transport mechanisms
  





 RMI-IIOP 



  
      CORBA allows objects in different languages on different machines to interact
  
  
      RMI allows Java objects on different machines to interact
  
  
      If an interface is defined as both an RMI and a CORBA interface, then
      it is possible to create both RMI and CORBA objects
  
  
      The rmic stub generator has options to create the RMI stub
      which uses IIOP instead of JRMP
  
  
      By then treating it as a CORBA object, it can be run from a CORBA server,
      registered with a CORBA naming service or accessed by a CORBA client
  
  
      This is Java-specific - you cannot get a Java RMI object to talk to
      a C++ object
  
  
      The mechanism is supported by Enterprise Java Bean containers
  






Jan Newmarch <jan@newmarch.name>

Last modified: Tue Sep 19 15:22:51 EST 2006