RPC, RMI and CORBA

Object-based DistributedSystemsEEE466Reference: [CDK00] ch. 5 and [CW01] RMI trail

Architectural Abstractions• sockets• make IPC look like explicitly sending messages(datagram) or reading and writing a file (stream)localprocessmessagesor IOremoteprocess• remote procedure call or remote method invocation• make IPC look like local procedure call or methodinvocationlocalobjectmethodinvocationreturnvalueargsremoteobjectArguments and return values must be either serializable (passed by copy)or remote objects themselves (passed by remote reference).

Design Exercise – a remote procedurecall protocol• Service – Remote Cryptographic Engine (RCE)• Module has the following APIpublic String encrypt( int[] key, String plaintext)public String derypt( int[] key, String cyphertext)public String messageDigest( String plaintext)where: key is an array of 4 32-bit integers

Programming with RMI*• create a remote object• define a remote interface (CORBA IDL or Java)• create an implementation of the remote interface• make available to users• by registering with a name service• by passing as an argument or a return value• use a remote object:• obtain a remote reference• by “bootstrapping” (from a name service)• as an argument or return value• reference is to remote interface type not implementation class• operate on the reference• standard method invocation syntax• multiple possible semantics• be prepared to handle errors from partial failure* In these lectures, RMI means remote method invocationgenerally, unless Java RMI is specifically indicated

Programming Model• integrated into vs. attached to• CORBA is “language neutral”• can be added onto many languages, allows multilingual systems• difficult to pass objects by copy• requires additional language (CORBA Interface DefinitionLanguage (IDL)) and tools (IDL compiler)• requires separate Object Request Broker (ORB), security model,garbage collection mechanism• Java RMI integrated into Java• can assume all objects are Java objects• known semantics• possible to pass objects by copy• no additional language to learn, tools are built-in (including RMIcompiler)• benefits from Java security model• ORB part of JVM; JVM handles distributed garbage collection

Java RMI Development ProcessDeveloperRemote interfacedefinitionJavacompilerInterface.class fileDeveloperRemote objectimplementationJavacompilerImplementation.class fileSkeleton.class fileRMIcompilerStub.class fileDeveloperClientimplementationJavacompilerClient.class file

Define a Remote Interface• the interface defines methods and attributesavailable to users (clients) of the remote object• must be defined in an Interface Definition Language(IDL)• CORBA provides a separate IDL which can be mappedonto multiple other languages’ object models• Java RMI uses the standard Java interface definitionmechanism

Java RMI Development ProcessDeveloperRemote interfacedefinitionJavacompilerInterface.class fileDeveloperRemote objectimplementationJavacompilerImplementation.class fileSkeleton.class fileRMIcompilerStub.class fileDeveloperClientimplementationJavacompilerClient.class file

Make Available to Users• “bootstrapping” refers to finding the initial object,usually the server access point• once that object is found, it may pass remotereferences of other “server” objects• in CORBA• the implementation is instantiated in an implementationrepository, which is associated with a name, directory,or “trader” service• in Java RMI• must “export” the object• inherit from java.rmi.server.UnicastRemoteObject and call itsconstructor by super(), or call the static methodUnicastRemoteObject.exportObject()

Java RMI Development ProcessDeveloperRemote interfacedefinitionJavacompilerInterface.class fileDeveloperRemote objectimplementationJavacompilerImplementation.class fileSkeleton.class fileRMIcompilerStub.class fileDeveloperClientimplementationJavacompilerClient.class file

Client Side: Obtain a Remote Reference• Need to obtain an initial remote reference from aname server/trader service• Reference is to the remote interface type

Review• RMI Development Process

Java RMI Development ProcessDeveloperRemote interfacedefinitionJavacompilerInterface.class fileDeveloperRemote objectimplementationJavacompilerImplementation.class fileSkeleton.class fileRMIcompilerStub.class fileDeveloperClientimplementationJavacompilerClient.class file

Server Side: Important Detail—Java• In Java, all classes inherit from Object and arerequired to support Object’s core operations• remote objects need special implementations ofequals(), hashCode() and toString(), since thenormal implementations would require remotereferences but don’t throw RemoteExceptions• for remote objects, equals() and hashCode() operate onthe remote object identifier so equality and identityare the same• The required implementations are provided inUnicastRemoteObject. Either extend that class, orprovide reasonable implementations for these threemethods.

Structure of an RMI Application• Consider the following simple example:• A “Hello” service that when the “sayHello” methodis invoked the service will respond with the String“Hello, World!”

Remote Interface Definition

Remote Object Implementation

Client Implementation

RMI Mechanism• Work through collaboration diagram

package common;import java.rmi.Remote;import java.rmi.RemoteException;public interface Hello extends Remote {public String sayHello() throws RemoteException;}

package server;import java.rmi.registry.Registry;import java.rmi.registry.LocateRegistry;import java.rmi.RemoteException;import java.rmi.server.UnicastRemoteObject;import common.Hello;public class Server extends UnicastRemoteObject implements Hello {public Server() throws RemoteException {super();}public String sayHello() throws RemoteException {return "Hello, world!";}public static void main(String args[]) {try {Server server = new Server();// Bind the remote object's stub in the registryRegistry registry = LocateRegistry.getRegistry();registry.rebind("Hello", server);}}System.err.println("Server ready");} catch (Exception e) {System.err.println("Server exception: " + e.toString());e.printStackTrace();}

package client;import java.rmi.registry.LocateRegistry;import java.rmi.registry.Registry;import java.rmi.RMISecurityManager;import common.Hello;public class Client {private Client() {}public static void main(String[] args) {System.setSecurityManager(new RMISecurityManager());}}String host = (args.length < 1) ? "localhost" : args[0];try {Registry registry = LocateRegistry.getRegistry(host);Hello stub = (Hello) registry.lookup("Hello");String response = stub.sayHello();System.out.println("response: " + response);} catch (Exception e) {System.err.println("Client exception: " + e.toString());e.printStackTrace();}

This file was generated by the RMI Plugin for Eclipse.///////////////////////////////////////////////////////////////// This is a sample policy file that grants the application all permissions.// A policy file is needed by the RMISecurityManager and your application might// not work after installing the RMISecurityManager unless you provide a// security policy file at launch.//// You can configure the security policy of a launched application using either// the RMI Launcher or by manually setting the java.security.policy property.//// SECURITY NOTE: This security policy is good for development. For deployment// you may need a stricter security policy.//// For more information see:// http://java.sun.com/docs/books/tutorial/rmi/running.html// http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html//grant {permission java.security.AllPermission;// Other options:// permission java.net.SocketPermission "127.0.0.1:1024-", "accept, connect, listen, resolve";// permission java.net.SocketPermission "localhost:1024-", "accept, connect, listen, resolve";// From http://java.sun.com/docs/books/tutorial/rmi/running.html// Copyright 1995-2005 Sun Microsystems, Inc. Reprinted with permission// permission java.net.SocketPermission "*:1024-65535", "connect,accept";// permission java.net.SocketPermission "*:80", "connect";};// permission java.net.SocketPermission "*:1024-65535", "connect,accept";// permission java.io.FilePermission "c:\\home\\ann\\public_html\\classes\\-", "read";// permission java.io.FilePermission "c:\\home\\jones\\public_html\\classes\\-", "read";

Design Example:• In this example you will use Java RMI to create asmall distributed application. The application is asimple Domain Name Service (SDNS) that maintainsa table of (IP address, Domain Name) pairs.• The SDNS server is a service that maintains adirectory of (domain name, ip address) pairs. Aclient makes request of the remote SDNS serverobject using RMI. The SDNS protocol is defined byan interface that allows an SDNS client to performupdates and requests on a remote SDNS server.

Review• RMI Semantics

Client-Server CommunicationRPC/RMI• typically the client is requesting that the serverperform some service• normal pattern:• server invokes GetRequest and blocks until a requestarrives• server: blocking receive• client invokes DoOperation on server and blockswaiting for reply• client: asynchronous send, followed by blocking receive• server performs operation, invokes SendReply, andinvokes GetRequest again• server: unblocks, performs operation, asynchronous send,followed by blocking receive• client: unblocks, continues

Specification of the OperationsIn pseudo-Java:Message DoOperation(PortId server, Message msg)• the returned message is the result of SendReply• blockingMessage GetRequest(PortId server)• acquires a request message• blockingvoid SendReply(PortId client, Message msg)• sends a reply messageinterface Message {}MessageType type;int requestId;int methodId;Object[] arguments;// request or reply// matches replies to requests// method to execute// flattened list

Delivery Failures• In the general case• messages are occasionally dropped by senders,receivers, and the network• networks may become partitioned• processes may fail• not generally distinguishable from network failure• typically assume failure after N requests; choosing a good N is ahard problem• received data is corrupted• To account for this, DoOperation should have atimeout associated with it; other steps arenecessary

Possible Exchange Protocols• Looked at Request-Reply• Three widely used variants:• Request• no value to be returned• no confirmation of operation is required• Request-Reply• used for most client-server communications• reply regarded as acknowledgement from server• next request regarded as acknowledgement from client• Request-Reply-Acknowledge• acknowledgements include requestIds; receipt of a requestIdimplies receipt of all lower-numbered requestIds• losing an acknowledge message is harmless

Timeouts• Possible options on timeout of DoOperation:• return with error indication• relies on application-level interpretation• not appropriate if operation must be redone, since the newattempt will have a different requestId (possible source ofduplicate requests)• multiple retry• re-invokes DoOperation with same message until success or“reasonably certain” problem due to server failure• returns with server failure indication (throws Exception)

Duplicate Requests• Since client may retransmit requests, server mayreceive duplicates• e.g., server may be slow processing a request, exceedsclient timeout, client retries• with requestIds globally unique, can discard duplicates

Lost Replies• If a server has already sent a reply when it receivesa duplicate, it may need to resend• cause may be lost reply message• resending may require recomputing original request• if operation is x=7 this poses no problem• if operation is x+=1 recomputing the request will lead toincorrect values of x• recomputation is only allowable when the operationsare idempotent• an idempotent operation is one that can be performed repeatedlywith the same effect as if it had been performed exactly once• Servers with only idempotent operations canrecompute duplicates

History• When a server cannot safely recompute operations,it can use a reply history• record of reply messages that have been transmitted• identifies requestId, message, client identifier• Main issue is storage cost: require a mechanism todelete histories that are no longer required• if clients make only one request at a time, receipt ofnext (new) request is acknowledgement of previous• history can be erased up to new request, for this client• can also use request-reply-acknowledge• if many clients, storage requirement may be large• problematic when client disappears withoutacknowledging last request (Always happens in requestreplyprotocol. Why?)

Remote Method Semantics• in creating implementation, must understanddelivery guarantee provided by system• relies on request-reply protocol (client-server lecture)• at-least-once• succeeded or failed, may have been executed multipletimes• at-most-once (Java RMI, CORBA)• if succeeded, executed exactly once• if failed, executed either zero or one times

Examples:• Specify:• the semantics needed (at-least-once, etc)• an appropriate protocol exchange (request-reply, etc.)• is the server operation idempotent• Get time• Report position (eg. Situational Awareness, gaming)• Execute a financial transaction• Open a door remotely• PER Workflow• Send mail• Get mail