JAVA RMI Technology
Thread Rating:
  • 2 Vote(s) - 4 Average
  • 1
  • 2
  • 3
  • 4
  • 5
seminar surveyer
Active In SP
**

Posts: 3,541
Joined: Sep 2010
#1
03-01-2011, 02:26 PM




Purav Patel


.pdf   JAVA RMI Technology.pdf (Size: 124.67 KB / Downloads: 244)

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




Reply
seminar class
Active In SP
**

Posts: 5,361
Joined: Feb 2011
#2
24-03-2011, 11:15 AM


.doc   Unit-II.doc (Size: 331 KB / Downloads: 91)
Introduction to Java RMI
Remote method invocation allows applications to call object methods located remotely, sharing resources and processing load across systems. 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. RMI allows both client and server to dynamically load new object types as required. In this unit, you'll learn more about RMI.
Overview
Remote Method Invocation (RMI) facilitates object function calls between Java Virtual Machines (JVMs). JVMs can be located on separate computers - yet one JVM can invoke methods belonging to an object stored in another JVM. Methods can even pass objects that a foreign virtual machine has never encountered before, allowing dynamic loading of new classes as required. This is a powerful feature!
Consider the follow scenario:
• Developer A writes a service that performs some useful function. He regularly updates this service, adding new features and improving existing ones.
• Developer B wishes to use the service provided by Developer A. However, it's inconvenient for A to supply B with an update every time.
Java RMI provides a very easy solution! Since RMI can dynamically load new classes, Developer B can let RMI handle updates automatically for him. Developer A places the new classes in a web directory, where RMI can fetch the new updates as they are required.
Figure 1 shows the connections made by the client when using RMI. Firstly, the client must contact an RMI registry, and request the name of the service. Developer B won't know the exact location of the RMI service, but he knows enough to contact Developer A's registry. This will point him in the direction of the service he wants to call..
Developer A's service changes regularly, so Developer B doesn't have a copy of the class. Not to worry, because the client automatically fetches the new subclass from a webserver where the two developers share classes. The new class is loaded into memory, and the client is ready to use the new class. This happens transparently for Developer B - no extra code need to be written to fetch the class.
Writing RMI services
Writing your own RMI services can be a little difficult at first, so we'll start off with an example which isn't too ambitious. We'll create a service that can calculate the square of a number, and the power of two numbers (238 for example). Due to the large size of the numbers, we'll use the java.math.BigInteger class for returning values rather than an integer or a long.
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.
1. A method that accepts as a parameter an integer, squares it, and returns a BigInteger
public BigInteger square ( int number_to_square );
2. A method that accepts as a parameter two integers, calculates their power, and returns a BigInteger
public Big Integer power ( int num1, int num2 );
Once we've decided on the methods that will compose our service, we have to create a Java interface. An interface is a method which contains abstract methods; these methods must be implemented by another class. Here's the source code for our service that calculates powers.
import java.math.BigInteger;
import java.rmi.*;
//
// PowerService Interface
//
// Interface for a RMI service that calculates powers
//
public interface PowerService extends java.rmi.Remote
{
// Calculate the square of a number
public BigInteger square ( int number )
throws RemoteException;

// Calculate the power of a number
public BigInteger power ( int num1, int num2)
throws RemoteException;
}
Our interface extends java.rmi.Remote, which indicates that this is a remote service. We provide method definitions for our two methods (square and power), and the interface is complete. The next step is to implement the interface, and provide methods for the square and power functions.
Implementing the interface
Implementing the interface is a little more tricky - we actually have to write the square and power methods! Don't worry if you're not sure how to calculate squares and powers, this isn't a math lesson. The real code we need to be concerned about is the constructor and main method.
We have to declare a default constructor, 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 UnicastRemoteObject. Sound confusing? Don't worry, because our constructor is extremely simple.
public PowerServiceServer () throws RemoteException
{
super();
}
Our implementation of the service also needs to have a main method. The main method will be responsible for creating an instance of our PowerServiceServer, 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[] ) throws Exception
{
// Assign a security manager, in the event that dynamic
// classes are loaded
if (System.getSecurityManager() == null)
System.setSecurityManager ( new RMISecurityManager() );

// Create an instance of our power service server ...
PowerServiceServer svr = new PowerServiceServer();

// ... and bind it with the RMI Registry
Naming.bind ("PowerService", svr);

System.out.println ("Service bound....");
}
Once the square and power methods are added, our server is complete. Here's the full source code for the PowerServiceServer.
import java.math.*;
import java.rmi.*;
import java.rmi.server.*;

//
// PowerServiceServer
//
// Server for a RMI service that calculates powers
//
public class PowerServiceServer extends UnicastRemoteObject
implements PowerService
{
public PowerServiceServer () throws RemoteException
{
super();
}

// Calculate the square of a number
public BigInteger square ( int number )
throws RemoteException
{
String numrep = String.valueOf(number);
BigInteger bi = new BigInteger (numrep);

// Square the number
bi.multiply(bi);

return (bi);
}

// Calculate the power of a number
public BigInteger power ( int num1, int num2)
throws RemoteException
{
String numrep = String.valueOf(num1);
BigInteger bi = new BigInteger (numrep);

bi = bi.pow(num2);
return bi;
}

public static void main ( String args[] ) throws Exception
{
// Assign a security manager, in the event that dynamic
// classes are loaded
if (System.getSecurityManager() == null)
System.setSecurityManager ( new RMISecurityManager() );

// Create an instance of our power service server ...
PowerServiceServer svr = new PowerServiceServer();

// ... and bind it with the RMI Registry
Naming.bind ("PowerService", svr);

System.out.println ("Service bound....");
}
}
Writing a RMI client
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());
}

// Call registry for PowerService
PowerService service = (PowerService) Naming.lookup
("rmi://" + args[0] + "/PowerService");
To identify a service, we specify an RMI URL. The URL contains the hostname on which the service is located, and the logical name of the service. This returns a PowerService instance, which can then be used just like a local object reference. We can call the methods just as if we'd created an instance of the remote PowerServiceServer ourselves.
// Call remote method
System.out.println ("Answer : " + service.square(value));
// Call remote method
System.out.println ("Answer : " + service.power(value,power));
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.
import java.rmi.*;
import java.rmi.Naming;
import java.io.*;

//
//
// PowerServiceClient
//
//
public class PowerServiceClient
{
public static void main(String args[]) throws Exception
{
// Check for hostname argument
if (args.length != 1)
{
System.out.println
("Syntax - PowerServiceClient host");
System.exit(1);
}

// Assign security manager
if (System.getSecurityManager() == null)
{
System.setSecurityManager
(new RMISecurityManager());
}

// Call registry for PowerService
PowerService service = (PowerService) Naming.lookup
("rmi://" + args[0] + "/PowerService");

DataInputStream din = new
DataInputStream (System.in);

for (;Wink
{
System.out.println("1 - Calculate square");
System.out.println("2 - Calculate power");
System.out.println("3 - Exit"); System.out.println();
System.out.print ("Choice : ");

String line = din.readLine();
Integer choice = new Integer(line);

int value = choice.intValue();

switch (value)
{
case 1:
System.out.print ("Number : ");
line = din.readLine();System.out.println();
choice = new Integer (line);
value = choice.intValue();

// Call remote method
System.out.println ("Answer : " + service.square(value));

break;
case 2:
System.out.print ("Number : ");
line = din.readLine();
choice = new Integer (line);
value = choice.intValue();

System.out.print ("Power : ");
line = din.readLine();
choice = new Integer (line);
int power = choice.intValue();

// Call remote method
System.out.println("Answer : " + service.power(value, power));

break;
case 3:
System.exit(0);
default :
System.out.println ("Invalid option");
break;
}
}
}

}
Running the client and server
Our example was extremely simple. More complex systems, however, might contain interfaces that change, or whose implementation changes. To run this article's examples, both the client and server will have a copy of the classfiles, 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!
You can download all the source and class files together as a single ZIP file. Unpack the files into a directory, and then perform the following steps.
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 server
Compile the server, and use the rmic tool to create stub files.
3. Start the server
From the directory in which the classes are located, type the following:-
java PowerServiceServer
4. Start the client
You can run the client locally, or from a different machine. In either case, you'll need to specify the hostname of the machine where you are running the server. If you're running it locally, use localhost as the hostname.
java PowerServiceClient localhost
Reply
Nish89
Active In SP
**

Posts: 2
Joined: Aug 2011
#3
25-01-2012, 09:09 PM

hi could u pls send me the ppt for this topic...
In anticipation..


milan
Reply
seminar addict
Super Moderator
******

Posts: 6,592
Joined: Jul 2011
#4
26-01-2012, 10:31 AM


to get information about the topic JAVA RMI Technology full report,ppt and related topic refer the link bellow

topicideashow-to-java-rmi-technology
Reply
seminar flower
Super Moderator
******

Posts: 10,120
Joined: Apr 2012
#5
20-09-2012, 11:07 AM

Java RMI


.doc   Java_RMI_Notes.doc (Size: 63 KB / Downloads: 13)

Introduction

This is a brief introduction to Java Remote Method Invocation (RMI). Java RMI is a mechanism that allows one to invoke a method on an object that exists in another address space. The other address space could be on the same machine or a different one. The RMI mechanism is basically an object-oriented RPC mechanism. CORBA is another object-oriented RPC mechanism. CORBA differs from Java RMI in a number of ways:
1. CORBA is a language-independent standard.
2. CORBA includes many other mechanisms in its standard (such as a standard for TP monitors) none of which are part of Java RMI.
3. There is also no notion of an "object request broker" in Java RMI.
Java RMI has recently been evolving toward becoming more compatible with CORBA. In particular, there is now a form of RMI called RMI/IIOP ("RMI over IIOP") that uses the Internet Inter-ORB Protocol (IIOP) of CORBA as the underlying protocol for RMI communication.
This tutorial attempts to show the essence of RMI, without discussing any extraneous features. Sun has provided a Guide to RMI, but it includes a lot of material that is not relevant to RMI itself. For example, it discusses how to incorporate RMI into an Applet, how to use packages and how to place compiled classes in a different directory than the source code. All of these are interesting in themselves, but they have nothing at all to do with RMI. As a result, Sun's guide is unnecessarily confusing. Moreover, Sun's guide and examples omit a number of details that are important for RMI.

Serializable Classes

We now consider how to design Remote and Serializable classes. The easier of the two is a Serializable class. A class is Serializable if it implements the java.io.Serializable interface. Subclasses of a Serializable class are also Serializable. Many of the standard classes are Serializable, so a subclass of one of these is automatically also Serializable. Normally, any data within a Serializable class should also be Serializable. Although there are ways to include non-serializable objects within a serializable objects, it is awkward to do so. See the documentation of java.io.Serializable for more information about this.
Using a serializable object in a remote method invocation is straightforward. One simply passes the object using a parameter or as the return value. The type of the parameter or return value is the Serializable class. Note that both the Client and Server programs must have access to the definition of any Serializable class that is being used. If the Client and Server programs are on different machines, then class definitions of Serializable classes may have to be downloaded from one machine to the other. Such a download could violate system security. This problem is discussed in the Security section.

Programming a Client

Having described how to define Remote and Serializable classes, we now discuss how to program the Client and Server. The Client itself is just a Java program. It need not be part of a Remote or Serializable class, although it will use Remote and Serializable classes.
A remote method invocation can return a remote object as its return value, but one must have a remote object in order to perform a remote method invocation. So to obtain a remote object one must already have one. Accordingly, there must be a separate mechanism for obtaining the first remote object. The Object Registry fulfills this requirement. It allows one to obtain a remote object using only the name of the remote object.
The name of a remote object includes the following information:
1. The Internet name (or address) of the machine that is running the Object Registry with which the remote object is being registered. If the Object Registry is running on the same machine as the one that is making the request, then the name of the machine can be omitted.
2. The port to which the Object Registry is listening. If the Object Registry is listening to the default port, 1099, then this does not have to be included in the name.
3. The local name of the remote object within the Object Registry.
Reply

Important Note..!

If you are not satisfied with above reply ,..Please

ASK HERE

So that we will collect data for you and will made reply to the request....OR try below "QUICK REPLY" box to add a reply to this page

Quick Reply
Message
Type your reply to this message here.


Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Possibly Related Threads...
Thread Author Replies Views Last Post
  BRAIN GATE TECHNOLOGY ABSTRACT project girl 1 490 01-04-2016, 11:20 AM
Last Post: mkaasees
  latest seminar topics for information technology jaseelati 0 359 23-02-2015, 03:17 PM
Last Post: jaseelati
  seminar topics for information technology with ppt jaseelati 0 316 21-02-2015, 04:16 PM
Last Post: jaseelati
  information technology seminar topics jaseelati 0 316 07-02-2015, 12:58 PM
Last Post: jaseelati
  bicmos technology seminar report jaseelati 0 321 09-01-2015, 02:58 PM
Last Post: jaseelati
  3d optical data storage technology seminar report jaseelati 0 403 06-01-2015, 04:47 PM
Last Post: jaseelati
  3d optical data storage technology seminar report jaseelati 0 322 30-12-2014, 03:23 PM
Last Post: jaseelati
  embedded web technology ppt jaseelati 0 497 16-12-2014, 04:34 PM
Last Post: jaseelati
  6g technology ppt jaseelati 0 303 16-12-2014, 02:17 PM
Last Post: jaseelati
  Java EE seminar ideas 6 4,166 14-11-2014, 06:59 PM
Last Post: alokigorRob