Transcript L05

Lecture 5

Distributed object systems

Java RMI



programmer’s view
(RMI internals)
Assignment 2
EECE 411: Design of Distributed Software Applications
[Traditional] Objects
object
object
Data
implementation
of methods

m1
m2
m3
m1
m2
m3
implementation
of methods
Object = data + methods




Data
interface
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
EECE 411: Design of Distributed Software Applications
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
local
remote
invocation
A
B
C
E
invocation local
invocation
local
invocation
D
EECE 411: Design of Distributed Software Applications
remote
invocation
F
The Distributed Object Model: What’s needed?
local
remote
invocation
A

remote
invocation
F
Extend the object model with:




B
C
E
invocation local
invocation
local
invocation
D
Remote interfaces (to differentiate local access from remote one)
Remote method invocation (and new exceptions)
Remote object references
Extend runtime

Distributed garbage collection
EECE 411: Design of Distributed Software Applications
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




32 bits
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)
32 bits
Internet address port number
32 bits
time
32 bits
object number
EECE 411: Design of Distributed Software Applications
interface of
remote object
Remote Interfaces
remoteobject
remote
interface
{

m1
m2
m3
implementation
of methods
m4
m5
m6
Specify externally accessible methods



Data
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)
EECE 411: Design of /
Distributed
Software Applications
Retry policy (at-least-once
at-most-once)
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)
EECE 411: Design of Distributed Software Applications
Java Remote Method Invocation
EECE 411: Design of Distributed Software Applications
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
EECE 411: Design of Distributed Software Applications
Call semantics
At-most-once invocation
 Used by Java RMI (and Corba)
EECE 411: Design of Distributed Software Applications
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 coarsegrain computation.
EECE 411: Design of Distributed Software Applications
A programmer’s view
Object
Registry
Server
(manages XYZ object)
Client
program
uses
XYZ
interface
implements
Client Host
XYZ
Implementation
Server Host
EECE 411: Design of Distributed Software Applications
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;
}
EECE 411: Design of Distributed Software Applications
+
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;
}
}
EECE 411: Design of Distributed Software Applications
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);
}
}
}
EECE 411: Design of Distributed Software Applications
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);
EECE 411: Design of Distributed Software Applications
}
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!
EECE 411: Design of Distributed Software Applications
public interface Task {
Quiz: What is this code meant to do?
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();
}
EECE 411: Design of Distributed Software Applications
Recap: Steps in developing an RMI application
1.
2.
3.
Design the remote interface for the object.
Implement the object specified in the interface.
Implement client/application
3.
2.
XYZ
Implementation
XYZ
Client
uses
1.
XYZ
interface
implements
Client Host
Server Host
EECE 411: Design of Distributed Software Applications
RMI – Steps: Compile, Deploy and Use
4.
Compile.


XYZ
Client
Compile (javac): interface, server, client
Compile interface (rmic): Generate the stubs
Stub
uses
Client Host
XYZ
Implementation
Stub
1.
XYZ
interface
implements
Server Host
EECE 411: Design of Distributed Software Applications
RMI – Steps: Compile, Deploy and Use
5.
6.
7.
8.
Start rmiregistry
Start server, instantiate remote object & register it
Start client – locate remote object reference
Invoke method on remote object
7. Retrieve object
reference
4.
XYZ
Stub
rmiregistry
rmic
Implementation
Client
uses
6. Store object
reference
4.
2.
XYZ
Stub
1.
XYZ
interface
implements
Client HostEECE 411: Design of Distributed Software ApplicationsServer Host
Java Remote Method Invocation
• Internals
EECE 411: Design of Distributed Software Applications
Internal Implementation of RMI
server
client
object A proxy for B
Request
server stub
& dispatcher
for B’s class
remote
object B
Reply
Communication
Remote
reference module
module
Communication
module
CarriesClass
out RequestProxy - makes RMI transparent to client.
implements
reply
remote interface. Marshals requests
andprotocol
unmarshals
results. Forwards request.
Translates
local and
remote
object interface.
Server stubbetween
- implements
methods
in remote
references
and
createsand
remote
object
Unmarshals
requests
marshals
results. module
Invokesand
Dispatcher
- gets
request
from
communication
references.
Uses
remote
object table
method
in remote
object.
invokes
method
in server
stub(using
methodID in
message).
Remote reference
module
RMI: software layer
between application
level objects and
communication and
remote reference
modules
EECE 411: Design of Distributed Software Applications
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
EECE 411: Design of Distributed Software Applications
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
EECE 411: Design of Distributed Software Applications
RMI Software Architecture

Proxy



Dispatcher



behaves like local object to client
forwards requests to remote object
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
EECE 411: Design of Distributed Software Applications
Java Remote Method Invocation
• Miscelaneous
EECE 411: Design of Distributed Software Applications
Classes Supporting Java RMI
RemoteObject
RemoteServer
Activatable
Good if you want
to control the set
of active objects
yourself
UnicastRemoteObject
<servant class>
EECE 411: Design of Distributed Software Applications
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)


void bind (String name, Remote obj)


removes a binding.
Remote lookup(String name)


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)


used by a server to register the identifier of a remote object by 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.
EECE 411: Design of Distributed Software Applications
RMI Security


Server/client may not trust each other
User code (or even Stubs) could be malicious
EECE 411: Design of Distributed Software Applications
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
EECE 411: Design of Distributed Software Applications
RMI Security Managers

None



Remote stub loading disabled
Class/Stubs loading still works if they are in local CLASSPATH
RMISecurityManager
Disables 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
EECE 411: Design of Distributed Software Applications
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);
EECE 411: Design of Distributed Software Applications
Assignment 2 discussion
EECE 411: Design of Distributed Software Applications
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
EECE 411: Design of Distributed Software Applications
Assignment 2 discussion

Server initiates communication (pushes data)

Two subsequent problems:


When to initiate communication (push the data)?
Where to push it (How to find he clients?
EECE 411: Design of Distributed Software Applications
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)
EECE 411: Design of Distributed Software Applications
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.
EECE 411: Design of Distributed Software Applications
Garbage collection in single box systems
Solutions
 Reference counting
 Tracing based solutions (mark and sweep)
EECE 411: Design of Distributed Software Applications
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
EECE 411: Design of Distributed Software Applications
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.]
EECE 411: Design of Distributed Software Applications
Reference Counting (cont)
Passing remote object references
a)
Copy the reference and let the destination increment the counter
•
b)
Problems?
•
What if P1 deletes its reference before P2 increments the counter
Signal the copy first to the server
•
Problems?
•
Overheads, Coupling (what if P2 fails?)
EECE 411: Design of Distributed Software Applications
Advanced Reference Counting
Weighted Reference Counting
a)
b)
Initial assignment of weights (lifes)
New weight (life) assignment when creating a new
reference.
EECE 411: Design of Distributed Software Applications
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
EECE 411: Design of Distributed Software Applications
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




Copying a remote reference


(P1 attempts to pass to P2 a remote reference to O)
Advantages:

add/delete are idempotent



P sends its identification to O skeleton
O acknowledges and stores P identity
P creates the proxy
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)
EECE 411: Design of Distributed Software Applications
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?
EECE 411: Design of Distributed Software Applications
Summary so far

Push vs. pull design



Callbacks
Distributed garbage collection
 Solutions much more complex than for nondistributed 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