03-01-2011, 02:26 PM
Purav Patel
[attachment=7908]
Abstract
We present an automated run-time optimisation framework that can improve the performance of distributed applications written using Java RMI whilst preserving its semantics. Java classes are modified at load-time in order to intercept RMI calls as they occur. RMI calls are not executed immediately, but are delayed for as long as possible. When a dependence forces execution of the delayed calls, the aggregated calls are sent over to the remote server to be executed in one step. This reduces network overhead and the quantity of data sent, since data can be shared between calls. The sequence of calls may be cached on the server side along with any known constants in order to speed up future calls. A remote server may also make RMI calls to another remote server on behalf of the client if necessary. Our results show that the techniques can speed up distributed programs significantly, especially when operating across slower networks. We also discuss some of the challenges involved in maintaining program semantics, and show how the approach can be used for more ambitious optimisations in the future.
Introduction
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 applications-level protocols to encode and decode messages for exchange, and the design of such protocols is cumbersome and can be errorprone. An alternative to sockets is Remote Procedure Call (RPC), 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 localprocedure, when in fact the arguments of the call are packaged up and shipped off to the remote target of the call. RPC, however, does not translate well into distributed object systems, where communication between program-level objects residing in different address spaces is needed. distributed object systems require remote method invocation or RMI. In such systems, a local surrogate (stub) object manages the invocation on a remote object. The Java platform’s remote method invocation system described in this specification has been specifically designed to operate in the Java application environment. The Java programming language’s RMI system assumes the homogeneous environment of the Java virtual machine (JVM), and the system can therefore take advantage of the Java platform’s object model whenever possible.
System Goals
The goals for supporting distributed objects in the Java programming language are:
• Support seamless remote invocation on objects in different virtual machines
• Support callbacks from servers to applets
• Integrate the distributed object model into the Java programming language
• Make differences between the distributed object model and local Java platform’s object model apparent • Make writing reliable distributed applications as simple as possible
• Preserve the type-safety provided by the Java platform’s runtime environment
• Support various reference semantics for remote objects; for example live (nonpersistent) references, persistent references, and lazy activation
• Maintain the safe environment of the Java platform provided by security managers and class loaders Underlying all these goals is a general requirement that the RMI model be both simple (easy to use) and natural (fits well in the language).
How Java RMI system Overview How it is worked?
The basic structure of an RMI-based method call involves a client, a server and a registry. To make a call to a remote object, the client first looks up the object it wishes to invoke a method on in the registry. The registry returns a reference to the object (assuming it exists) on the server, which the client can use to invoke any methods that the remote object implements. The client communicates with the remote object via a User-defined interface that is actually implemented by the remote object. The client actually does not deal directly with the remote object at all, but with a code stub that deals with the process of communication between client and server (using, in the default case, sockets). At the server end, in pre-Java 2 JDKs (before JDK 1.2), a code skeleton dealt with client communication. In Java 2, the skeleton is no longer needed. Fortunately, the code stub (and skeleton if necessary) are generated automatically by the RMI Compiler rmic. Remote objects can be invoked with parameters, naturally – these parameters can be entire objects, complete with methods that are passed using serialization.
The Basic Architecture of RMI
The RMI server must implement the remote object's interface, and hence it must implement the methods in that interface. (It can in fact implement other methods as well, but such additional methods will only be available to other objects on the server to call - only those methods declared in the interface will be accessible remotely.) In addition, it is commonly the case that remote objects extend the class java.rmi.server.UnicastRemoteObject, which provides the default behaviour required for RMIbased communication in `typical' cases. It is also possible for you to define your own such behaviour, but that is beyond the scope of this module. In addition to the methods of the interface, the server must also undertake a certain amount of initialisation - make the remote object(s) available by binding them into the registry. The JAVA RMI Technology PURAV
