© City University London, Dept. of Computing Distributed Systems / 4 - 1 Distributed Systems Session 4: RPCs (Remote Method Invocation) Java RMI. Christos

© City University London, Dept. of Computing Distributed Systems / 4 - 1

Distributed Systems

Session 4: RPCs (Remote Method Invocation) Java RMI.

Christos KloukinasDept. of Computing

City University London


Outline

Motivation and Introduction to Java RMI Conceptual Framework RMI Details Example Implementation Summary


0 Motivation

DS require computations running in different address spaces (different hosts) to communicate

For basic communication; Java Supports sockets; Sockets API=SEND & RECV CALLS

Sockets require Client & Server engage in application level protocols to encode and decode messages for exchange

Design of such protocols is cumbersome and error prone Alternative is Remote Procedure Call (RPC) (think of sin(),

log(), static methods…)


0.1 RPC

RPC abstracts the communication interface to the level of procedure call i.e provides procedural interface to distributed (remote) services

Instead of working directly with socket, programmer has illusion of calling a local proc. (transparency)

BUT in reality; arguments of the call are packaged and shipped to remote target of call (marshalling)

RPC systems encode arguments and return values using an external representation such as XDR


0.2 RPC to RMI

RPC does not translate well into distributed object systems (DOS)

Communication between program-level objects residing in different address spaces is required

To match the semantics of object invocation, DOS require remote method invocation or RMI

Here, a local surrogate(stub) object manages invocation on remote object

RPC + Object Orientation


0.3 Middleware Layers

Request-Reply protocolMarshalling and external data Representation

RMI and RPC

Application and services

TCP and UDP

Middleware layers


0.3 Java RMI:The Essence

RMI provide you with an object Oriented mechanism to invoke a method on an object that exist somewhere else.

Java RMI system assumes the homogeneous environment of the java virtual machines (JVM)

therefore it takes advantage of the java platform’s object model whenever possible.


0.4 Java

Java is an object-oriented programming language developed by Sun Microsystems that is both compiled and interpreted: A Java compiler creates byte-code, which is interpreted by a virtual machine (VM).

Java is portable: Different VMs interpret the byte-code on different hardware and operating system platforms.


0.5 RMI Rationale High-level primitive for object communication (not just

UDP datagrams and TCP streams). RMI is tightly integrated with the rest of Java language

specification, development environment and the Java VM. Reliance on Java VMs for the resolution of heterogeneity.

RMIs can assume a homogeneous representation Java/RMI does not support RMI between Java objects

and objects written in another OO language (unless you use the native interface for C/C++)


0.6 Client-Service

Before getting into the details, we should examine what an RMI system looks like in comparison to a standard strong-referenced object relationship.

In a standard instantiate-and-invoke relationship, there are only the Client and Service objects.

They both live in the same virtual machine. Method invocations are made directly on the Service

object.


0.7 Client-Service


0.8 RMI

In RMI, the Client object does not directly instantiate the Service,

BUT gets a reference to its interface through the RMI Naming service.

This interface hooks up the client system to the server through a series of layers and proxies until it reaches the actual methods provided by the Service object.


0.9 Remote Method Invocation


1.0 Conceptual Framework: Aspects

Architecture.

Accessing components from programming languages.

Interfaces to lower layers.

Component identification.

Service invocation styles.

Handling of failures.


1.1 System Goals of RMI

Seamless integration of objects on different VMs. Support callbacks from servers to applets. Distributed object model for Java

» Security, write once run everywhere, multithreaded

» Object Orientation

Simplicity (learning curve) Safety (maintain Java standards) Flexibility (several invocation mechanisms and various

reference semantics, distributed garbage collection)


Distributed Object Application Requirements

Locate remote objects» App can register its remote objects with RMI naming

facility, the rmiregistry Communicate with remote objects

» Details of communication handled by RMI.(Transparency) Load class bytecodes for objects that are passed as

parameters or return values» RMI provides class loading


2.0 Remote Method Invocation

Overview of RMI architecture.

Generation of client/server stubs.

RMI interface.

Binding.

Handling of remote methods.

Failures of RMIs.


2.1 RMI Architecture

Client Server

Network

Local Call

ServerStub

RMIInterface

RMIInterface

ServerSkeleton

Remote ObjectMethod

send receive send receive


2.2 RMI Components

Remote Object Interfaces Client Server Stub Skeleton


2.31 The Remote Object: Remote object is a class that is designed to

execute on a server but be treated by the client as if it were local.

There are several reasons why you would want to implement a class as a remote object: » the object will run faster, security and proximity to

necessary resources than it would on the client. » If the above reasons don’t apply then it’s probably not a

good idea to implement a class as a remote object.


2.32 The interface

An RMI remote object must extend java.rmi.Remote. When deploying the remote object, a stub is created that implements the same interface.

The major purpose of the interface is to provide the template that is used by both the remote object and its stubs.

The client never instantiates the remote object itself, and in fact doesn’t even need the class file on its system.


2.33 The Interface: Advantages There are several advantages to using an

interface that makes RMI a more robust platform.» Security by preventing decompiling» The interface is significantly smaller than the actual remote object’s class,

so the client is lighter in weight.» Maintainability; If changes are made to the underlying remote object, it

would need to be propagated to the clients, otherwise serious errors can occur.

» From an architectural standpoint, the interface is cleaner. The code in the remote object will never run on the client, and the interface acts appropriately as a contract between the caller and the class performing the work remotely.


2.34 The Client

Users of remote objects . Use Naming Class to lookup() objects instead of

creating them with the new keyword. However, the remote object is NOT returned, only a

stub which happens to implement the same interface of the remote object.

Once the client has an object which implements the remote object interface, it can make calls on it as if it was the real object.


2.35 The stub The client needs more than just the interface to call

the methods on the remote object. Proxy for the remote object, obtained via naming

service Implements all of the methods of its interface. The stub’s major functionality is serializing objects

between the client and server over the RMI port, i.e Marshalling and unmarshalling


2.36 The Skeleton On the other side of the connection is a skeleton

of the remote object, as well as the remote object itself.

When the server starts, it creates an instance of the remote object and waits for invocations.

Each time a method is called on the stub from the client, the skeleton object receives a “dispatch” from the server .

The Skeleton is responsible for dispatching the call to the actual object implementation.


2.37 The Server

RMI server must be present and running on the network.

Create with an instance of class that implement remote interface. I.e creates remote objects

Can be used to start the RMI naming service. Binds an instance of the remote object to the

naming service, giving it an alias in the process.


Implementation

Hello World Program


3.0 How to Write RMI ApplicationsDefine your

remote interface

Server class(.class)

Server skeleton(.class)

Client Stub(.class)

Implement Client

javac

Start client

Start RMI registry

Server

Client

rmic

Start Server objects Register remote objects

Implement theinterface

javac

uses

(.java)

(.class)

Run the Stub Compiler

(.java)

(.class)

Client

8

1

4

3

2

5 9

7106


3.0 How to write an RMI application

To write an RMI application proceed as follows: 1) Define a remote interface (Server Services) by extending java.rmi.Remote and have

methods throw java.rmi.RemoteException 2) Implement the remote interface. You must provide a Java server class that implements

the interface. It must be derived from the class java.rmi.UnicastRemoteObject 3) Compile the server class using javac 4) Run the stub compiler rmic. Run rmic against your (.class) file to generate client stubs

and server skeletons for your remote classes. (REMEMBER proxies for marshalling & unmarshalling)

5) Start the RMI registry on your server (call rmiregistry &). The registry retrieves and registers server objects. In contrast to CORBA it is not persistent.

6) Start the server object and register it with the registry using the bind method in java.rmi.Naming

7) Write the client code using java.rmi.Naming to locate the server objects. 8) Compile the client code using javac 9) Start the client


3.1 Implementing RMI

Interface for remote object:public interface Hello extends java.rmi.Remote

{String sayHello() throws java.rmi.RemoteException;

}

Implementation of server (declaration):import java.rmi.*;import java.rmi.server.UnicastRemoteObject;public class HelloImpl

extends UnicastRemoteObjectimplements Hello {

private String name;...


3.2 Implementing RMI: RMI Core

RemoteException superclass for exceptions specific to remote objects thrown by RMI runtime (broken connection, a reference mismatch, e.g.)

The Remote interface embraces all remote objects (Does not define methods, but serves to flag remote objects)

The RemoteObject class corresponds to Java’s Object class. It implements remote versions of methods such as hashCode, equals, toString

The class RemoteServer provides methods for creating and exporting servers (e.g. getClientHost, getLog), I.e. common superclass to server implementations and provides the framework to support a wide range of remote reference semantics.

UnicastRemoteObject Your server must either directly inherit or indirectly extend the class and inherit its remote behaviour: implements a special server with the following characteristics:

» all references to remote objects are only valid during the life of the process which created the remote object

» it requires a TCP connection-based protocol

» parameters, invocations etc. are communicated via streams


3.3 Interfaces and Classes

Remote RemoteObject

RemoteServer

Activatable UnicastRemoteObject

IOException

RemoteException

Interfaces Classes

extensionimplementation


3.4 Implementing RMI (Server)

Impl. of server (constructor, method, main):public HelloImpl(String s)throws RemoteException {super(); name = s;}public String sayHello() throws RemoteException {return "Hello World!";}public static void main(String args[]){System.setSecurityManager(new

RMISecurityManager());try {

HelloImpl obj = new HelloImpl("HelloServer"); Naming.rebind("//myhost/HelloServer",obj);} catch (Exception e) {…}

“localhost” or run Java like this: java helloSrv `hostname`


3.5 Implementing RMI (Server)

The class Naming is the bootstrap mechanism for obtaining references to remote objects based on Uniform Resource Locator (URL) syntax. The URL for a remote object is specified using the usual host, port and name: rmi://host:port/name host = host name of registry (defaults to current host) port = port number of registry (defaults to the registry port number) name = name for remote object

A registry exists on every node that allows RMI connections to servers on that node. The registry on a particular node contains a transient database that maps names to remote objects. When the node boots, the registry database is empty. The names stored in the registry are pure and are not parsed. A service storing itself in the registry may want to prefix its name of the service by a package name (although not required), to reduce name collisions in the registry.


3.6 Implementing RMI (Client)

Remote remoteHello = null;Hello myHello = null;System.setSecurityManager(

new RMISecurityManager());try {

remoteHello = Naming.lookup("//myhost/HelloServer");

myHello = (Hello) remoteHello;}…


3.7 Implementing RMI: Summary

To summarise the above example:» The server creates the server object and binds it

to a name

» The client uses lookup to get an object reference and then has to perform a cast to turn a RemoteObject into an object of the proper type


4.0 RMI Interface

Used by client or server directly:» Locating servers.

» Choosing a transport protocol.

» Authentication and security.

» Invoking RMIs dynamically.

Used by stubs for:» Generating unique message IDs.

» Sending messages.

» Maintaining message history.


5.0 Binding

How to locate an RMI server that can execute a given procedure in a network?

Can be done» statically (i.e. at compile-time) or

» dynamically (i.e. at run-time).


5.1 Binding

A problem that arises is to locate that server in a network which supports the program with the desired remote procedures.

This problem is referred to as binding. Binding can be done statically or dynamically. The binding

we have seen in the last example was static because the hostname was determined at compile time.

Static binding is fairly simple, but seriously limits migration and replication transparency.

With dynamic binding the selection of the server is performed at run-time. This can be done in a way that migration and replication transparency is retained.


5.1 Binding

Limited support for dynamical server location with the LocateRegistry class to obtain the bootstrap Registry on some host. Usage (minus exception handling):

// Server wishes to make itself available to others: SomeSRVC service = ...; // remote object for service Registry registry = LocateRegistry.getRegistry(); registry.bind("I Serve", service); // The client wishes to make requests of the above service: Registry registry = LocateRegistry.getRegistry("foo.services.com"); SomeSRVC service = (SomeSRVC)registry.lookup("I Serve"); service.requestService(...);

Programs can be easily migrated from one server to another and be replicated over multiple hosts with full transparency for clients.


6.0 Handling of Remote Methods

Call handled synchronously by server.

Concurrent RMIs:» serial or» concurrently.

Server availability:» continuous or» on-demand.» (RMI & CORBA support both)


7.0 Failures of RMIs

Machines or networks can fail at any time.

At most once semantics.

RMI return value indicates success.

Up to the client to avoid maybe semantics!


Summary 1

The client process’s role is to invoke the method on a remote object. The only two things that are necessary for this to happen are the remote interface and stub classes.

The server, which “owns” the remote object in its address space, requires all parts of the RMI interchange.

When the client wants to invoke a method on a remote object, it is given a surrogate that implements the same interface, the stub. The client gets this stub from the RMI server as a serialized object and reconstitutes it using the local copy of that class.


Summary 2

The third part of the system is the object registry. When you register objects with the registry, clients are able to obtain access to it and invoke its methods.

The purpose of the stub on the client is to communicate via serialized objects with the registry on the server. It becomes the proxy for communication back to the server.


Summary The critical parts of a basic RMI system include

the client, server, RMI registry, remote object and its matching stub, skeleton and interface.

A remote object must have an interface to represent it on the client, since it will actually only exist on the server. A stub which implements the same interface acts as a proxy for the remote object.

The server is responsible for making its remote objects available to clients by instantiating and registering them with Naming service.


The Remote Method Invocation (RMI) is a Java system that can be used to easily develop distributed object-based applications.RMI, which makes extensive use of object serialization, can be expressed by the following formula:

RMI = Sockets + Object Serialization + Some Utilities

The utilities are the RMI registry and the compiler to generate stubs and skeletons.

If you are familiar with RMI, you would know that developing distributed object-based applications in RMI is much simpler than using sockets.

So why bother with sockets and object serialization then?

Critique


• The advantages of RMI in comparison with sockets are:• Simplicity: RMI is much easier to work with than sockets• No protocol design: unlike sockets, when working with RMI there is no need to worry about designing a protocol between the client and server -- a process that is error-prone.

• The simplicity of RMI, however, comes at the expense of the network.• There is a communication overhead involved when using RMI and that is due to the RMI registry and client stubs or proxies that make remote invocations transparent. For each RMI remote object there is a need for a proxy, which slows the performance down.

Critique


Online Resources & Reading

Chapter 4 of Course textbook Chapter 5 of Coulouris & Dollimore Examples at

//web.archive.org/web/20031220223738/http://www.churchillobjects.com/c/11086.html

Tutorials at //engronline.ee.memphis.edu/advjava/online.htm short tutorial at

//www.eg.bucknell.edu/~cs379/DistributedSystems/rmi_tut.html

Next Session:CORBA & COMPARISON WITH RMI

Documents

© City University London, Dept. of Computing Distributed Systems / 4 - 1 Distributed Systems Session 4: RPCs (Remote Method Invocation) Java RMI. Christos