1. 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
This revision lecture took 1 hour 15 minutes to present

2. Applies to all of the following:
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

3. 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

4. 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

5. CORBA IDL example Remote interface: • Figure 5.2 CORBA has a struct
struct Person {
string name;
string place;
long year;
} ;
interface PersonList {
readonly attribute string listname;
void addPerson(in Person p) ;
void getPerson(in string name, out Person p);
long number(); };
Figure 5.2
CORBA has a struct
remote interface
remote interface defines methods for RMI
parameters are in, out or inout
Person structure (type used in arguments in the interface)
in Java RMI it would have been defined as a class
But CORBA may be used by non object-oriented languages e.g. C that don’t have classes.
interface PersonList specifies methods available for RMI
note in and out on parameters
note attribute - really like another method, can get the value from it
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

6. Distributed object model
Figure 5.3
invocation
remote
local A B C D E 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

7. Invocation semantics Local invocations are executed exactly once
Remote invocations cannot achieve this. Why not?
the Request-reply protocol can apply fault-tolerance measures
Fault tolerance measures
Invocation
semantics
Retransmit request
message
Duplicate
filtering
Re-execute procedure
or retransmit reply No
Yes
Not applicable
Retransmit reply
At-most-once
At-least-once
Maybe
Figure 5.5
remind them of request-reply protocol - single request message and reply message. Maybe executed
re-transmit requests until we get a reply - at least once
save replies for re-transmission - at-most-once • 7

8. 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

9. The architecture of remote method invocation
Figure 5.6
object A
object B
skeleton
Request
proxy for B
Reply
Communication
Remote
Remote reference
module
reference module
for B’s class
& dispatcher
remote
client
server
Skeleton - implements methods in remote interface. Unmarshals requests and marshals results. Invokes method in remote object.
Proxy - makes RMI transparent to client. Class implements remote interface. Marshals requests and unmarshals results. Forwards request.
Dispatcher - gets request from communication module and invokes method in skeleton (using methodID in message).
carries out Request-reply protocol
translates between local and remote object references and creates remote object references. Uses remote object table
describe animation - First just shows the figure 5.6
then bring in descriptions of communication and remote reference modules
then text on RMI software
then proxy, skeleton and dispatcher
RMI software - between application level objects and communication and remote reference modules • 9

10. Representation of a remote object reference
Figure 4.10
Internet address
port number
time
object number
interface of
remote object
32 bits
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
mention that uniqueness is formed from first 3 fileds • 10

11. 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

12. Java Remote interfaces Shape and ShapeList
Note the interfaces and arguments
GraphicalObject is a class that implements Serializable.
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;
Figure 5.11
animation brings in the text at the top • 12

13. Java class ShapeListServer with main method
Probably skip this one
import java.rmi.*;
public class ShapeListServer{
public static void main(String args[]){
System.setSecurityManager(new RMISecurityManager());
try{
ShapeList aShapeList = new ShapeListServant(); 1
Naming.rebind("Shape List", aShapeList ); 2
System.out.println("ShapeList server ready");
}catch(Exception e) {
System.out.println("ShapeList server main " + e.getMessage());} }
Figure 5.13 13

14. Java class ShapeListServant implements interface ShapeList
Probably skip this one
import java.rmi.*;
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 { ... }
Figure 5.14 14

15. Java client of ShapeList
Probably skip this one
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") ; 1
Vector sList = aShapeList.allShapes(); 2
} catch(RemoteException e) {System.out.println(e.getMessage());
}catch(Exception e) {System.out.println("Client: " + e.getMessage());} }
Figure 5.15 15

16. 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