Back 2 Basics : RMI
Intro and Basics
RMI forms the basis for Java's own remoting capabilities. RMI makes remoting transparent by making remote objects look like local objects. The only difference from a user of a remote service's user's perspective would be how the object itself is obtained. RMI is based on 3 abstraction layers.- Stub / Skeleton layer
- Remote Reference layer
- Transport layer
Stubs and Skeletons
Stubs and skeletons are special objects that make remoting with RMI possible. The client actually invokes the method on the client side object called Stub, though this is transparent to the client, since the client uses an interface type. The method call and the parameters are intercepted by the Stub, marshalled (something like serialized) across to the Skeleton, a server side object which un-marshalls (deserializes) the method call and parameters and makes the call to the actual object. The return value is intercepted by the skeleton and sent back to the Stub, who in turn returns it to the client. The stub is a proxy on the client side and the skeleton is a helper class that acts as liaison or connector between the Stub and the actual object. The Stub passes the data to the remote reference layer, which hands it to the skeleton.Remote Reference Layer
The remote reference later defines the semantics for remote object references. It connects the and governs the communication between the the Stub and the Skeleton. Its is JRMP specific and defines classes like RemoteRef which are used by the Stub to get data across to the Skeleton. From Java 2, remote reference layer adds semantics for activatable objects. Another example of the semantics defined and managed by this layer is Multi-cast , in which the method is invoked on several remote implementations and he first response to return is used.The Transport Layer
The transport layer is responsible for the low level connection between the two JVMs, and management of these connections. RMI defines a wire level protocol called JRMP, JRMP is on P/IP and also provides some firewall penetration strategies. JRMP was updated in java 2, to eliminate skeletons and to use reflection instead.Looking up Remote objects
A client can use either JNDI or the more simpler RMI registry to look-up the remote objects. We will not discuss JNDI here. The RMI registry itself is a remote object., and implements the interface java.rmi.registry.Registry. RMI registries can be started as a separate process or in a programmatic way, by an object itself, and by default runs on the port 1099. Starting a registry means exporting the remote object that implements the Registry interface, that is the actual resgisty itself is a remote object. Once a remote object is bound to a registry under a public name, a client can look-up the registry for a remote object based on the name with which it was bound. Here's what happens :- The client tries to get a registry, which gets him a Stub that acts as the client proxy to the registry, [This step is usually transparent because JDK classes d the job of getting the registry]
- The client makes a "look-up" on the registry with the pubic name with which the remote object was bound
- A Stub to the remote object is returned to the client.
- The client can now invoke methods on the remote object just as if it were a local object.
Parameter Passing
With RMI we have three types of parameters :- Primitive params : these are passed by value , just like any other primitive parameter.
- Object parameters : Since references in one JVM are meaningless in another JVM, objects are serialized and passed by value. So changing the properties of an object in the remote JVM does not make those changes visible to the local JVM.
- Remote Params : Remote params are params that happen to be remote objects themselves. When a remote object is used as a parameter or a return type, the JVM passes the stub to the remote object and not the remote object itself. Under the covers the JVM checks the parameters and return types. if any of them is an instance of Remote, then its stub is fetched, serialized and sent across, instead of the actual remote object. this rule applies to all references, including say, retuning 'this' from a remote object.
Distributed Garbage Collection
RMI provides a distributed garbage collector to gc the remote objects. GC in RMI is more complex because there may not be any local references to an object. Internally, the JVM keeps track of clients requesting access to a remote object, and marks that object as dirty. When the remote reference is dropped, the object is marked clean; all clean objects are eligible for garbage collection when the DGC runs. In addition to the reference counting mechanism, there is a lease mechanism, which basically means that even if a client requested access to a remote object, unless the client is actively using the connection, the connection has a timeout associated with it (default 10 mins), and when the timeout has been reached, the object is marked clean. Like the finalize() method, RMI has an interface Unreferenced, with a single method unreferenced() that is invoked when there are no more clients holding a live connection to the remote object. Remember that the registry itself is a client to the remote object and the unreferenced method on a remote object(should it choose to implement Unreferenced) will not be invoked if the registry is holding a reference to it.Dynamic Class Loading
Normally the clients needs to have the remote interface type class files available on the client JVM so that they can use it to cast the resulting stub from from a look-up and invoke methods on it. However, RMI support dynamic class loading as an alternative to this static approach. Dynamic class loading in RMI works similar to applets; a system property for a codebase is set and the required class definitions are downloaded on demand from that code base. the property is java.rmi.server.codebase and is a URL that can be accessed with file:// ftp:// or http:// protocols. note that though we say "client jvms download the class def" its not restricted to client JVMs. server JVMs can also use a code base to download other remote object definitions or client side classes for callbacks. When an object is bound in the registry, the code base is also saved with it.When a client requests a remote object, the registry returns a stub to the remote object, and the client JVM looks for the class definition of the stub in its CLASSPATH and if it does not find it there, it uses the code base from the registry, to download the definitions. RMI has its own Security manager, the RMISecurityManager and the VM will not download any files unless the security manager is present.Advanced RMI
Object Activation
One of the downsides to RMI is that the remote objects have to be accessible at all times, including when clients are not executing or requesting their services, and eats up a lot of resources. To solve this problem object activation was introduced. This is similar to having the remote objects on an "as required" basis, and can be though similar to lazily instantiated references. All the magic happens in the Remote reference layer, and the stub given to client is not connected to a live remote object or its skeleton, instead its connected to the activation system, that transparently makes resources available when the stub is actually being used. Tha activations system is a complex ecosystem and core t it is an RMI daemon 'rmid' which is able to startnew VM instances for the required remote objects 'On Demand'.
Activatable Remote objects extend from the abstract class Activatable(no this is not an interface) and not from the usual UnicastRemoteObject. The process of registering an activatable remote object is also considerably different, though the client does not see any difference. The steps are :
- install the SecurityManager - RMISecurityMananger
- create an ActivationGroup - which is an object that keeps a collection of activatable objects
- create an ActivationDesc - or ActivationDescriptor instance, that provides all information to the rmid (the Activator) to create a new instance of the Implementation class.
- register the remote interface with the Activativator - Activatable.register() registers the Remote interface with the rmid
- bind the stub that was returned as a result of register() with the RMIRegistry.
once this rig is setup, Activation process works like this :
- The Stub for the Activatable object contains special information like the ActivationID that idetifies an Activatable.
- The stub uses this ActivationID to call on the Activator (rmid) to activate the object.
- The activator (rmid) uses the ActivationDescriptor to find the JVM in which the object is to be activated.
- The activator locates the ActivationGroup and if the ActivationGroup does not yet exist, then a new JVM is created for the AcivationGroup to run in and the request for the object's activation is forwarded to the ActivationGroup.
- The ActivationGroup loads the class and creates a new instance of the remote object.
- The live reference of the real remote object is returned to the Activator , which records the ActiovationID and reference pairing and the live reference is returned to the stub.
- The stub now forwards all method invocations to the remote object via the live reference.
HTTP Tunneling
Firewalls prevent application / non-standard ports from being opened up in a public network, we can use HTTP tunneling to get RMI working. Tunnelling is essentially wrapping up the RMI calls inside an HTTP POST request. Its the responsibility of the Transport layer to do this wrapping. There are two ways to do this :
- HTTP to port : Used when the client of an RMI service is behind a firewall. The JRMP call data is automatically wrapped in an HTTP POST and sent to the proxy server on the client. This proxy server is the http proxy server the client uses to connect to the public network. The only config required to do this is to set the proxy server settings via java system properties.
- HTTP to CGI : is used when the the server is behind a firewall and cannot accept incoming connections. Here the transport layer redirects http wrapped JRMP calls to a cgi script running in a webserver. This cgi script is java-rmi and is a part of the JDK ( see bin directory). A servlet version of the cgi is also available. The cgi intercepts requests coming on 80, which is intended for a non-default port (the client transport layer embeds this info if its wrapping up the JRMP call in http) and forwards the call to the local port.
Although tunnelling is a very attractive solution to the problem of firewalls, they should be carefully used because there will be severe performance degradation, and the cgi script is actually a security hole and tunneled applications cannot use callbacks.
RMI IIOP - CORBA Interoperability
RMI-IIOP was designed to make RMI applications interoperable with CORBA applications. This involves supporting both the RMI's own wire protocol JRMP s well as CORBA's wire protocol IIOP. The interoperability is achieved by letting java developers use a Java interface and the CORBA developers use the IDL for coding. With an RMI-IIOP server, the remote interface can be used to generate the corresponding IDL for a CORBA C++ Client. The clients can also use a IDL to java conversion to convert IDL to a Java Interface, enabling the RMI-IIOP client to connect to a CORBA server. The stubs for an RMI-IIOP Client should be generated with the -iiop option so that they can use the IIOP protocol.CORBA compliant remote objects are derived from the PortableRemoteObject and they need to be rmic'd with the -iiop option to tell the compiler to generate Stubs and skeletons that can speak RMI-IIOP. They form the foundation for the enterprise level distributed computing in java and the heart of the EJB programming model, though EJBs would make most of this transparent to the developer. Another crucial difference is that in a plain vanilla RMI-IIOP environment, the rmi registry is replaced by JNDI using a COS Naming Service like tnameserv or an LDAP server. Distributed garbage collection is not supported by CORBA, which means objects have to be created and destroyed explicitly. The RMI activation system is replaced by the PortableObjectAdaper and the remote references have to be down cast using the OPrtablRemoteObject's narrow() method and not using a normal java cast.
