Transcript Distributed Objects and Remote Invocation - Ar

Distributed Objects and Remote Invocation – 5.1 Introduction
 Foci:
– Communication among distributed objects via RMI
 Recipients of remote invocations are remote objects, which implement
remote interfaces for communication
– Reliability
 Either one or both the invoker and invoked can fail, and status of
communication is supported by the interface (e.g., notification on failures,
reply generation, parameter processing – marshalling/unmarshalling)
– Local invocations target local objects, and remote invocations target
remote objects
– Distributed even-based systems - ‘subscription’ to events as they
occur at remote sites of interest; and receipt of ‘notification’ therefrom
 Subscription/notification paradigm supports heterogeneity and asynchrony
(e.g., the Jini distributed event-driven specification)
1
Distributed Objects and Remote Invocation – 5.1 Introduction
 Programming models for distributed programs/applications
– RPC – client programs call procedures in server programs, running in
separate and remote computers (e.g., Unix RPC)
– RMI – extensions of object-oriented programming models to allow a local
method (of a local object) to make a remote invocation of objects in a remote
process (e.g., Java RMI)
– EBP (event-based programming) model – allows objects anywhere to receive
notification of events that occur at other objects of which interests have been
registered (e.g., Jini EBP)
 Chapter 5 – focus on RMI and EBP paradigms
– Issues
 Distributed object communication
 Design and implementation of RMI and RPC
 EBP – design and implementation
2
Distributed Objects and Remote Invocation – 5.1 Introduction
 Middleware
– A suite of API software that uses underlying processes and
communication (message passing) protocols to provide its abstract
protocol – simple RMI request-reply protocol
– The middleware provides location transparency, protocol abstraction,
OS, and hardware independence, and multi-language support
3
Distributed Objects and Remote Invocation – 5.1 Introduction
 Middleware
– Location transparency: RPC – client calls appear to be local and
remote procedure could be on any remote server; RMI remote objects’
location is transparent; and in EBP models sources of object
event/notification is transparent
– Protocol transparency: the middleware request-reply protocol can be
built on top of lower-level TCP or UDP
– Hardware transparency: Issues with different data representations,
conversions, and instruction set are transparent
– OS: all three paradigms could run on top of any OS platform
4
Distributed Objects and Remote Invocation – 5.1 Introduction
 Remote Object Interfaces
– Interfaces hide the details of modules providing the service; and access to
module variables is only indirectly via ‘getter’ and ‘setter’ methods / mechanisms
associated with the interfaces
 (e.g., call by value/reference for local calls through pointers vs. input, output, and inout
paradigms in rmi/rpc through message-data and objects)
– An interface is a set of language facilities (syntax/semantics) or notation for
mapping input/output parameters in a remote invocation/call onto native normal
handling of parameters
– Such API’s allow uniformity of both local and remote invocation (same syntax and
denotational semantics)
– IDL: Provide a ‘generic’ template of interfaces for objects in different languages to
perform remote invocation among each other
 E.g., CORBA IDL (Fig 5.2), Sun XDR for RPC, Jave RMI, OSF DCE for RPC in C
5
Distributed Objects and Remote Invocation – 5.2 Communication
 By means of RMI:
– The object model
– Distributed objects (object-based distributed systems)
– The distributed object model (extensions of the basic object model for
distributed object implementation)
– The design issues (of RMI) (local once-or-nothing invocation semantics vs.
remote invocation semantics – similarities or differences)
– The implementation issues (mapping the middleware to lower-layer facilities)
– Distributed garbage collection issues (an application – algorithmic)
6
Distributed Objects and Remote Invocation – 5.2 Communication
 The object model
– Objects (in classes) encapsulate methods and data variables, with some
variables being directly accessible; and communication via passing arguments
and receiving results from (locally) invoked objects
– Object references: objects or variables holding instances of objects are
accessed via references. Accessing target/receiver objects requires –
reference.methodname(args); and references can be passed as args, too.
– Interfaces: the signature of a set of object methods – arg type, return values,
and exceptions. Objects providing interfaces typically offer ‘internal’
implementations of methods of the interfaces. E.g., a class may implement
several ‘interfaces,’ and an interface may be implemented by any class
– Actions: effect of method invocation – may affect receiver/target or cause
chain reaction to complete, including results and exception propagation
– Exceptions: For clarity and cleanness of code, object methods lists exception
conditions that can be thrown and handlers/blocks-of-code written to
handle/catch the exceptions as they occur
– Garbage collection: reclaiming freed object spaces – Java (automatic), C++
(user supplied)
7
Distributed Objects and Remote Invocation – 5.2 Communication
 Distributed objects
– State of an object: current values of its variables
– State of an object (in OO context): depends of how the objects are partitioned
or distributed in the program space and the programming model
– CS: objects reside with client and server processes or computers
– RMI: method invocations and associated messages are exchanged by c/s
depending on where the objects reside
– When objects are replicated for performance and fault-tolerance, or migrated
for performance and availability, objects are thus distributed
– Distributing objects require ‘encapsulation’ for effective, secure, protected
object state (All data are accessed directly by their respective methods, and
requires authorization.)
– Concurrent access to distributed objects is protected (due to encapsulation,
and use of, e.g., condition variables for synchronization)
– Heterogeneity (of data types) is supported via interface-methods
8
Distributed Objects and Remote Invocation – 5.2 Communication
 The distributed object model

extensions to the basic object model – supporting both local and remote method
invocation of objects (with transparency) in processes. Some objects can effect only
local invocation, and others remote invocation, and others can have both

RMI: invocations between objects in different processes (either on same or different
computers) is remote. Invocations within the same process are local

each process contains objects, some of which can receive remote invocations, others
only local invocations

those that can receive remote invocations are called remote objects

objects need to know the remote object reference of an object in another process in
order to invoke its methods. How do they get it?

the remote interface specifies which methods can be invoked remotely
9
Distributed Objects and Remote Invocation – 5.2 Communication
Figure 5.3
local
remote
invocation
A
B
C
local E
invocation
invocation
local
invocation
D
remote
invocation
F
– Objects receiving remote invocations (service objects) are remote
objects, e.g., B and F
– Object references are required for invocation, e.g., C must have E’s
reference or B must have A’s reference
– B and F must have remote interfaces (of their accessible methods)
10
Distributed Objects and Remote Invocation – 5.2 Communication
 Remote object references
– An unique identifier of a remote object, used throughout a distributed system
– The remote object reference (including the ‘interface’ list of methods) can be
passed as arguments or results in rmi
 Remote interfaces
– Remote objects have a class that implement remote methods (as public).
– In Java, a remote interface class extends the Remote interface
– Local objects can access methods in an interface plus methods implemented
by remote objects (Remote interfaces can’t be constructed – no constructors)
11
Distributed Objects and Remote Invocation – 5.2 Communication
 Actions in distributed object systems
– Local activations plus remote invocations that could be chained across different
processes/computers. Remote invocation activate the RMI interface using the remote
object reference (identifier)
– Example of chaining: In Figure 5.3 Object A received remote object reference of object F
from object B
 Distributed garbage collection
– Achieved by cooperation between local (language-specific) collectors and a designated
module that keeps track of object reference-counting (See details and examples in 5.2.6,
using an algorithm based on pairwise request-reply comm with at-most-once invocation
semantics between the reference modules in the processes using proxies.)
 Exceptions
– Possible problems: remote process is busy, dead, suspended to reply, or lost reply; which
will require timeout-retry in an exception handler implemented by the invoker/client
– Usually, there are standard exceptions which can be raised plus others users implement
12
Distributed Objects and Remote Invocation – 5.2 Communication
 Design Issues of RMI
– Local invocations have at-most-once or exactly-once semantics
– Distributed RMI, there alternative semantics are:
 Retry request message – retransmit until reply is received or on
server failure – at-least-once semantics
 Duplicate message filtering – discard duplicates at server (using
seq #s or ReqID)
 Buffer result messages at server for retransmission – avoids redo
of requests (even for idempotent ops) – at-most-once semantics
13
Distributed Objects and Remote Invocation – 5.2 Communication
 Invocation semantics: failure model
 Maybe, At-least-once and At-most-once can suffer from crash failures
when the server containing the remote object fails.
 Maybe - if no reply, the client does not know if method was executed or
not
– omission failures if the invocation or result message is lost
 At-least-once - the client gets a result (and the method was executed at
least once) or an exception (no result)
– arbitrary failures. If the invocation message is retransmitted, the remote object may
execute the method more than once, possibly causing wrong values to be stored or
returned.
– if idempotent operations are used, arbitrary failures will not occur
 At-most-once - the client gets a result (and the method was executed
exactly once) or an exception (instead of a result, in which case, the
method was executed once or not at all)
14
RMI Implementation: The architecture of remote method
invocation (with transparency)
Figure 5.6
server
client
object A proxy for B
skeleton
& dispatcher
for B’s class
Request
remote
object B
Reply
Communication
Remote
reference module
module
Communication
module
Proxy - makes RMI transparent to client.
implements
carriesClass
out Requestremote interface. Marshals requests
andprotocol
unmarshals
reply
results. Forwards request.
translates
local
and remote
objectinterface.
Skeleton - between
implements
methods
in remote
references
creates
remote
object
Unmarshals
requests
and
marshals
results. Invokes
Dispatcher
- and
gets
request
from
communication
module and
references.
Uses
remote
methodmethod
in remote
object. object
invokes
in skeleton
(usingtable
methodID in message).
15
Remote reference
module
RMI software - between
application level objects
and communication and
remote reference modules
•
Distributed Objects and Remote Invocation – 5.3 RPC
• RPC
• Similar to RMI but calls are made to remote ‘procedures’ and can have
chain-reaction effect
• Server process defines the callable procedures in its service interface, have
at-most-once or at-least-once invocation semantics
• Implemented using request-reply protocol (without ROR)
• There is one stub procedure for each procedure in the interface (like RMI
proxy – marshalls procedure id and arguments into message, and
unmarshalls results on return)
• Server has dispatcher (like RMI) with one server stub procedure and its
service procedure for each procedure in the interface
• Server stub procedure (like RMI skeleton method) – unmarshalls
arguments in calls, calls corresponding procedure, and marshalls results in a
reply message
16
Distributed Objects and Remote Invocation – 5.3 RPC
17
Distributed Objects and Remote Invocation – 5.4 Events &
Notification
18
Distributed Objects and Remote Invocation – 5.4 Events &
Notification
19
Java Remote interfaces Shape and ShapeList
• Note the interfaces and arguments
• GraphicalObject is a class that implements Serializable.
Figure 5.11
import java.rmi.*;
import java.util.Vector;
public interface Shape extends Remote {
int getVersion() throws RemoteException;
GraphicalObject getAllState() throws RemoteException;
}
public interface ShapeList extends Remote {
Shape newShape(GraphicalObject g) throws RemoteException;
Vector allShapes() throws RemoteException;
int getVersion() throws RemoteException;
}
20
Java class ShapeListServer with main method
 Probably skip this one
import java.rmi.*;
Figure 5.13
public class ShapeListServer{
public static void main(String args[]){
System.setSecurityManager(new RMISecurityManager());
try{
ShapeList aShapeList = new ShapeListServant();
Naming.rebind("Shape List", aShapeList );
System.out.println("ShapeList server ready");
}catch(Exception e) {
System.out.println("ShapeList server main " + e.getMessage());}
}
}
21
1
2
Java class ShapeListServant implements interface
ShapeList
 Probably skip this one
import java.rmi.*;
Figure 5.14
import java.rmi.server.UnicastRemoteObject;
import java.util.Vector;
public class ShapeListServant extends UnicastRemoteObject implements ShapeList {
private Vector theList;
// contains the list of Shapes
1
private int version;
public ShapeListServant()throws RemoteException{...}
public Shape newShape(GraphicalObject g) throws RemoteException {
2
version++;
Shape s = new ShapeServant( g, version);
3
theList.addElement(s);
return s;
}
public Vector allShapes()throws RemoteException{...}
public int getVersion() throws RemoteException { ... }
22
}
Java client of ShapeList
 Probably skip this one
Figure 5.15
import java.rmi.*;
import java.rmi.server.*;
import java.util.Vector;
public class ShapeListClient{
public static void main(String args[]){
System.setSecurityManager(new RMISecurityManager());
ShapeList aShapeList = null;
try{
aShapeList = (ShapeList) Naming.lookup("//bruno.ShapeList") ;
Vector sList = aShapeList.allShapes();
} catch(RemoteException e) {System.out.println(e.getMessage());
}catch(Exception e) {System.out.println("Client: " + e.getMessage());}
}
}
23
1
2
Summary
 Heterogeneity is an important challenge to designers :
– Distributed systems must be constructed from a variety of different networks,
operating systems, computer hardware and programming languages.
 The Internet communication protocols mask the difference in networks
and middleware can deal with the other differences.
 External data representation and marshalling
– CORBA marshals data for use by recipients that have prior knowledge of the
types of its components. It uses an IDL specification of the data types
– Java serializes data to include information about the types of its contents,
allowing the recipient to reconstruct it. It uses reflection to do this.
 RMI
– each object has a (global) remote object reference and a remote interface that
specifies which of its operations can be invoked remotely.
– local method invocations provide exactly-once semantics; the best RMI can
guarantee is at-most-once
– Middleware components (proxies, skeletons and dispatchers) hide details of
marshalling, message passing and object location from programmers.
24