Java Remote Method Invocation
Mohammad Masudur Rahman
Department of Computer Science
University of Saskatchewan
call. RPC systems encode arguments and return values using
an external data representation, such as XDR.
RPC, however, doe...
Fig. 1. RMI Layered Architecture[2]
Fig. 2. How RMI Works[8]

to the client-side transport, then up through the server-sid...
A method that accepts as a parameter an integer, finds
whether it is a prime number or not, and returns a boolean


//MathService Server or Provider

To identify a service, we specify an RMI URL. The URL
contains the host name on which the service is located, and
the logi...
//MathService Client

Here, the first part of the command specifies the policy
file, second part is the client class itself and the last part
7) Write Once, Run Anywhere: RMI is part of Java’s ”Write
Once, Run Anywhere” approach. Any RMI based system
is 100% porta...
In this tutorial, we provided a simple overview about Java
RMI technology including a simple application d...
Upcoming SlideShare
Loading in …5

Java RMI Detailed Tutorial


Published on

A Java RMI detailed tutorial for starting users.

Published in: Education, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Java RMI Detailed Tutorial

  1. 1. Java Remote Method Invocation Mohammad Masudur Rahman Department of Computer Science University of Saskatchewan Saskatoon, Canada Abstract—Java Remote Method Invocation (RMI) is a distributed object technology which allows an application to invoke methods from remote java objects hiding socket level details. It can be considered as an object version of Java RPC. It is mainly a java-centric technology and it has three major parts - client part which invokes the remote method, server part which allows client to invoke methods and RMI registry which maintains the remote object references for both client and server. This is an easy to use, cross-platform distributed object technology which leverages the whole power of Java technology. In this tutorial, we have provided an overview of Java RMI technology and developed a simple RMI application. We have also discussed about the strengths and weaknesses of the technology which is followed by a comparative study between RMI and another distributed object technology called CORBA. Index Terms—Java RMI; Distributed Object; RPC; IIOP; CORBA I. I NTRODUCTION Remote method invocation (RMI) is a technology that allows applications to call object methods located remotely, sharing resources and processing load across systems in a distributed environment. It facilitates object function calls between Java Virtual Machines (JVMs). JVMs can be located on separate computers - yet one JVM can invoke methods belong to an object stored in another JVM[3]. Java has builtin support for RMI through Java RM I AP I. The original implementation depends on Java Virtual Machine (JVM) class representation mechanisms and it thus only supports making calls from one JVM to another. The protocol underlying this Java-only implementation is known as Java Remote Method Protocol (JRMP). In order to support code running in a nonJVM context, there is also a version compliant with CORBA technology [17]. Unlike other systems for remote execution which require that only simple data types or defined structures be passed to and from methods, RMI allows any Java object type to be used - even if the client or server has never encountered it before[3]. It can be also considered as an object version of Remote Procedure Call (RPC). RMI allows both client and server to dynamically load new object types as required. Basically, RMI uses object serialization1 to marshal2 and unmarshal parameters and does not truncate types, supporting true objectoriented polymorphism. 1 A process to convert the object into a stream of bytes suitable for storage or transmission over network 2 A similar process like serialization except it records object’s state, code base and treat remote objects specially[11] Java RMI is a distributed object technology and it has two parts- client and server. However, client and server don’t communicate directly, rather client proxy object communicates with server stub object and emulates the remote method invocation as a local object function call. In this tutorial, we have provided an overview about Java RMI technology and implemented a simple RMI application for mathematical operations. We tried to discover the strengths and weaknesses of RMI and also performed its comparative study against another distributed object technology called CORBA. However, rest of the tutorial is structured as follows. • Section II focuses on the historical perspective of Java RMI technology in brief. • Section III defines few technical terminologies required to understand the architecture or functionalities of our target technology. • Section IV discusses how different components of RMI architecture operate with each other. • Section V demonstrates the implementation and deployment of a simple Java RMI application for mathematical operations. • Section VI highlights some advanced topics related to Java RMI • Section VII illustrates the strength and weakness of the technology • Section VIII provides a comparative study between Java RMI and CORBA technology. • Section IX concludes the tutorial II. H ISTORICAL BACKGROUND [7] Distributed systems require that computations running in different address spaces, potentially on different hosts, be able to communicate. For a basic communication mechanism, the Java programming language supports sockets, which are flexible and sufficient for general communication. However, sockets require the client and server to engage in applicationslevel protocols to encode and decode messages for exchange, and the design of such protocols is cumbersome and can be error-prone. An alternative to sockets is Remote Procedure Call (RPC) developed in late 1970’s, which abstracts the communication interface to the level of a procedure call. Instead of working directly with sockets, the programmer has the illusion of calling a local procedure, when in fact the arguments of the call are packaged up and shipped off to the remote target of the
  2. 2. call. RPC systems encode arguments and return values using an external data representation, such as XDR. RPC, however, does not translate well into distributed object systems, where communication between program-level objects residing in different address spaces is needed. There are three widely available distributed object technologies so far - RMI by Sun Microsystem, CORBA by Object Management Group(OMG) and SOAP by Microsoft. In order to match the semantics of java object invocation, distributed object systems require remote method invocation or RMI. In such systems, a local surrogate (stub) object manages the invocation on a remote object. III. T ERMINOLOGIES In this section, we illustrate some required terminologies . These would help us to comprehend the Java RMI technology more easily. A. RPC[19] Remote Procedure Call (RPC) is an inter-process communication that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction. B. XDR[20] External Data Representation(XDR) is the backbone of the Sun Microsystems Remote Procedure Call package. It is a standard data serialization format, for uses such as computer network protocols. It allows data to be transferred between different kinds of computer systems. Converting from the local representation to XDR is called encoding. Converting from XDR to the local representation is called decoding. XDR is implemented as a software library of functions which is portable between different operating systems and is also independent of the transport layer. C. CORBA[18] The Common Object Request Broker Architecture (CORBA) is a standard defined by the Object Management Group (OMG) that enables software components written in multiple computer languages and running on multiple computers to work together (i.e., it supports multiple platforms). CORBA enables separate pieces of software written in different languages and running on different computers to work with each other like a single application or set of services. More specifically, CORBA is a mechanism in software for normalizing the method-call semantics between application objects residing either in the same address space (application) or remote address space (same host, or remote host on a network). D. IIOP[10] Internet Inter-ORB Protocol (IIOP) is CORBA’s communication protocol. It defines the way bits are sent over a wire between CORBA clients and servers. Interfaces to client and server are described in a platform-neutral interface definition language (IDL). Mappings from IDL to specific programming languages are implemented binding the language to CORBA/IIOP. E. Java IDL[9] Java IDL adds CORBA capability to the Java platform, providing standards-based interoperability and connectivity. Java IDL enables distributed Web-enabled Java applications to transparently invoke operations on remote network services using the industry standard OMG IDL (Object Management Group Interface Definition Language) and IIOP (Internet InterORB Protocol) F. RMI-IIOP[10] Previously, Java programmers had to choose between RMI and CORBA/IIOP (Java IDL) for distributed programming solutions. Now, by adhering to a few restrictions, RMI server objects can use the IIOP protocol, and communicate with CORBA client objects written in any language. This solution is known as RMI-IIOP. RMI-IIOP combines RMI ease of use with CORBA cross-language interoperability. G. SOAP[15] Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. It relies on Extensible Markup Language (XML) for its message format, and usually relies on other Application Layer protocols, most notably Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission IV. S YSTEM A RCHITECTURE RMI applications often comprise two separate programs, a server and a client. A typical server program creates some remote objects, makes references to these objects accessible, and waits for clients to invoke methods on these objects. A typical client program obtains a remote reference to one or more remote objects on a server and then invokes methods on them. RMI provides the mechanism by which the server and the client communicate and pass information back and forth. In this section, we are going to explain the architecture details of RMI technology. A. RMI Layered Structures[2] The RMI system consists of four layers: • Application layer-client and server application • The stub/skeleton layer - client-side stubs (proxies) and server-side skeletons • The remote reference layer - remote reference behavior (i.e., invocation to a single object or to a replicated object) • The transport layer - connection set up and management and remote object tracking The application layer sits on top of the RMI system. The relationship between the layers is shown in the Fig 1. A remote method invocation from a client to a remote server object travels down through the layers of the RMI system
  3. 3. Fig. 1. RMI Layered Architecture[2] Fig. 2. How RMI Works[8] to the client-side transport, then up through the server-side transport to the server. A client invoking a method on a remote server object actually makes use of a stub or proxy for the remote object as a conduit to the remote object. A client-held reference to a remote object is a reference to a local stub. This stub is an implementation of the remote interfaces of the remote object and forwards invocation requests to that server object via the remote reference layer. Stubs are generated using the rmic compiler. The remote reference layer is responsible for carrying out the semantics of the invocation. For example the remote reference layer is responsible for determining whether the server is a single object or is a replicated object requiring communications with multiple locations. Each remote object implementation chooses its own remote reference semanticswhether the server is a single object or is a replicated object requiring communications with its replicas. The remote reference layer abstracts the different ways of referring to objects that are implemented in (a) servers that are always running on some machine, and (b) servers that are run only when some method invocation is made on them (activation). At the layers above the remote reference layer, these differences are not seen. The transport is responsible for connection set-up, connection management, and keeping track of and dispatching to remote objects (the targets of remote calls) residing in the transport’s address space. In order to dispatch to a remote object, the transport forwards the remote call up to the remote reference layer. The remote reference layer handles any server-side behavior that needs to be done before handing off the request to the server-side skeleton. The skeleton for a remote object makes an up-call to the remote object implementation which carries out the actual method call. The return value of a call is sent back through the skeleton, remote reference layer and transport on the server side, and then up through the transport, remote reference layer and stub on the client side. registers itself with remote object registry. Server object may be always running or needs to be activated on method call from client object. Basically server object is associated with a skeleton object called < server class name > skel which is responsible to translate the method invocation from client as local object method invocation. Client object generally resides on a different JVM from the server does. To invoke a method from server object, client object looks up the remote object registry for the required reference to the service. The object registry returns the reference of the < server class name > stub which will communicate with the server object. Client object can invoke the available methods to get the service. Again, the client’s call is abstracted by the stub object so that the socket level details are hidden from the client developer. V. A S IMPLE RMI I MPLEMENTATION [3] In this section, we demonstrated the implementation of a simple RMI application. At first, we performed necessary coding to develop service interface, server class and client class. Then we deployed them in localhost for simplicity. However, we have provided necessary guidelines to deploy the service in another host having JVM installed and running. A. Writing RMI Service To write a RMI service we’ll start off with an example which isn’t too ambitious. We’ll create a service that can calculate factorial or square of a number and can check whether a given number is a prime or not. Our factorial method returns an integer, square method returns a big integer (java.math.BigInteger) and checkPrime method returns a boolean value. 1) Writing an Interface: The first thing we need to do is to agree upon an interface, An interface is a description of the methods we will allow remote clients to invoke. Let’s consider exactly what we’ll need. • A method that accepts as a parameter an integer, finds its factorial, and returns an integer B. Working Principles[16, 8] Fig 2 illustrates how different part of RMI works. Server object implements the publicly available service interface and public long factorial(int number) throws RemoteException;
  4. 4. A method that accepts as a parameter an integer, finds whether it is a prime number or not, and returns a boolean • public boolean checkPrime(int number) throws RemoteException; A method that accepts as a parameter an integer, finds its square, and returns a BigInteger object • public BigInteger square(int number) throws RemoteException; Once we’ve decided on the methods that will compose our service, we have to create a Java interface. An interface is a class which contains abstract methods; these methods must be implemented by another class. Here is our M athService interface in Listing 1 Our implementation of the service also needs to have a main method. The main method will be responsible for creating an instance of our M athServiceP rovider, and registering (or binding) the service with the RMI Registry. Our main method will also assign a security manager to the JVM, to prevent any nasty surprises from remotely loaded classes. In this case, a security manager isn’t really needed, but in more complex systems where untrusted clients will be using the service, it is critical. public static void main(String args[]) { try { // setting RMI security manager if (System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager()); } // creating server instance MathServiceProvider provider = new MathServiceProvider(); // binding the service with the registry LocateRegistry.getRegistry().bind(" MathService", provider); System.out.println("Service is bound to RMI registry"); } catch (Exception exc) { // showing exception System.out.println("Cant bind the service: " + exc.getMessage()); exc.printStackTrace(); //interface between RMI client and server import java.math.BigInteger; import java.rmi.*; public interface MathService extends Remote { // every method associated with RemoteException // calculates factorial of a number public long factorial(int number) throws RemoteException; } // check if a number is prime or not public boolean checkPrime(int number) throws RemoteException; //calculate the square of a number and returns BigInteger public BigInteger square(int number) throws RemoteException; } Listing 3. MathServiceProvider main() method Once the factorial, checkPrime and square methods are added, our server application is complete. Here’s the full source code for the M athServiceP rovider. in Listing 4. B. Writing RMI Client } Listing 1. MathService Interface Our interface extends java.rmi.Remote, which indicates that this is a remote service. We provide method signatures for our three methods (factorial, checkPrime and square), and the interface is complete. The next step is to implement the interface, and provide method definitions for the factorial, checkPrime and square functions. 2) Implementing Interface: To implement M athService interface, we have to declare a default constructor M athServiceP rovider(), even when we don’t have any initialization code for our service. This is because our default constructor can throw a java.rmi.RemoteException, from its parent constructor in U nicastRemoteObject. However, the constructor is quite simple. public MathServiceProvider() throws RemoteException { super(); } Listing 2. MathServiceProvider constructor What good is a service, if you don’t write a client that uses it? Writing clients is the easy part - all a client has to do is call the registry to obtain a reference to the remote object, and call its methods. All the underlying network communication is hidden from view which makes RMI clients simple. Our client must first assign a security manager, and then obtain a reference to the service. Note that the client receives an instance of the interface we defined earlier, and not the actual implementation. Some behind-the-scenes work is going on, but this is completely transparent to the client. // Assign security manager if (System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager()); } // Accessing RMI registry for MathService String hostName = "localhost"; //this can be any host MathService service = (MathService) Naming. lookup("//" + hostName + "/MathService"); Listing 5. MathServiceClient RMIRegistry access
  5. 5. //MathService Server or Provider import import import import import java.awt.font.NumericShaper; java.math.BigInteger; java.rmi.*; java.rmi.registry.LocateRegistry; java.rmi.server.UnicastRemoteObject; public class MathServiceProvider extends UnicastRemoteObject implements MathService { // MathServiceProvider implements all the methods of MathService interface // service constructor public MathServiceProvider() throws RemoteException { super(); } // implementation of factorial public long factorial(int number) { // returning factorial if (number == 1) return 1; return number * factorial(number - 1); } // implementation of checkPrime public boolean checkPrime(int number) { // returning whether prime or not boolean isprime=true; for(int i=2;i*i<number;i++) { if(number%i==0) { isprime=false; break; } } //returning response return isprime; } //implementing of Square public BigInteger square(int number) { //creating BigInteger object BigInteger number1=new BigInteger(String.valueOf(number)); //returning the BigInteger object return number1.multiply(number1); } public static void main(String args[]) { try { // setting RMI security manager if (System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager()); } // creating server instance MathServiceProvider provider = new MathServiceProvider(); // System.setProperty("","file:./server.policy"); // binding the service with the registry LocateRegistry.getRegistry().bind("MathService", provider); // Naming.bind("MathService", provider); System.out.println("Service is bound to RMI registry"); } catch (Exception exc) { // showing exception System.out.println("Cant bind the service: " + exc.getMessage()); exc.printStackTrace(); } } } Listing 4. MathServiceProvider class
  6. 6. To identify a service, we specify an RMI URL. The URL contains the host name on which the service is located, and the logical name of the service. This returns a M athService instance, which can then be used just like a local object reference. We can call the methods just as if we had created an instance of the remote M athServiceP rovider ourselves. // Call to factorial method System.out.println("The factorial of " + number + "=" + service.factorial(number)); set special permission for both server and client class. If one wishes to grant additional permissions, then one can specify them in a policy file and then request them to be loaded using options such as the following: $ java policy=policy-file MyClass // Call to checkPrime method boolean isprime=service.checkPrime(number); Both of the ”-D” options specify system properties. The first system property has the same effect as executing the following statement as the first statement in your program: //Call to square method BigInteger squareObj=service.square(number); System.setSecurityManager (new SecurityManager ()); Listing 6. MathServiceClient accessing remote methods Writing RMI clients is the easiest part of building distributed services. In fact, there’s more code for the user interface menu in the client than there is for the RMI components! To keep things simple, there’s no data validation, so be careful when entering numbers. Here’s the full source code for the RMI client in Listing 7. C. Running the Client and Server Our example was very simple. More complex systems, however, might contain interfaces that change, or whose implementation changes. To run this tutorial example, both the client and server will have a copy of the class files, but more advanced systems might share the code of the server on a webserver, for downloading as required. If your systems do this, don’t forget to set the system property java.rmi.server.codebase to the webserver directory in which your classes are stored. 1) Start the rmiregistry: To start the registry, Windows users should do the following (assuming that your java/ bin directory is in the current path): $ start rmiregistry To start the registry, Unix users should do the following:$ rmiregistry & 2) Compile the sever $ javac MathServiceProvider. java 3) Create the server stub: This step is no longer needed to do manually. From JDK 1.5+, it is automatically done for the developers. The second system property above causes the specified policy-file (which is specified with a URL) to be added to the other policy files when defining the entire security policy. The policytool can be used to construct the policy file, but one can also use any text editor. However, in our case we have created a policy file called no.policy and kept it in the CLASSP AT H. So, the content of no.policy file is as follows. grant { permission; }; In the file, we have actually removed all security restrictions for the server class. However, this can be more restrictive, but we did it here for simplicity. As if this wasn’t already complicated enough, there is yet another way to deal with the problem of downloading Serializable classes. The command-line option $ -Djava.rmi.server.codebase=code-base specifies a location from which Serializable classes may be downloaded. Of course, your security manager must recognize this system property, and not all of them will do so. Furthermore, as mentioned earlier, this is only necessary if you actually need to download Serializable classes. However, we didn’t focus about serializable classes in this tutorial. 5) Start the server: To start the server, we have to specify the policy file we have created for server class. As, our server class sets up a security manager in the source, there is no need set another security manager from command line. $ rmic MathServiceProvider 4) Establishing security policy[14]: One of the most common problems one encounters with RMI is a failure due to security constraints. Note that this section assumes that one is using Java 1.2 or later. The default security manager uses a policy that is defined in a collection of policy files. These files are managed by the policytool program. By default, the security manager (i.e., in JDK 7) does not support RMI method call. So, we need to $ java MathServiceProvider 6) Start the client: The client also needs a policy file like the server. We have used the same no.policy file for the client also. Thus our command to start the client is as follows. $ java MathServiceClient localhost
  7. 7. //MathService Client import import import import java.math.BigInteger; java.rmi.Naming; java.rmi.RMISecurityManager; java.util.Scanner; //This client accesses MathService Remote Object public class MathServiceClient { public static void main(String[] args) { try { // Assign security manager if (System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager()); } // Accessing RMI registry for MathService String hostName = "localhost"; MathService service = (MathService) Naming.lookup("//" + hostName + "/MathService"); // enter your input values Scanner scanner = new Scanner(; System.out.println("Enter your number to get factorial"); // is the input entered? if (scanner.hasNext()) { // reading the number for factorial from keyboard int number = scanner.nextInt(); System.out.println("The factorial of " + number + "=" + service.factorial(number)); } System.out.println("Enter your number to check prime"); if (scanner.hasNext()) { // reading the number for checkPrime int number = scanner.nextInt(); boolean isprime=service.checkPrime(number); if(isprime)System.out.println(number+" is a prime number"); else System.out.println(number+" is not a prime number"); } System.out.println("Enter your number to get square"); if (scanner.hasNext()) { // reading the number for square int number = scanner.nextInt(); BigInteger squareObj=service.square(number); System.out.println("The square of "+number+" is ="+squareObj.intValue()); } } catch (Exception exc) { // showing exceptions System.err.println(exc.getMessage()); exc.printStackTrace(); } } } Listing 7. MathService Client
  8. 8. Here, the first part of the command specifies the policy file, second part is the client class itself and the last part refers to the host it is trying to connect. VI. A DVANCED T OPICS ON RMI Here, we discuss few advanced topics related to RMI briefly as the detailed discussion is beyond the scope of this tutorial. A. Java Object Serialization When client and server application try to communicate using serializable user-defined objects during RMI, they need to exchange those objects over the network. Java serialization is a technique to convert those object definitions into sequence of bytes which are suitable for network transmission. Generally, stub and skeleton are responsible for Java object serialization during RMI. B. Parameter Marshalling and Demarshalling It is a special kind of Java Object serialization technique for method parameters. Any object of type remote or serializable can be marshalled. It is almost like serialization, but additionally, it records the code base of the definition so that the original object can be obtained after demarshalling. C. Object Activation Java RMI facilitates remote object access on demand; that means, the remote reference layer activates the remote object only when the client requests for the service. This feature can be implemented using Activable remote object and this is reasonable solution to resource optimization. Generally, each RMI call creates a client-server communication line and there is no need to keep all connections alive if the clients are not using it. So, client can store a persistence reference of the remote object and can make a connection when required. VII. S TRENGTH & W EAKNESS OF JAVA RMI In this section, we discuss about the strengths and weaknesses of Java RMI as a distributed object technology. A. Strength of Java RMI[1] At the most basic level, RMI is Java’s remote procedure call (RPC) mechanism. RMI has several advantages over traditional RPC systems because it is part of Java’s object oriented approach. Traditional RPC systems are language-neutral, and therefore are essentially least-common-denominator systemsthey cannot provide functionality that is not available on all possible target platforms. RMI is focused on Java, with connectivity to existing systems using native methods. This means RMI can take a natural, direct, and fully-powered approach to provide you with a distributed computing technology that lets you add Java functionality throughout your system in an incremental, yet seamless way. 1) Object Oriented: RMI can pass full objects as arguments and return values, not just predefined data types. This means that you can pass complex types, such as a standard Java hashtable object, as a single argument. In existing RPC systems you would have to have the client decompose such an object into primitive data types, ship those data types, and then recreate a hashtable on the server. RMI lets you ship objects directly across the wire with no extra client code. 2) Mobile Behavior: RMI can move behavior (class implementations) from client to server and server to client. For example, you can define an interface for examining employee expense reports to see whether they conform to current company policy. When an expense report is created, an object that implements that interface can be fetched by the client from the server. When the policies change, the server will start returning a different implementation of that interface that uses the new policies. The constraints will therefore be checked on the client side-providing faster feedback to the user and less load on the server-without installing any new software on user’s system. This gives you maximal flexibility, since changing policies requires you to write only one new Java class and install it once on the server host. 3) Design Patterns: Passing objects lets you use the full power of object oriented technology in distributed computing, such as two- and three-tier systems. When you can pass behavior, you can use object oriented design patterns in your solutions. All object oriented design patterns rely upon different behaviors for their power; without passing complete objects-both implementations and type-the benefits provided by the design patterns movement are lost. 4) Safe and Secure:: RMI uses built-in Java security mechanisms that allow your system to be safe when users downloading implementations. RMI uses the security manager defined to protect systems from hostile applets to protect your systems and network from potentially hostile downloaded code. In severe cases, a server can refuse to download any implementations at all. 5) Easy to Write/Easy to Use: RMI makes it simple to write remote Java servers and Java clients that access those servers. A remote interface is an actual Java interface. A server has roughly three lines of code to declare itself a server, and otherwise is like any other Java object. This simplicity makes it easy to write servers for full-scale distributed object systems quickly, and to rapidly bring up prototypes and early versions of software for testing and evaluation. And because RMI programs are easy to write they are also easy to maintain. 6) Connects to Existing/Legacy Systems: RMI interacts with existing systems through Java’s native method interface JNI. Using RMI and JNI you can write your client in Java and use your existing server implementation. When you use RMI/JNI to connect to existing servers you can rewrite any parts of you server in Java when you choose to, and get the full benefits of Java in the new code. Similarly, RMI interacts with existing relational databases using JDBC without modifying existing non-Java source that uses the databases.
  9. 9. 7) Write Once, Run Anywhere: RMI is part of Java’s ”Write Once, Run Anywhere” approach. Any RMI based system is 100% portable to any Java Virtual Machine, as is an RMI/JDBC system. If you use RMI/JNI to interact with an existing system, the code written using JNI will compile and run with any Java virtual machine. 8) Distributed Garbage Collection: RMI uses its distributed garbage collection feature to collect remote server objects that are no longer referenced by any clients in the network. Analogous to garbage collection inside a Java Virtual Machine, distributed garbage collection lets you define server objects as needed, knowing that they will be removed when they no longer need to be accessible by clients. 9) Parallel Computing: RMI is multi-threaded, allowing your servers to exploit Java threads for better concurrent processing of client requests. 10) The Java Distributed Computing Solution: RMI is part of the core Java platform starting with JDK 1.1, so it exists on every 1.1+ Java Virtual Machine. All RMI systems talk the same public protocol, so all Java systems can talk to each other directly, without any protocol translation overhead. B. Weakness of Java RMI[4, 6] Despite of so many advantages, Java RMI suffers from some problems. In this section, we have discussed the shortcomings of Java RMI technology. 1) Tied to Java system: It is strongly tied to Java platform and has no support for legacy systems written in C++, Ada, Fortran, Cobol, and others (including future languages). 2) Performance issues: RMI calls should be used for only large-grain computation. Because, every remote invocation from the client results into a new thread and a new TCP connection. 3) Added Security restrictions & complexity: It has security threats when downloading the remote objects for execution which is controlled by security manager and security policy file. However, due to added security concern, using RMI is complex and less flexible. It also requires additional compilation with rmic for creating stub classes which might be an overhead to the performance. VIII. A C ASE S TUDY: RMI VS CORBA In this section, we provide a comparative study between RMI and CORBA as distributed object technologies. Please visit [13] for details. A. Language Dependence As we mentioned before, RMI is a Java-centric distributed object system. The only way currently to integrate code written in other languages into a RMI system is to use the Java nativecode interface to link a remote object implementation in Java to C or C++ code. But, the native-code interface in Java is complicated, and can quickly lead to fragile or difficult-tomaintain code. CORBA, on the other hand, is designed to be language-independent. Object interfaces are specified in a language that is independent of the actual implementation language. This interface description can then be compiled into whatever implementation language suits the job and the environment. B. Mobile Behavior An RMI system is immediately cross-platform; any subsystem of the distributed system can be relocated to any host that has a Java virtual machine handy. In CORBA, objects can never really leave their implementation hosts; they can only roam the network in the virtual sense, sending stub references to themselves and to clients. C. Performance Issue Performance may be an issue in case of RMI for heavy computation. Heavy computational tasks like computational fluid dynamics and finite-element modeling are best written in languages that can be compiled down to native hardware instructions, like C and C++. The Java virtual machine architecture is a disadvantage here, since an additional interpretation layer is added to the processing of instructions. The Java just-in-time compilers (JIT) are capable of generating native instructions from Java bytecodes, but there is still an additional piece of overhead in running each piece of Java code. D. Ease of Use RMI can be easier to master, especially for experienced Java programmers, than CORBA. CORBA is a rich, extensive family of standards and interfaces, and delving into the details of these interfaces is sometimes overkill for the task at hand. E. Maturity of Technology CORBA is a more mature standard than RMI, and has had time to gain richer implementations. The CORBA standard is a fairly comprehensive one in terms of distributed objects, and there are CORBA implementations out there that provide many more services and distribution options than RMI or Java. The CORBA Services specifications, for example, include comprehensive high-level interfaces for naming, security, and transaction services. F. Renowned Customers Java RMI technology is widely used by IBM, Swiss Federal Supreme Court, CEAS Consulting and most importantly different chat service companies [12]. On the other hand, CORBA is an old and established technology and it has customers like USA AG, Cisco Systems, American Airlines, BHP Information Technology and others [5]. To summarize, comparing RMI and CORBA doesn’t reveal an optimum solution - one is not ”better” than the other. The properties of these two technologies lend themselves to different situations. A comparison of RMI and CORBA helps to highlight individual strengths and weaknesses, but the applicability of one technology over the other depends largely on the purposes for which it is to be used, the experience of the developers who will design, implement and maintain the distributed system, and whether non-Java systems are intended to access the system now or in the future.
  10. 10. IX. C ONCLUSION In this tutorial, we provided a simple overview about Java RMI technology including a simple application demonstration and a case study between RMI and CORBA. We also discovered its strengths and weaknesses of RMI. However, the choice of RMI depends on the purpose, scope and nature of the application we are going to develop. R EFERENCES [1] Advantages of java rmi. URL technetwork/java/javase/tech/index-jsp-138781.html. [2] Java rmi architecture. URL ∼michael/java/jdk1.1-beta2-docs/guide/rmi/rmi-arch. doc.html. [3] Introduction to java rmi. URL http://www. [4] Java rmi: Remote method invocation. URL java-rmi/java-rmi-handouts.pdf. [5] Corba success stories. URL [6] Disadvantages of rmi. URL http://www.coderanch. com/t/180297/java-developer-SCJD/certification/ RMI-Advantages-Disadvantages. [7] Background of java rmi. URL javase/1.5.0/docs/guide/rmi/spec/rmi-intro2.html. [8] How rmi works. URL netmanage/simulator/rmi/RMIExplanation.htm. [9] Java idl. URL Java IDL.html. [10] Rmi iiop. URL [11] Marshalling object. URL Marshalling %28computer science%29. [12] Real world applications using java rmi, . URL∼paul8/jdk1.2beta3/docs/guide/ rmi/examples.html. [13] Rmi vs corba, . URL∼on/O/ oreilly/java-ent/dist/ch03 07.htm. [14] Security issues of java rmi. URL ∼cs379/DistributedSystems/rmi tut.html. [15] Simple object access protocol. URL http://en.wikipedia. org/wiki/SOAP. [16] Java remote method invocation. URL http://userpages.∼tarr/dp/lectures/RMI.pdf. [17] Java remote method invocation, . URL http://en. remote method invocation. [18] Common object request broker architecture, . URL http: // [19] Remote procedure call, . URL wiki/Remote procedure call. [20] External data representation. URL com/cd/E19963-01/html/821-1671/xdrnts-1.html.