0% found this document useful (0 votes)
38 views32 pages

Client/Server Technologies RPC and Java RMI: Lecture#5

Remote Procedure Call (RPC) allows a program to call a subroutine in another address space as if it were a local routine. RPC uses client-side and server-side stubs that marshal and unmarshal arguments to handle the details of communication. Java RMI is a form of RPC that allows Java objects to communicate remotely by making method calls appear as local calls. It requires interfaces, remote classes that implement interfaces, and registration of remote objects in an RMI registry so clients can lookup and invoke methods on remote objects.

Uploaded by

Iqra Khan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
38 views32 pages

Client/Server Technologies RPC and Java RMI: Lecture#5

Remote Procedure Call (RPC) allows a program to call a subroutine in another address space as if it were a local routine. RPC uses client-side and server-side stubs that marshal and unmarshal arguments to handle the details of communication. Java RMI is a form of RPC that allows Java objects to communicate remotely by making method calls appear as local calls. It requires interfaces, remote classes that implement interfaces, and registration of remote objects in an RMI registry so clients can lookup and invoke methods on remote objects.

Uploaded by

Iqra Khan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 32

Client/Server Technologies

Lecture#5

RPC and Java RMI


Remote Procedure Call (RPC)

• The most common framework for newer protocols and for middleware
• Used both by operating systems and by applications
• DCOM, CORBA, Java RMI, etc., are just RPC systems
Remote Procedure Call (RPC)

• Fundamental idea: –
• Server process exports an interface of procedures or functions that can be
called by client programs
• similar to library API, class definitions, etc.
• Clients make local procedure/function calls
• As if directly linked with the server process
• Under the covers, procedure/function call is converted into a message
exchange with remote server process
Remote Procedure Call
RPC: A pair of Stubs

Client-side stub Server-side stub


 Looks like local server function  Looks like local client function to
 Same interface as local function server
 Bundles arguments into message,  Listens on a socket for message
sends to server-side stub from client stub
 Waits for reply, un-bundles results  Un-bundles arguments to local
 returns variables
 Makes a local function call to
server
 Bundles result into reply message
to client stub

The hard work of building messages, formatting, uniform representation, etc., is


buried in the stubs
RPC – Issues

• How to make the “remote” part of RPC invisible to the programmer?


• What are semantics of parameter passing?
• E.g., pass by reference?
• How to bind (locate & connect) to servers?
• How to handle heterogeneity?
• OS, language, architecture, …
• How to make it go fast?
RPC Model

• A server defines the service interface using an interface definition


language (IDL)
• the IDL specifies the names, parameters, and types for all client-callable
server procedures

• A stub compiler reads the IDL declarations and produces two stub
functions for each server function
• Server-side and client-side
RPC Model (continued)

• Linking:–
• Server programmer implements the service’s functions and links with the
server-side stubs
• Client programmer implements the client program and links it with client-
side stubs
• Operation:–
• Stubs manage all of the details of remote communication between client and
server
RPC Stubs

• A client-side stub is a function that looks to the client as if it


were a callable server function
• i.e., same API as the server’s implementation of the function
• A server-side stub looks like a caller to the server
• The client program thinks it’s invoking the server
• but it’s calling into the client-side stub
• The server program thinks it’s called by the client
• but it’s really called by the server-side stub
• The stubs send messages to each other to make the RPC
happen transparently (almost!)
Marshalling Arguments

• Marshalling is the packing of function parameters


into a message packet
• the RPC stubs call type-specific functions to marshal or unmarshal the
parameters of an RPC
• Client stub marshals the arguments into a message
• Server stub unmarshals the arguments and uses them to invoke
the service function
• on return:
• the server stub marshals return values
• the client stub unmarshals return values, and returns to the client
program
Transport of Remote Procedure
Call
• Option — TCP
• Connection-based, reliable transmission
• Useful but heavyweight, less efficient
• Necessary if repeating a call produces different result
• Alternative — UDP
• If message fails to arrive within a reasonable time, caller’s stub simply sends it again
• Okay if repeating a call produces same result
Asynchronous RPC
Asynchronous RPC (continued)
Uses of RPC

• Remote Procedure Call is used:


• Between processes on different machines
• e.g., client-server model

• Between processes on the same machine


• More structured than simple message passing

• Between subsystems of an operating system


• Windows XP (called Local Procedure Call)
RMI
Remote Method Invocation
Introduction to RMI

• RMI is the JAVA implementation of RPC

• RMI is purely Java-specific


• Java to Java communications only
• As a result, RMI is much simpler than other technologies providing RPC
implementation, such as CORBA
What is needed for RMI

• Java makes RMI (Remote Method Invocation) fairly easy, but there
are some extra steps
• To send a message to a remote “server object,”
• The “client object” has to find the object
• Do this by looking it up in a registry
• The client object then has to marshal the parameters (prepare them for
transmission)
• Java requires Serializable parameters
• The server object has to unmarshal its parameters, do its computation, and marshal its
response
• The client object has to unmarshal the response
Terminology

A remote object is an object on another computer


The client object is the object making the request (sending
a message to the other object)
The server object is the object receiving the request
As usual, “client” and “server” can easily trade roles (each
can make requests of the other)
The rmiregistry is a special server that looks up objects by
name
Hopefully, the name is unique!
rmic is a special compiler for creating stub (client) and
skeleton (server) classes
Processes

• For RMI, you need to be running three processes


• The Client
• The Server
• The Object Registry, rmiregistry, which is like a DNS service for objects
• You also need TCP/IP active
Interfaces

Interfaces define behavior


Classes define implementation

Therefore,
In order to use a remote object, the client must know its behavior
(interface), but does not need to know its implementation (class)
In order to provide an object, the server must know both its
interface (behavior) and its class (implementation)
In short,
The interface must be available to both client and server
The class of any transmitted object must be on both client and
server
The class whose method is being used should only be on the server
Classes

• A Remote class is one whose instances can be accessed remotely


• On the computer where it is defined, instances of this class can be accessed
just like any other object
• On other computers, the remote object can be accessed via object handles
• A Serializable class is one whose instances can be marshaled
(turned into a linear sequence of bits)
• Serializable objects can be transmitted from one computer to another
Conditions for serializability

If an object is to be serialized:


The class must be declared as public
The class must implement Serializable interface
However, Serializable does not declare any methods
The class must have a no-argument constructor
All fields of the class must be serializable: either
primitive types or Serializable objects
Exception: Fields marked transient will be ignored during
serialization
Remote Class:
Interface and the Class Itself
A Remote class has two parts:
 The interface (used by both client and server):
 Must be public
 Must extend the interface java.rmi.Remote
 Every method in the interface must declare that it throws java.rmi.RemoteException
(other exceptions may also be thrown)
 The class itself (used only by the server):
 Must implement the Remote interface
 Should extend java.rmi.server.UnicastRemoteObject
 May have locally accessible methods that are not in its Remote interface
The Server Class to Register Remote
Class in RMIRegistry
The class that defines the server object should extend
UnicastRemoteObject
This makes a connection with exactly one other computer
Sun does not provide a MulticastRemoteObject class
The server class needs to register its server object:
String url = "rmi://" + host + ":" + port + "/" + objectName;
 The default port is 1099
Naming.rebind(url, object);
Every remotely available method must throw a RemoteException
(because connections can fail)
Every remotely available method should be synchronized
Hello World Server:
Remote Interface
• import java.rmi.*;

public interface HelloInterface extends Remote {


public String say() throws RemoteException;
}
Hello World Server:
Remote Class implementing the Interface
import java.rmi.*;
import java.rmi.server.*;

public class Hello extends UnicastRemoteObject implements HelloInterface


{
private String message; // Strings are serializable

public Hello (String msg) throws RemoteException {


message = msg;
}

public String say() throws RemoteException {


return message;
}
}
Hello World Server:
Registering the Hello World Server into the RMI Registry

class HelloServer {

public static void main (String[] argv) {

try {

Naming.rebind("rmi://localhost/HelloServer",new Hello("Hello, world!"));

System.out.println("Hello Server is ready.");

}
catch (Exception e) {

System.out.println("Hello Server failed: " + e);

}
}
}
The Hello World Client Program

class HelloClient {

public static void main (String[] args) {

HelloInterface hello;
String name = "rmi://localhost/HelloServer";

try {

hello = (HelloInterface)Naming.lookup(name);
System.out.println(hello.say());

}
catch (Exception e) {
System.out.println("HelloClient exception: " + e);
}
}
}
rmic

• The class that implements the remote object should be compiled as


usual (i.e. Hello class)
• Then, it should be compiled with rmic:
• rmic Hello
• This will generate files Hello_Stub.class and Hello_Skel.class
• These classes do the actual communication
• The “Stub” class must be copied to the client area
• The “Skel” was needed in SDK 1.1 but is no longer necessary
Trying RMI

• In three different terminal windows:


1. Run the registry program:
• rmiregistry
2. Run the server program:
• java HelloServer
3. Run the client program:
• java HelloClient

 If all goes well, you should get the “Hello, World!” message
Summary

1. Start the registry server, rmiregistry


2. Start the object server
1. The object server registers an object, with a name, with the registry
server
3. Start the client
1. The client looks up the object in the registry server
4. The client makes a request
1. The request actually goes to the Stub class
2. The Stub classes on client and server talk to each other
3. The client’s Stub class returns the result
References

Trail: RMI
by Ann Wollrath and Jim Waldo
http://java.sun.com/docs/books/tutorial/rmi/index.html

Fundamentals of RMI Short Course


by jGuru
http://developer.java.sun.com/developer/onlineTraining/
rmi/RMI.html
Java RMI Tutorial
by Ken Baclawski
http://www.eg.bucknell.edu/~cs379/DistributedSystems/
rmi_tut.html
http://www.cs.rutgers.edu/~pxk/rutgers/notes/pdf/rb-rmi.pdf

You might also like