1. Notes from “Distributed Systems Concepts and Design” by Coulouris
Chapter 5 and Chapter 17
Notes from “Distributed Systems Concepts and Design” by Coulouris

2. Middleware layers Applications RMI, RPC and events Middleware
Request reply protocol
External data representation
Operating System
RMI, RPC and events

3. IDL (Interface Definition Language)
An IDL provides a notation for defining interfaces in which each of the parameters
of a method may be described as for input
or output in addition to having its type
specified. (Chapter 5)

4. IDL (Interface Definition Language)
An IDL is needed when languages differ
Example IDL’s include:
-Corba IDL (Object-oriented syntax)
-OSF’s Distributed Computing Environment DCE (C
like syntax)
-DCOM IDL based on OSF’s DCE and used
by Microsoft’s DCOM
-Sun XDR (An IDL for RPC)
-Web Services WSDL

5. CORBA IDL example How does this compare with WSDL?
// In file Person.idl
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(); };
How does this compare with WSDL?

6. File interface in Sun XDR (Originally External Data Representation but now an IDL) for RPC
const MAX = 1000;
typedef int FileIdentifier;
typedef int FilePointer;
typedef int Length;
struct Data {
int length;
char buffer[MAX]; };
struct writeargs {
FileIdentifier f;
FilePointer position;
Data data;
struct readargs {
FileIdentifier f;
FilePointer position;
Length length; };
program FILEREADWRITE {
version VERSION {
void WRITE(writeargs)=1; // procedure
Data READ(readargs)=2; // numbers
}=2; // version number
} = 9999; // program number
// numbers passed in request message
// rpcgen is the interface compiler

7. Remote and local method invocationsB C D E F

8. A remote object and its remote interface
Data
implementation
object {
of methods

9. RMI Design Issues RMI Invocation Semantics
Local calls have Exactly Once semantics.
Remote calls have Maybe, At Least Once
or at Most Once semantics.
Level of Transparency
Remote calls should have a syntax
that is close to local calls.
It should probably be clear to the
programmer that a remote call is being
made.

10. Invocation semantics Fault tolerance measures Invocation semantics
Retransmit request
message
Duplicate
filtering
Re-execute procedure
or retransmit reply No
Yes
Not applicable
Retransmit reply (history)
At-most-once
At-least-once
Maybe
Duplicate filtering means removing duplicate request at the server.

11. Invocation Semantics Maybe semantics is useful only for
applications in which occasional failed
invocations are acceptable.
At-Least-Once semantics is appropriate
for idempotent operations.
At-Most-Once semantics is the norm.

12. Typical modules found in remote method invocation systems
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

13. The communication module in remote method invocation
Coordinate to provide a specified invocation semantics.
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

14. The role of remote reference module in remote method invocation
The remote reference module holds a table that records the correspondence
between local object references in that process and remote object references
(which are system wide).
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

15. The role of proxies in remote method invocation
The proxy makes the RMI transparent to the caller. It marshals and unmarshals
Parameters. There is one proxy for each remote object.
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

16. Dispatchers and skeletons in RMI
The server has one dispatcher and skeleton for each class representing a
remote object. A request message with a methodID is passed from the communication
module. The dispatcher calls the method in the skeleton passing the request
message. The skeleton implements the remote object’s interface in much the
same way that a proxy does. The remote reference module may be asked for the
local location associated with the remote reference.
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

17. Binders used in RMI Java uses the rmiregistry CORBA uses the
CORBA Naming Service
Binders allow an object to be named and registered.
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

18. Events and Notifications
Examples of the local event model
-- a keystroke causes an interrupt
handler to execute storing a key
character in the keyboard buffer
-- a mouse click causes an interrupt
handler to call
a registered listener to handle the mouse
event

19. Distributed Event Based Systems
Suppose the whiteboard server is willing to make calls to all registered clients when the drawing is changed by any one client
Clients may subscribe to this service (register interest)
The whiteboard server publishes the events that it will make available to clients
This is the publish-subscribe paradigm

20. Two Characteristics of Distributed Event Based Systems
(1) Heterogeneous
-- event generators publish the types of
events they offer
-- other objects subscribe and provide
callable methods
-- components that were not designed
to work together may interoperate

21. Two Characteristics of Distributed Event Based Systems
(2) Asynchronous
-- Publishers and subscribers are
decoupled
-- notifications of events are sent
asynchronously to all subscribers

22. Dealing room system Dealer’s computer Information provider Dealer
External
source
Notification

23. Architecture for distributed event notification
subscriber
observer
object of interest
Event service 3. 1. 2.
notification

24. Chapter 17 Coulouris text
CORBA
Chapter 17 Coulouris text

25. Today’s Topics CORBA History and goals CORBA RMI CORBA services
The Distributed Whiteboard Revisited

26. CORBA History and Goals
Object Management Group Formed in 1989
Goals:
-- OOP on distributed systems
-- heterogeneous hardware
-- heterogeneous OS
-- different programming languages

27. History and Goals OMG Introduced the Object Request Broker (ORB)
The role of the ORB is to help a client find an object, activate the object if necessary, and call a method on the object.
Common Object Request Broker Architecture (CORBA) agreed to by a group of companies in 1991
CORBA 2.0 specification released in 1996

28. History and Goals
CORBA 2.0 specification defined standards for different implementations of CORBA to communicate with one another
These standards are called the General Inter-ORB protocol (GIOP) and may run over various transports
GIOP over TCP/IP is called the Internet Inter-ORB Protocol

29. CORBA RMI Main components
-- An Interface Definition language (IDL) that promotes
the use of different programming languages, stubs are
generated in the client’s language and skeletons are
generated in the server’s language
-- An architecture
-- GIOP defines an external data representation (CDR) as
well as message formats and message types
-- Message types include request and reply as
well as location requests, errors, and request
cancellations

30. CORBA Services A set of generic services that can be used
for distributed application
-- Naming Service (location by name)
-- Trading Service (location by attribute -
directory service)
-- Event Service
-- Security Service (authentication, ACL’s, auditing, non-
repudiation)
-- Transaction Service (begin, commit, rollback a
series of RMI calls )
-- Persistent Object Service (POS)

31. The Distributed Whiteboard Example in CORBA

32. IDL interfaces Shape and ShapeList
struct Rectangle{ // no class in IDL 1
long width;
long height;
long x;
long y;
} ;
struct GraphicalObject { 2
string type;
Rectangle enclosing;
boolean isFilled; };
interface Shape { 3
long getVersion() ;
GraphicalObject getAllState() ; // returns state of the GraphicalObject };
typedef sequence <Shape, 100> All; // All is a 100 element array 4
interface ShapeList { 5
exception FullException{ }; 6
Shape newShape(in GraphicalObject g) raises (FullException); 7
All allShapes(); // returns sequence of remote object references 8
long getVersion() ; // parameters are in, out, or both
}; // parameters may be primitive, struct or array and
// are passed by value
// parameters whose type is an IDL interface
// is passed by remote reference

33. idltojava Run idltojava on the above interface
The command idlj is found in
j2sdk1.4.2\bin
The Java 2 Platform, Standard Edition, v1.4, provides an Object Request Broker (ORB) runtime component
The JDK documentation states that its Java ORB has not been tested with ORB’s written in other languages
JDK 1.4 provides an Orb class with a pluggable architecture

34. From the JDK Doc
OMG specifies a mapping from IDL to several different programming languages,
including Java, C, C++, Lisp, Python, Smalltalk, COBOL, and Ada.
When mapped, each statement in OMG IDL is translated to a corresponding
statement in the programming language of choice.

35. Java interface ShapeList generated by idltojava from CORBA interface ShapeList
public interface ShapeList extends org.omg.CORBA.Object {
Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException;
Shape[] allShapes();
int getVersion(); }

36. ShapeListServant class from CORBA interface ShapeList
import org.omg.CORBA.*;
class ShapeListServant extends _ShapeListImplBase {
ORB theOrb;
private Shape theList[];
private int version;
private static int n=0;
public ShapeListServant(ORB orb){
theOrb = orb;
// initialize the other instance variables }
public Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException { 1
version++;
Shape s = new ShapeServant( g, version);
if(n >=100) throw new ShapeListPackage.FullException();
theList[n++] = s; 2
theOrb.connect(s);
return s;
public Shape[] allShapes(){ ... }
public int getVersion() { ... }

37. Java class ShapeListServer
import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
import org.omg.CORBA.*;
public class ShapeListServer {
public static void main(String args[]) {
try{
ORB orb = ORB.init(args, null); 1
ShapeListServant shapeRef = new ShapeListServant(orb); 2
orb.connect(shapeRef); 3
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService"); 4
NamingContext ncRef = NamingContextHelper.narrow(objRef);
NameComponent nc = new NameComponent("ShapeList", ""); 5
NameComponent path[] = {nc}; 6
ncRef.rebind(path, shapeRef);
java.lang.Object sync = new java.lang.Object();
synchronized (sync) { sync.wait();}
} catch (Exception e) { ... } }

38. Java client program for CORBA interfaces Shape and ShapeList
import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
import org.omg.CORBA.*;
public class ShapeListClient{
public static void main(String args[]) {
try{
ORB orb = ORB.init(args, null); 1
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
NamingContext ncRef = NamingContextHelper.narrow(objRef);
NameComponent nc = new NameComponent("ShapeList", "");
NameComponent path [] = { nc };
ShapeList shapeListRef =
ShapeListHelper.narrow(ncRef.resolve(path)); 2
Shape[] sList = shapeListRef.allShapes(); 3
GraphicalObject g = sList[0].getAllState(); 4
} catch(org.omg.CORBA.SystemException e) {...} }

39. The main components of the CORBA architecture
client
server
proxy
or dynamic invocation
implementation
repository
object
adapter
ORB
skeleton
or dynamic skeleton
program
interface
Request
Reply
core
for A
Servant A
The implementation repository maintains a registry of known servers,
records which server is currently running, and which port and host it uses.
It starts servers on demand if they are registered with the Implementation Repository.

40. The main components of the CORBA architecture
client
server
proxy
or dynamic invocation
implementation
repository
object
adapter
ORB
skeleton
or dynamic skeleton
program
interface
Request
Reply
core
for A
Servant A
The interface repository is a server that contains information about
CORBA interfaces. A client can use the repository to access all the
metadata necessary to marshal and unmarshal messages.

41. Naming graph in CORBA Naming Service
initial naming context
initial naming context
initial naming context XX
ShapeList B V P C D E T R S Q U