Transcript Chapter 5 revision

Teaching material
based on Distributed
Systems: Concepts
and Design, Edition 3,
Addison-Wesley 2001.
Copyright © George
Coulouris, Jean Dollimore,
Tim Kindberg 2001
email: [email protected]
This material is made
available for private study
and for direct use by
individual teachers.
It may not be included in any
product or employed in any
service without the written
permission of the authors.
Viewing: These slides
must be viewed in
slide show mode.
Distributed Systems Course
Topics in distributed objects
Ideas needed to understand CORBA
Revise
1.4 heterogeneity
4.3 external data representation
5.4 distributed objects & RMI
5.5 Java RMI case study
Heterogeneity
 Applies to all of the following:
– networks
 Internet protocols mask the differences between networks
– computer hardware
 e.g. data types such as integers can be represented differently
– operating systems
 e.g. the API to IP differs from one OS to another
– programming languages
 data structures (arrays, records) can be represented differently
– implementations by different developers
 they need agreed standards so as to be able to interwork
 Middleware provides a programming abstraction and
masks the heterogeneity of networks etc.
•
2
Middleware programming models
 Distributed objects and remote object invocation is
the model explained in Chapter 5
– illustrated by Java RMI
 CORBA is in Chapter 17. We will study it shortly.
– it provides remote object invocation between a client program written
in one language and a server program written in another language
– our book uses Java CORBA to illustrate the use of CORBA
– another language commonly used in CORBA is C++
 Other programming models
– remote event notification
– remote SQL access
– distributed transaction processing
•
3
External data representation
 This was presented in Chapter 4. It masks the differences
due to different computer hardware.
 CORBA CDR
– only defined in CORBA 2.0 in 1998, before that, each implementation of
CORBA had an external data representation, but they could not generally
work with one another. That is:
 the heterogeneity of hardware was masked
 but not the heterogeneity due to different programmers (until CORBA 2)
– CORBA CDR represents simple and constructed data types (sequence, string,
array, struct, enum and union)
 note that it does not deal with objects
– it requires an IDL specification of data to be serialised
 Java object serialisation
– represents both objects and primitive data values
– it uses reflection to serialise and deserialise objects– it does not need an IDL
specification of the objects
•
4
CORBA IDL example
struct Person {
Figure 5.2
string name;
CORBA has a struct string place;
remote interface
long year;
};
interface PersonList {
remote interface defines
readonly attribute string listname;
methods for RMI
void addPerson(in Person p) ;
void getPerson(in string name, out Person p);
long number();
};
parameters are in, out or inout
 Remote interface:
– specifies the methods of an object available for remote invocation
– an interface definition language (or IDL) is used to specify remote interfaces.
E.g. the above in CORBA IDL.
– Java RMI would have a class for Person, but CORBA has a struct
•
5
Distributed object model
Figure 5.3
local
remote
invocation
A
B
C
local E
invocation
invocation
local
invocation
D
remote
invocation
F
 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
•
6
Invocation semantics
 Local invocations are executed exactly once
 Remote invocations cannot achieve this. Why not?
– the Request-reply protocol can apply fault-tolerance measures
Figure 5.5
Fault tolerance measures
Retransmit request
message
Duplicate
filtering
Invocation
semantics
Re-execute procedure
or retransmit reply
No
Not applicable
Not applicable
Yes
No
Re-execute procedure
At-least-once
Yes
Yes
Retransmit reply
At-most-once
7
Maybe
•
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)
•
8
The architecture of remote method invocation
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).
9
Remote reference
module
RMI software - between
application level objects
and communication and
remote reference modules
•
Representation of a remote object reference
32 bits
32 bits
Internet address
port number
32 bits
time
32 bits
object number
Figure 4.10
interface of
remote object
 a remote object reference must be unique in the distributed system and
over time. It should not be reused after the object is deleted. Why not?
 the first two fields locate the object unless migration or re-activation in
a new process can happen
 the fourth field identifies the object within the process
 its interface tells the receiver what methods it has (e.g. class Method)
 a remote object reference is created by a remote reference module
when a reference is passed as argument or result to another process
– it will be stored in the corresponding proxy
– it will be passed in request messages to identify the remote object whose
method is to be invoked
•
10
Shared whiteboard example (p 194)
 In the RMI and CORBA case studies, we use a
shared whiteboard as an example
– this is a distributed program that allows a group of users to share a
common view of a drawing surface containing graphical objects, each
of which has been drawn by one of the users.
 The server maintains the current state of a drawing
and it provides operations for clients to:
– add a shape, retrieve a shape or retrieve all the shapes,
– retrieve its version number or the version number of a shape
•
11
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;
•
}
12
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());}
}
}
13
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 { ... }
14
}
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());}
}
}
15
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.
•
16