1

Chapter 5 and Chapter 17

Notes from “Distributed Systems Concepts and Design” by

Coulouris

2

Middleware layers

Applications

Middlewarelayers Request reply protocol

External data representation

Operating System

RMI, RPC and events

3

IDL (Interface Definition Language)

• Definition:

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

// In file Person.idlstruct 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; // procedureData 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 invocations

invocation invocationremote

invocationremote

locallocal

local

invocation

invocationA B

C

D

E

F

8

A remote object and its remote interface

interfaceremote

m1m2m3

m4m5m6

Data

implementation

remoteobject

{ 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

Yes

Not applicable

No

Yes

Not applicable

Re-execute procedure

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 Bskeleton

Requestproxy for B

Reply

CommunicationRemote Remote referenceCommunication

module modulereference module module

for B’s class& dispatcher

remoteclient server

13

The communication module in remote method invocation

object A object Bskeleton

Requestproxy for B

Reply

CommunicationRemote Remote referenceCommunication

module modulereference module module

for B’s class& dispatcher

remoteclient server

Coordinate to provide a specified invocation semantics.

14

The role of remote reference module in remote method invocation

object A object Bskeleton

Requestproxy for B

Reply

CommunicationRemote Remote referenceCommunication

module modulereference module module

for B’s class& dispatcher

remoteclient server

The remote reference module holds a table that records the correspondencebetween local object references in that process and remote object references(which are system wide).

15

The role of proxies in remote method invocation

object A object Bskeleton

Requestproxy for B

Reply

CommunicationRemote Remote referenceCommunication

module modulereference module module

for B’s class& dispatcher

remoteclient server

The proxy makes the RMI transparent to the caller. It marshals and unmarshalsParameters. There is one proxy for each remote object.

16

Dispatchers and skeletons in RMI

object A object Bskeleton

Requestproxy for B

Reply

CommunicationRemote Remote referenceCommunication

module modulereference module module

for B’s class& dispatcher

remoteclient server

The server has one dispatcher and skeleton for each class representing a remote object. A request message with a methodID is passed from the communicationmodule. The dispatcher calls the method in the skeleton passing the request message. The skeleton implements the remote object’s interface in much thesame way that a proxy does. The remote reference module may be asked for thelocal location associated with the remote reference.

17

Binders used in RMI

object A object Bskeleton

Requestproxy for B

Reply

CommunicationRemote Remote referenceCommunication

module modulereference module module

for B’s class& dispatcher

remoteclient server

Java uses the rmiregistry

CORBA uses the CORBA Naming Service

Binders allow an object to be named and registered.

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

Informationprovider

Dealer

Externalsource

Externalsource

Informationprovider

Dealer

Dealer

Dealer

Notification

Notification

Notification

Notification

NotificationNotification

Notification

Notification

Dealer’s computer

Dealer’s computerDealer’s computer

NotificationNotification

23

Architecture for distributed event notification

subscriberobserverobject of interest

Event service

object of interest

object of interest observer

subscriber

subscriber

3.

1.

2. notification

notification

notification

notification

24

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 ShapeListstruct Rectangle{ // no class in IDL

1long width; long height;long x;long y;

} ;

struct GraphicalObject {2string type; Rectangle enclosing; boolean isFilled;

};

interface Shape { 3long getVersion() ;GraphicalObject getAllState() ; // returns state of the GraphicalObject

};

typedef sequence <Shape, 100> All; // All is a 100 element array 4interface ShapeList { 5

exception FullException{ }; 6Shape newShape(in GraphicalObject g) raises (FullException); 7All allShapes(); // returns sequence of remote object references 8long 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

ShapeListpublic interface ShapeList extends org.omg.CORBA.Object {

Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException;Shape[] allShapes();int getVersion();

}

36

ShapeListServant class from CORBA interface ShapeListimport 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 ShapeListServerimport 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", ""); 5NameComponent path[] = {nc}; 6ncRef.rebind(path, shapeRef); 7

java.lang.Object sync = new java.lang.Object();synchronized (sync) { sync.wait();}

} catch (Exception e) { ... }}

}

38

Java client program for CORBA interfaces Shape and ShapeListimport 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

ORBORB

skeleton

or dynamic skeleton

client program

interface repository

Request

Replycorecore 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

ORBORB

skeleton

or dynamic skeleton

client program

interface repository

Request

Replycorecore 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

ShapeList

CD E

B

initial naming context

P

R S T

V

Q U

initial naming context

XX