EECE 411: Design of Distributed Software Applications Lecture 5 Distributed object systems Java RMI programmer’s view (RMI internals) Assignment 2.

EECE 411: Design of Distributed Software Applications

Lecture 5 Distributed object systems

Java RMI programmer’s view (RMI internals) Assignment 2


[Traditional] Objects

Object = data + methods logical and physical encapsulation Identified by means of references first class citizens, i.e., can be passed as

arguments Interaction defined via interfaces

define types of arguments and exceptions for methods

m1m2m3

Data

implementation

object

of methods

m1m2m3

Data

implementation

object

of methods

interface


The Distributed Object Model: Idea

Programs are (logically and physically) partitioned into objects Distribute objects across memory spaces

Client-server relationship at the object level

invocation invocationremote

invocationremote

locallocal

local

invocation

invocationA B

C

D

E

F


The Distributed Object Model: What’s needed?

Extend the object model with: Remote interfaces (to differentiate local access from

remote one) Remote method invocation (and new exceptions) Remote object references

Extend runtime Distributed garbage collection

invocation invocationremote

invocationremote

locallocal

local

invocation

invocationA B

C

D

E

F


Remote Object References [Traditional] Object references

used to access objects which live in processes can be passed as arguments and results can be stored in variables

Remote object references object identifiers in a distributed system must be unique across space and time error returned if accessing a deleted object may support relocation (e.g., in CORBA)

Internet address port number time object number interface of remote object

32 bits 32 bits 32 bits 32 bits


Remote Interfaces

Specify externally accessible methods no direct references to variables (no global memory) local interface is separate

Method arguments input, output or both Need to decide call semantics

How are arguments passed (call by value / call by reference / copy in-copy out)

Retry policy (at-least-once / at-most-once)

interfaceremote

m1m2m3

m4m5m6

Data

implementation

remoteobject

{ of methods


Handling Remote Objects

Exceptions raised in remote invocation clients need to handle exceptions timeouts in case server crashed or too busy

Garbage collection distributed garbage collection may be necessary combined local and distributed garbage collector multiple solutions are possible

(e.g. Java does reference counting/listing)


Java Remote Method Invocation


Argument Passing

If argument is primitive type Pass by value

If the object implements Remote interface Pass by reference

If object implements Serializable interface Pass by copy out

Note: deep copy! If none of the above

Exception is raised


Call semantics

At-most-once invocation Used by Java RMI (and Corba)


Performance Issues: Granularity

[generally] an RMI method invocation results in :

A new TCP connection to the remote server Creation of a new thread on the remote server

[issue] Concurrency to be managed by application

[as a result] RMI calls should be used for coarse-grain computation.


A programmer’s view

XYZImplementation

Client Host Server Host

Client program

XYZinterface

uses implements

Server(manages XYZ object)

Object

Registry


Hello World: Remote Interface

import java.rmi.*; +

public interface HelloInterface extends Remote { +

/* * Remotely invocable method,

* returns a message from the remote object,

* throws a RemoteException

* if the remote invocation fails

*/

public String say() throws RemoteException; +

}


Hello World: The Remote Object

import java.rmi.*; +import java.rmi.server.*; +

public class HelloImpl extends UnicastRemoteObject + implements HelloInterface { + private String message; /* Constructor for a remote object * Throws a RemoteException if the object handle * cannot be constructed */ public HelloImpl(String msg) throws RemoteException{ message = msg; } /* Implementation of the remotely invocable method

*/ public String say() throws RemoteException { return message; }}


Hello World: The ‘Server’

import java.io.*;import java.rmi.*;

public class HelloServer{ /* * Server program for the "Hello, world!" example. */ public static void main (String[] args) { try { Naming.rebind ("SHello", new HelloImpl ("Hello, world!")); System.out.println ("HelloServer is ready."); } catch (Exception e) { System.out.println ("HelloServer failed: " + e); } }}


Hello World: The Client

import java.io.*;import java.rmi.*;

public class HelloClient{ /* * Client program for the "Hello, world!" example */ public static void main (String[] args) { try { HelloInterface hello = (HelloInterface) Naming.lookup ("//matei.ece.ubc.ca/SHello");

/* ... Now remote calls on hello can be used ... System.out.println (hello.say()); } catch (Exception e) { System.out.println ("HelloClient failed: " + e); }}


Hello World: Compilation

On the server side compile with Java compiler: HelloInterface.java, HelloImpl.java, HelloServer.java

compile with RMI compiler: Hello command: rmic Hello

produces class Hello_Stub.class start the RMI registry: rmiregistry & (Standard port number 1099)

On the client side compile HelloClient

class HelloInterface.class needs to be accessible!


public interface Task {

Object run();} import java.rmi.*;

public interface ComputeServer extends Remote { Object compute(Task task) throws

RemoteException;}

import java.rmi.*; import java.rmi.server.*;public class ComputeServerImpl extends UnicastRemoteObject implements ComputeServer{ public ComputeServerImpl() throws RemoteException { } public Object compute(Task task) { return task.run(); }}

Quiz: What is this code meant to do?


Recap: Steps in developing an RMI application

1. Design the remote interface for the object.2. Implement the object specified in the

interface.3. Implement client/application

XYZImplementation


XYZClient

XYZinterface

uses implements1.

2.3.


RMI – Steps: Compile, Deploy and Use 4. Compile.

Compile (javac): interface, server, client Compile interface (rmic): Generate the stubs


XYZClient

Stub Stub

XYZinterface

uses implements1.

XYZImplementation


RMI – Steps: Compile, Deploy and Use 5. Start rmiregistry6. Start server, instantiate remote object &

register it7. Start client – locate remote object reference8. Invoke method on remote object


XYZClient

Stub Stub

XYZinterface

uses implements1.

2.4. 4.XYZImplementation

rmicrmiregistry

6. Store object reference

7. Retrieve object reference


Java Remote Method Invocation• Internals


object A proxy for B

Remote Communication

modulereference module

client

object Bserver stub

Communication Remote reference

module module

for B’s class& dispatcher

remote server

Request

Reply

Internal Implementation of RMI

Dispatcher - gets request from communication module and invokes method in server stub(using methodID in message).

Server stub - implements methods in remote interface. Unmarshals requests and marshals results. Invokes method in remote object.

Carries out Request-reply protocol

Translates between local and remote object references and creates remote object references. Uses remote object table

RMI: software layer between application level objects and communication and remote reference modules

Proxy - makes RMI transparent to client. Class implements remote interface. Marshals requests and unmarshals results. Forwards request.


Communication Modules Reside in client and server Carry out Request-Reply jointly

use unique message ids (new integer for each message)

implement given RMI semantics Server’s communication module

selects dispatcher within RMI software calls Remote Reference Module to convert remote

object reference to local


Remote Reference Module Creates remote object references and proxies

Translates remote to local references (object table):

correspondence between remote and local object references (proxies)

Called by RMI software when marshalling/unmarshalling


RMI Software Architecture Proxy

behaves like local object to client forwards requests to remote object

Dispatcher receives request selects method and passes on request to skeleton

Server stub (aka skeleton) implements methods in remote interface

unmarshals data, invokes remote object waits for result, marshals it and returns reply


Java Remote Method Invocation• Miscelaneous


Classes Supporting Java RMI

RemoteServer

UnicastRemoteObject

<servant class>

Activatable

RemoteObject

Good if you want to control the set of active objects yourself


Binding and Naming

Goal mapping from textual names to remote references used by clients as a look-up service (cf Java

RMIregistry)

Available methods void rebind (String name, Remote obj)

used by a server to register the identifier of a remote object by name

void bind (String name, Remote obj) alternatively used by a server to register a remote object by name,

but if the name is already bound to a remote object reference an exception is thrown.

void unbind (String name, Remote obj) removes a binding.

Remote lookup(String name) used by clients to look up a remote object by name. A remote

object reference is returned. String [] list()

This method returns an array of Strings containing the names bound in the registry.


RMI Security

Server/client may not trust each other User code (or even Stubs) could be malicious


RMI: Loading stub classes

Client can load (application & stub) classes dynamically

java.rmi.server.codebase property defines where these are loaded from

The RMI class loader always tries to load stubs from the CLASSPATH first

Next, it tries downloading classes from a remote location

java.rmi.server.codebase specifies which web server

(but only if a security manager is enabled)

CLASSPATH can be confusing 3 VMs, each with its own classpath: Server vs. Registry vs. Client


RMI Security Managers None

Remote stub loading disabled Class/Stubs loading still works if they are in local CLASSPATH

RMISecurityManagerDisables all functionality except

class definition and access A downloaded class is allowed to make a connection if the

connection is initiated via the RMI transport. if(System.getSecurityManager() == null) {

System.setSecurityManager(new RMISecurityManager());

} Need to specify a security policy file at runtime by defining a

value for the java.security.policy property: java -Djava.security.policy=policyfilename

AppletSecurityManager Stub can only do what an applet can do


Server logging

Start logging: from command line at startup:

java java -Djava.rmi.server.logCalls=true YourServerImpl or enable inside program:

RemoteServer.setLog(System.err);


Assignment 2 discussion



Push vs. pull design

Server initiates communication (pushes data) Advantage: possibly lower load on server Drawback: server needs to maintain state (list of

clients) Client initiates communication (pulls data)

Advantage: no client registration needed, server does not maintain data, more flexibility for clients

Drawback: load on server, DoS attacks



Server initiates communication (pushes data) Two subsequent problems:

When to initiate communication (push the data)? Where to push it (How to find he clients?


Similar to Callbacks

Q: How can one implement asynchronous communication? Deal with asynchronous events?

Callback mechanism The client presents a notification method (or object for RMI)

and registers it with the server Server invokes the method (“calls back”) to notify the client (Note for RMI: the rmiregistry is out of the loop)

RMI specific – two solutions The object passed by the client extends

UnicastRemoteObject, The remote object prepares itself for remote use by calling

UnicastRemoteObject.exportObject (<remote_object>, 0)


Assignment 2 discussion: Chat system using RMI & callbacks

One possible solution: the server has

a Multicaster object with a method send(String) each client has

a Display object with a method show(String)

both methods are remote.

Clients invoke send and the server invokes show.

Sending a string means showing it on all displays.


Garbage collection in single box systems

Solutions Reference counting Tracing based solutions (mark and sweep)


Garbage collection in distributed systems Why is it different?

References distributed across multiple address spaces

Why a solution may be hard to design: Unreliable communication Unannounced failures Overheads


Reference Counting

The problem: maintaining a proper reference count in the presence of unreliable communication.

Key: ability to detect duplicate messages [A note on terminology: for the next few slides I’ll

use proxy for client stub and skeleton for server stub.]


Reference Counting (cont)Passing remote object references

a) Copy the reference and let the destination increment the counter• Problems?

• What if P1 deletes its reference before P2 increments the counter

b) Signal the copy first to the server• Problems?

• Overheads, Coupling (what if P2 fails?)


Advanced Reference Counting Weighted Reference Counting

a) Initial assignment of weights (lifes)b) New weight (life) assignment when creating a new reference.


Advanced Reference Counting Weighted Reference Counting (II)

Weight (life) assignment when copying a reference.

Pros/cons? + Create new references without contacting the

server! - Client machine failures


Reference Listing (Java RMI’s solution)

Skeleton maintains a list of client proxies Creating a remote reference

Assume P attempts to create remote reference to O P sends its identification to O skeleton O acknowledges and stores P identity P creates the proxy

Copying a remote reference (P1 attempts to pass to P2 a remote reference to O)

Advantages: add/delete are idempotent

i.e. duplicate operations have no effect no reliable communication required

Drawback overheads/scalability – the list of proxies can grow large handling unanounced client failures (may lead to

resource leak)


Reference Listing (Java RMI’s solution) Handling failures

Handling failures Lease based approach:

Skeleton promises to keep info on client only for limited time.

If info not renewed then the skeleton discards it.

Pros/Cons?


Summary so far

Push vs. pull design Callbacks

Distributed garbage collection Solutions much more complex than for non-

distributed case No perfect solution: depending on the

assumptions you make on your platform one or the other might offer the best tradeoffs

Lease based approaches (or soft-state): often practical solutions to scale in distributed environments

EECE 411: Design of Distributed Software Applications Lecture 5 Distributed object systems Java RMI programmer’s view (RMI internals) Assignment 2.

Documents