October 2005Distributed systems: coordination models and languages 1 Distributed Systems:...

October 2005 Distributed systems: coordination models and languages

1

Distributed Systems:

Coordination

models and languages


2

Overview of chapters

• Introduction

• Coordination models and languages– Ch 4: Interprocess communication

– Ch 5: Distributed objects and remote invocation

– Ch 20: Corba Case study

• General services

• Distributed algorithms

• Shared data

• Building distributed services


3

Introduction • Communication

– data representation

• Synchronization– how express cooperation?

Data transfer

Synchronization


4

This chapter: overview

• Data representation

• Message passing

• Remote procedure calls

• Object request brokers

• Generative communication

• Event Systems


5


Applications, services

Middlewarelayers

request-reply protocol

marshalling and external data representation

UDP and TCP

RMI and RPC


6

Data representation

• Problem

int int

System A

int = 2-complement, 32 bits

System B

int = 1-complement, 40 bits

on the wire: int = ??


7

Data representation (cont.)

• Problem:– program data: typed, structured, object– message data: bit/byte stream– different representations of data in

heterogeneous systems

• mapping to data items in messages:– flattened before transmission– rebuilt on arrival


8


• Conversion: different approaches– agreed form for transmission

• e.g. int = 2-complement, 32 bits

• both partners have full knowledge of transmitted data

• e.g.: Sun XDR, Corba CDR

– full data description transmitted• type, length, value coding on the wire

• interpretation at receiving site possible

• e.g. ASN + BER, Java serialized form

– Conversion to ASCII text• XML


9


• Sun XDR– Fixed representation of primitive & constructed types

– Message: ‘Smith’, ‘London’, 1934

5“Smit”“h___”6“Lond”“on__”1934

Length of string

‘Smith’

Length of string

‘London’

Cardinal

4 bytes


10


• CORBA CDR– Fixed representation of primitive & constructed types

• int: little- or big-endian: representation of sender

• Value of size n is placed at relative position that is a multiple of n

Type Representation

sequence length (unsigned long) followed by elements in orderstring length (unsigned long) followed by characters in order (can also

can have wide characters)array array elements in order (no length specified because it is fixed)struct in the order of declaration of the componentsenumerated unsigned long (the values are specified by the order declared)union type tag followed by the selected member


11


• CORBA CDR

The flattened form represents a Person struct with value: {‘Smith’, ‘London’, 1934}

0–34–78–1112–15

16–1920-2324–27

5"Smit""h___" 6"Lond""on__"1934

index in sequence of bytes 4 bytes

notes on representation

length of string

‘Smith’

length of string‘London’

unsigned long

Struct Person{ string name; string place; unsigned long year;};


12


• ASN.1: abstract syntax notation– application syntax

• type identifiers ( 4 classes)

• standard types

• constructors: sequence, sequenceof, set, setof

– encoding: TLV• Type: defines ASN.1 type

• Length

• Value


13


• Java: supports transfer of objects and primitive data values

Public class Person implements Serializable{

private String name;

private String place;

private int year;

public Person(String aName, String aPlace, int aYear){

…}

…

}


14


• Java serialized form– Handles: references to objects– Primitive types: portable binary format

The true serialized form contains additional type markers; h0 and h1 are handles

Serialized values

Person

3

1934

8-byte version number

int year

5 Smith

java.lang.Stringname:

6 London

h0

java.lang.Stringplace:

h1

Explanation

class name, version number

number, type and name of instance variables

values of instance variables

Person p = new Person(“Smith”, “London”, 1934);


15


• XML– Markup language defined by World Wide Web

consortium

– Data items tagged with ‘markup’ strings

– Users can define their own tags

<person id=‘123456789”>

<name>Smith</name>

<place>London</place>

<year>1934</year>

<…>

</person>


16


• Definitions:– marshalling = assembling a collection of data

items into a form suitable for transmission– unmarshalling = disassembling a message on

arrival to produce the equivalent collection of data items

• operations can be generated from specification


17



• Message passing




• Event Systems


18

Message passing

• Basic functionality– Procedure Send

(p: PortId; m: Message);

– Procedure Receive(p: PortId; VAR m: Message);


19

Message passing (cont.)

• Semantics:synchronous <> asynchronous communication

– synchronous = blocking• send: wait for corresponding receive

• receive: wait for message arrival

– asynchronous = no waiting for completion• send: no wait for message arrival

• receive: announce willingness to acceptor check for message arrival


20


• Semantics: synchronous <> asynchronous

type BlockingSend

BlockingReceive

LanguageSystem

Syn Yes Yes occam

Syn Yes No -

Asyn No Yes MachChorus

Asyn No No Charlotte


21


• Semantics: synchronous <> asynchronous Example: Occam style

Sender:

….. Send(p, m); {message is accepted!!!} …..

Receiver:

…. Receive(p, b); {sender after send } ….

Communication Synchronisation point

b := m


22



Send (p, m)

m?b

Receive(p, b)


23


• Semantics: synchronous <> asynchronous Example: Mach style

Sender:

….. send(….); {message is in buffer!!! arrival??}

Receiver:

…. receive(….); {message available } ….

Communication NO synchronisation point


24



Port p

Send (p, m)


25



Send(p, m)

Port p

receive(p,b)


26


• Semantics: message destinations– message destination = communication identifier

• preference for location independent identifiers

– types of message destination:

• process

• port

• mailbox


27


• Semantics: message destinationsprocess

Send (p, m)

Process p


28


• Semantics: message destinationsport

Send (p, m)

port p

port q


29


• Semantics: message destinationsmailbox

Send (p, m)

mailbox p

mailbox q


30


• Semantics: message destinations– types of message destination:

• process:– single entry point per process for all messages

• port– one receiver, many senders

– may have a message queue

– many ports per process

• mailbox– may have many receivers

– message queue


31


• Semantics: reliability

– possible failures• Corrupted messages

• Duplicate messages

• Omission: loss of messages

• Messages out of order

• Receiver process failure

– Reliable communication• Delivered uncorrupted, in order, without duplicates

• Despite a reasonable number of packets dropped or lost

• Perfectly reliable communication can not often be guaranteed

Communication failure


32

• How to implement reliable communication:– Avoiding corruption

• Include checksum in message

– Avoids order mistakes and duplicates • Include a message number which identifies the message

– Avoiding omission• Sender stores message in buffer, sends it and sets a time-out

• Receiver replies with acknowledgement

• Sender retransmits messages after timeout



33


• Semantics: reliability

– sender of message gets no reply?

no distinction between• process failure

• communication failure


34


• Case study: UDP/TCP– Sockets <> ports

• Socket bound to (TCP) port + Internet address

message

agreed portany port socketsocket

Internet address = 138.37.88.249Internet address = 138.37.94.248

other ports

client server


35


• Case study UDP– Messages:

• Restricted packet size: < 216 , < 213 (8Kbytes), truncation• No conversion: bit transmission

– Blocking:• Non-blocking send• Blocking receive

– Timeouts: user can set timeout on receive operation– Receive from any: receive returns port + Internet address

• But sockets can be bound to remote (IP address+port)

– Unreliable message service• lost, out of order, duplicates• no message corruption: checksum


36


• Case study UDP: Java API– Class InetAddress

• getByName(string) (underlying name server!)

– Class DatagramPacket• (bufferlength, buffer, InetAddress, PortID)

– Class DatagramSocket• Send(DatagramPacket)

• Receive(DatagramPacket)

• Close()


37


• Case study UDP: example in Java– UDP client sends a message to the server and

gets a reply (Figure 4.3)

– UDP server repeatedly receives a request and sends it back to the client (Figure 4.4)


38

4.3 UDP client sends a message to the server and gets a reply

import java.net.*;import java.io.*;public class UDPClient{ public static void main(String args[]){

// args give message contents and server hostnameDatagramSocket aSocket = null; try {

aSocket = new DatagramSocket(); byte [] m = args[0].getBytes();InetAddress aHost = InetAddress.getByName(args[1]);int serverPort = 6789; DatagramPacket request = new DatagramPacket(m, args[0].length(), aHost, serverPort);aSocket.send(request); byte[] buffer = new byte[1000];DatagramPacket reply = new DatagramPacket(buffer, buffer.length);aSocket.receive(reply);System.out.println("Reply: " + new String(reply.getData()));

}catch (SocketException e){System.out.println("Socket: " + e.getMessage()); }catch (IOException e){System.out.println("IO: " + e.getMessage());}}finally {if(aSocket != null) aSocket.close();}

} }


39

import java.net.*;import java.io.*;public class UDPServer{

public static void main(String args[]){ DatagramSocket aSocket = null; try{ aSocket = new DatagramSocket(6789);

byte[] buffer = new byte[1000]; while(true){ DatagramPacket request = new DatagramPacket(buffer, buffer.length); aSocket.receive(request); DatagramPacket reply = new DatagramPacket(request.getData(),

request.getLength(), request.getAddress(), request.getPort()); aSocket.send(reply);}

}catch (SocketException e){System.out.println("Socket: " + e.getMessage()); }catch (IOException e) {System.out.println("IO: " + e.getMessage());}}finally {if(aSocket != null) aSocket.close();}

}}

4.4 UDP server repeatedly receives a request and sends it back to the client


40


• Case study TCP – Stream communication: (<> message passing?)

• Connect: create a communication channel through communicating sockets

• Communication: read and write through channel • Close

– Implementation: • TCP handles all communication• Uses buffers at sender and receiver side • No conversion: bit transmission

– Synchronization semantics: • Non-blocking send, except for flow control

(when buffers of sender or receiver are full) • Blocking receive


41


• Case study TCP– Setting up a client server connection:

• Client sends request for communication to Server port• Server accepts client request• Typically, server creates new thread which handles

communication with client– Reliable message service

• Except broken connections– Overhead compared to UDP:

• Buffering• Creating a connection: 2(?) extra messages

– Sending a message, returning an acknowledgement– May create unacceptable overhead if goal is to send a single

message.


42


• Case study TCP: Java API– Class ServerSocket

• Socket Accept()

– Class Socket• getInputStream() • getOutputStream()

– Class DataInputStream • readUTF, … (Universal Transfer Format)

– Class DataOutputStream • writeUTF, …


43


• Case study TCP: example– TCP client makes connection to server, sends

request and receives reply (Figure 4.5)

– TCP server makes a connection for each client and then echoes the client’s request (Figure 4.6)


44

4.5 TCP client makes connection, sends request and receives reply

import java.net.*;import java.io.*;public class TCPClient {

public static void main (String args[]) {// arguments supply message and hostname of destinationSocket s = null; try{ int serverPort = 7896; s = new Socket(args[1], serverPort);

DataInputStream in = new DataInputStream( s.getInputStream());DataOutputStream out =

new DataOutputStream( s.getOutputStream());out.writeUTF(args[0]); // UTF is a string encoding see Sn 4.3String data = in.readUTF(); System.out.println("Received: "+ data) ;

}catch (UnknownHostException e){System.out.println("Sock:"+e.getMessage());

}catch (EOFException e){System.out.println("EOF:"+e.getMessage()); }catch (IOException e){System.out.println("IO:"+e.getMessage());}

}finally {if(s!=null) try {s.close();}catch (IOException e){System.out.println("close:"+e.getMessage());}} }}


45

4.6 TCP server makes a connection for each client and then echoes the request of the client

import java.net.*;import java.io.*;public class TCPServer { public static void main (String args[]) {

try{int serverPort = 7896; ServerSocket listenSocket = new ServerSocket(serverPort);while(true) {

Socket clientSocket = listenSocket.accept();Connection c = new Connection(clientSocket);

}} catch(IOException e) {System.out.println("Listen :"+e.getMessage());}

}}

// this figure continues on the next slide


46

class Connection extends Thread {DataInputStream in;DataOutputStream out;Socket clientSocket;public Connection (Socket aClientSocket) { try {

clientSocket = aClientSocket;in = new DataInputStream( clientSocket.getInputStream());out =new DataOutputStream( clientSocket.getOutputStream());this.start();

} catch(IOException e) {System.out.println("Connection:"+e.getMessage());}}public void run(){ try { // an echo server

String data = in.readUTF(); out.writeUTF(data);

} catch(EOFException e) {System.out.println("EOF:"+e.getMessage()); } catch(IOException e) {System.out.println("IO:"+e.getMessage());} } finally{ try {clientSocket.close();}catch (IOException e){/*close failed*/}}}

}

4.6 TCP server …


47


• Conclusion: UDP, TCP– general purpose communication protocols – primitive, low level operations:

• Setting up a communication

• No transfer of structured data

– Difficult to use– efficient implementation– building blocks used for more complex

interactions


48


• Conclusion: message passing– primitive, low level operations

– difficult, hard to use

– efficient implementation

– building blocks used for more complex interactions

• From message passing – to Client-server

– to RPC, RMI


49


• Client-server communication

Request

ServerClient

doOperation

(wait)

(continuation)

Replymessage

getRequest

execute

method

messageselect object

sendReply


50


• Client-server messages/operations– Designed to support roles and message

exchanges in typical client-server interactions• Acks redundant (replies are used)

• Connections not necessary

• No flow control

– Basic operations: • Client: doOperation: sends request and returns answer to

application program

• Server: getRequest, sendReply


51


– Reliability measures of TCP are an overkill!!• Acknowledgement of receiver is redundant :

the reply message is an acknowledgement!

• Limited size of data packet transfer

• One time communication

=> Making a connection is overhead

=> No stream needed, no flow control

Use of TCP is (often) an overkill and may cause efficiency problems!

UDP can be used for building more efficient client server communication.

• What about reliability??


52


• Case: Client-server communication: HTTP– Interactions:

• Open connection

• Client sends request

• Server sends reply

• Connection closedNew in HTTP1.1: Persistent connections using TCP

(for multiple requests at same server)

– HTTP methods:• Get(URL) : request for the resource referred to by URL

• Post(URL,data): replace or create resource at URL• ..


53


• Case: Client-server communication: HTTP

• Request message

• Reply message

GET //www.dcs.qmw.ac.uk/index.html HTTP/ 1.1

URL or pathnamemethod HTTP version headers message body

HTTP/1.1 200 OK resource data

HTTP version status code reason headers message body


54

Message Passing: Conclusion

• So far rather low level implementations:– Setting up a connection

– No transfer of structured data!!!

– Concerns for synchronisation and failure model

– No encryption of data

– …

• Higher level Message Passing systems exist!!– MPI, Mach, ..


55



• Message passing




• Event Systems


56

Remote procedure callsOverview

• Basic principles

• Design issues

• Implementation aspects

• Case studies

• Asynchronous RPC


57

Remote procedure calls Basic principles

• View on traditional application:– no OO yet! – application =

main program

+ procedures (functions)

familiar paradigm: procedure call


58

Remote procedure callsBasic principles

• View on traditional application:

Main program

…

….

….

…

….

...

end

Procedure A

Procedure B


59


• View on traditional application:– main program and procedures (functions)– familiar paradigm: procedure call

• approach in distributed systems:– group procedures into servers– main programs become clients– operations on server look like conventional

procedure calls


60


• Basic view on client-server model

Main program

…

….

….

…

….

...

end

client server

RPC middleware

Procedure A

Procedure B


61


• RPC technology: client side

Main program

…

….

….

…

….

...

end

Client stub procedure A

Client stub procedure B


62


• RPC technology: server side

Server stub

…

….

….

…

….

...

end

Procedure A

Procedure B


63


• RPC technology

Server stub

…

….

….

…

….

...

end

Procedure A

Procedure B

Main program

…

….

….

…

….

...

end

Client stub procedure A

Client stub procedure B

Message subsystem


64


• RPC technology

client

Request

Reply

CommunicationCommunication

module module dispatcher

service

client stub

server stubprocedure procedure

client process server process

procedureprogram


65

Remote procedure calls• Application program calls client stub procedure

• Client stub procedure marshalls parameters of call and gives it to communication module in client

• Communication module in client transmits a message with the marshalled RPC

• Communication module in server receives message and gives it to dispatcher

• Dispatcher determines which procedure is called and calls correct servers stub procedure with marshalled data

• Server Stub procedure unmarshalls data and calls the server procedure


66

Remote procedure calls• Server procedure returns an answer to Server Stub

procedure

• Server Stub procedure marshalls the answer and gives it to the communication module at server side

• Communication module at server side transmits the reply in a message

• Communication module at client side gives data to client stub procedure

• Who unmarshalls data and returns the answer to calling program


67

Remote procedure calls

• Primary characteristics:– code in client and server independent of

communication system– familiar paradigm: procedure call

• no message preparation• synchronous interaction• semantics?

– IDL: Interface definition language• independent of language used for client or server• base for generation of stubs


68

Remote procedure calls Design issues

• Classes of RPC systems

• Interface Definition language

• Exception handling

• Semantics of RPC

• Transparency


69


• Classes of RPC systems

– RPC integrated within a particular

programming language

• e.g. Argus (with CLU), Arjuna (C++)

– RPC based on a special IDL

• e.g. Sun RPC, ANSA RPC, OSF/DCE


70


• Interface Definition language

– describes operation signatures

– interface compilers for

• generating client and server stubs

• in different languages (e.g. C, Pascal,…)


71


• Exception handling

– failures cannot be hidden!

• Network <> server failure?

• Client cannot distinguish

– approaches to support failures:

• Language specific

• using return codes of functions

• extension provided by IDL


72


• Semantics of RPC– Maybe

– At-least-once (e.g. Sun RPC)

– At-most-once (e.g. ANSA RPC)

– Exactly-once:• difficult or impossible given failures


73

Remote procedure callsDelivery guarantees RPC semantics

retry request duplicatefiltering

re-execretrans reply

no not applic. not. Maybe

yes no re-exec At-least-once

yes yes retrans reply At-most-once


74


• Transparency– RPC more vulnerable to failure

• possibility of failure should not be hidden

– calling instructions different– no shared memory between caller and callee

programming convenience

vs.

true transparency


75

Remote procedure calls Implementation aspects

• Tasks for interface compiler: generate – client stub procedure– server stub procedure– marshalling and unmarshalling operations for

each argument type– header for server procedure


76


• Binding: linking client to server at execution time

• Binder interfaceProcedure Register (serviceName: String;

serverPort: Port; version: integer);

Procedure Withdraw (…);

Procedure Lookup(serviceName: String; version:…): Port;


77


• Binding:– server will register service at binder– client will lookup the service

• Locating the binder?– well known host address– responsibility of OS– broadcast message by client


78

Remote procedure calls Case studies: Sun RPC

• Sun RPC– designed by Sun for client-server

communication in the Sun NFS network file system

– interface definition language: XDR– at-least-once semantics– local binding service per system: port mapper


79

Remote procedure calls Sun RPC: Interface in XDR

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;

};


80

Remote procedure calls Sun RPC: Interface in XDR

Program FILEREADWRITE {

version VERSION {

void WRITE ( writeargs) = 1;

Data READ (readargs) = 2;

} = 2;

} = 9999;


81

Remote procedure calls Sun RPC: IDL

• Interface definition language– extension of XDR, originally for external data

representation– specifying an interface:

• program and version number

• procedure definitions– procedures are numbered

– input parameters = single (C-)structure

– output parameters = a (C-)structure

• type definitions


82

Remote procedure calls Sun RPC: IDL

• Interface compiler generates:– client stub procedures

– server main procedure, despatcher and stub procedures

– XDR marshalling and unmarshalling

– header file for client and server


83

Remote procedure calls Sun RPC: Client in C

main(…) {CLIENT *clientHandle;char *serverName = “coffee”;readargs a;Data *data;

clientHandle = clnt_create( serverName, FILEREADWRITE, VERSION, “udp”);

if(clientHandle == NULL) { };

a.f = 10; a.position = 100; a.length = 1000;

data = read_2( &a, clientHandle);

…

clnt_destroy ( clientHandle);

}


84

Remote procedure calls Sun RPC: Client program

– Binding:• via local port mapper, so hostname must be

specified

• use clnt_create(…)

– calling stub procedure• stub procedure name: IDLname + underscore +

version number

• arguments: input parameters + client handle

– stub procedure calls clnt_call, at-least-once semantics


85

Remote procedure calls Sun RPC: Server in C

Void *write_2( writeargs *a) {

/* do writing to file */

}

Data *read_2(readargs *a){

static Data result;

result.buffer = … /* do the reading */

result.length = …

return &result;

}

Generated headers


86

Remote procedure calls Sun RPC: server program

• Main– create socket– export service by informing port mapper

• dispatcher– check program and version number, unmarshal– call server procedure– marshal results and transmit reply message


87

Remote procedure calls Sun RPC

• Lower level facilities:– testing tools, such as null RPC– memory management for marshalling– broadcast RPC– batching client calls that require no reply– Authentication

• None• Unix style• Kerberos


88

Remote procedure calls Asynchronous RPC

• Problem: throughput RPC?Process argsmarshalsend

Receiveunmarshalexecute requestmarshalsend

Receiveunmarshalprocess results….

client server

timeIdle time!


89


• Timing:Synchronous RPC Asynchronous RPC


90


• When to use?– Many request, small amount of information,

limited processing: e.g. windows system– parallel requests to several servers

• Additional optimisations:– buffer request at client until …– proceed without waiting when no reply is

required


91


• Extensions:– call streams:

• mix of synchronous and asynchronous calls

• message ordering preserved

• connection oriented

• connection breaks when semantics cannot be guaranteed


92


• Extensions:– Promises:

• allow clients to continue with (other work) and retrieve result of call later

• created at the time of call

• store results of call (object with same type)

• operations:– get, await result

– result available?

• Alternative names: futures, tickets, continuations


93

Remote procedure calls

• Conclusion:– familiar paradigm– has been basic primitive for distributed

programming– limitations

• failures to be handled by clients

• no transaction support

• one-to-one communication


94



• Message passing




• Event Systems


95

Object request brokers

• Basics:

Object request broker =

Objects +

RPC

+ ...


96


• Overview

– distributed object systems

– case study: Java RMI

– case study: OMG Corba


97

ORB: Distributed object systems

• Why objects?– …

• Why distributed objects?– Maps naturally to distributed services– Services are modeled as objects– Functionality emerges by cooperation between

services and clients


98

ORB: Distributed object model

• Local <> remote invocation

invocation invocationremote

invocationremote

locallocal

local

invocation

invocationA B

C

D

E

F


99


• requirements– synchronous invocation semantics

• location transparency: location transparent object references

• access transparency: local & remote object invocations identical

– inheritance– polymorphism


100

ORB: Distributed objects

• a distributed object consists of– an implementation independent service

definition specified by an interface• method signature

• multiple inheritance

– a concrete service implementation • implements one or more interfaces

• provides the concrete implementation


101


• Remote object & its remote interface

interfaceremote

m1m2m3

m4m5m6

Data

implementation

remoteobject

{ of methods


102


• Distributed objects act like normal objects– can be used as parameters and return values– can be invoked (across address space

boundaries)– can be subclassed (inheritance)– are invoked synchronously


103


• But there are exceptions– Invocation semantics

• Java RMI: at most once

• Corba: at most once or maybe (if no result)

– Parameter passing• distributed objects are passed by reference

• normal objects are passed by value

– additional exceptions due to distribution• distribution is not transparent


104

ORB: Object invocations

object A object BskeletonRequestproxy for B

Reply

CommunicationRemote Remote referenceCommunication module modulereference module module

for B’s class& dispatcher

remoteclient server

servant


105

ORB: The object bus

Object Bus

Client Serverfoo()

Client - the invoking application objectServer - the invoked application object


106

ORB: The object bus

Broker

Stub/Proxy Skeleton

Client Serverfoo()

Application

Object Bus


107

ORB: The object bus

• Client - the invoking application object

• Server - the invoked application object

• Stub - reifies the invocation

• Skeleton - dispatches the invocation to the actual object implementation

• Broker - invocation distributor


108

ORB: The object bus

Broker

Stub Skeleton

Client Serverfoo()

Conceptual invocation


109

ORB: The object bus

foo()

Broker

Stub Skeleton

Client Server

Method call


110

ORB: The object bus

foo()

Broker

Stub Skeleton

Client Server

Reified invocation


111

ORB: The object bus

foo()

Broker

Stub Skeleton

Client Server

Reified invocation


112

ORB: The object bus

foo()

Broker

Stub Skeleton

Client Server

Method call


113

ORB: The object bus

foo()

Broker

Stub Skeleton

Client Server

Return value


114

ORB: The object bus

foo()

Broker

Stub Skeleton

Client Server

Reified return value


115

ORB: The object bus

foo()

Broker

Stub Skeleton

Client Server

Reified return value


116

ORB: The object bus

foo()

Broker

Stub Skeleton

Client Server

Return value


117

ORB: advanced topics

• Active objects;– Kept in running process– Ready to execute methods– Waste of resources if no requests

• Passive objects– Not currently active; can be become active– 2 parts:

• Implementation of methods

• State in marshalled form


118

ORB: advanced topics

• Persistent object– Guaranteed to live between activations of

processes• as passive object

• in persistent store

– Strategy for: passive active

• Object migration– Find location using object reference


119


• Overview





120

Java RMI

• JAVA

– Driven by SUN Micro systems

– Platform independent

• JAVA + RMI distribution:

– Remote Method Invocation

Distributed Java applications


121

Java RMI: Architecture

Java Runtime Environment

Stub Skeleton

Client Serverfoo()

implements java.rmi.remote

extends java.rmi.UnicastRemoteObject

generated by rmic


122

Java RMI: Services

• rmiregistry – simple naming service at the server-side– allows remote clients to get a reference to a

server object

• java.rmi.Naming – Naming class – provides methods for storing and obtaining

references to remote objects in the remote object registry


123

Java RMI: Naming Servicevoid rebind (String name, Remote obj)

This method is used by a server to register the identifier of a remote object by name, as shown in Figure 5.13, line 3.

void bind (String name, Remote obj) This method can alternatively be used by a server to register a

remote object by name, but if the name is already bound to a remote object reference an exception is thrown.

void unbind (String name, Remote obj) This method removes a binding.

Remote lookup(String name) This method is used by clients to look up a remote object by name,

as shown in Figure 5.15 line 1. A remote object reference is returned.

String [] list() This method returns an array of Strings containing the names bound

in the registry.


124

Java RMI

• Tools:– rmic - Java RMI Stub Compiler– rmiregistry - Java Remote Object Registry– rmid - Java RMI Activation System Daemon


125

Java RMI: a distributed application

• Step by step – define the server interface

• a remote interface extends the interface java.rmi.Remote

• each method of the interface declares java.rmi.RemoteException in its throws clause, in addition to any application-specific exceptions

– create the object implementation• implement one or more server interfaces


126

Java RMI: a distributed application

• Step by step (cont.)

– compile the Server source• run javac on the java source file

– generate stubs and skeletons• run the rmic compiler on the fully qualified class

name of the server object implementation

– create and compile the Client source• this can be done at any time after the server

interface is defined


127

Java RMI: Remote interfacepackage HelloAppRMI;

interface Hello extends java.rmi.Remote {String sayHello() throws java.rmi.RemoteException;

}


128

Java RMI: Serverpackage HelloAppRMI;

public class HelloServer { public static void main(String args[]) {

try {HelloServant obj = new HelloServant();java.rmi.Naming.rebind("//ryslinge/HelloServer",obj;System.out.println("HelloServer bound in registry");

} catch (Exception e) {System.err.println("Hello err: " +

e.getMessage());}

}}


129

Java RMI: Server (cont.)

class HelloServant extends java.rmi.server.UnicastRemoteObject implements Hello{

public HelloServant() throws java.rmi.RemoteException {

super();}public String sayHello() {

return "\nHello world!!\n";}

}


130

RMI: Clientpackage HelloAppRMI;

public class HelloClient {public static void main(String args[]) {

try { Hello obj = (Hello)java.rmi.Naming.lookup

("//" + "ryslinge" + "/HelloServer"); String hello = obj.sayHello();System.out.println(hello);

} catch (Exception e) { System.err.println("Hello exception: "

+ e.getMessage()); }

}}


131


• Overview





132

OMG CORBA • OMG

– Object Management Group– non-profit organization– sponsored by over 500 organizations

• computer manufacturers, software companies, telecommunications companies, end users

– overall objective: promote the theory and practice of object

technology for the development of distributed computing systems


133

OMG CORBA • OMG (cont.)

– approach to standardization• define requirements

• issue Requests for Proposals

• evaluate revised proposals

• selection

– major result: CORBA


134

OMG CORBA • Common Object Request Broker

Architecture

– Language independent

• Java, C++, C, Smalltalk, Ada, COBOL.

– Platform dependent

• requires an ORB implementation for each new

platform

A homogenous view on a heterogeneous world


135

OMG CORBA • OMA = Object management architecture

= Object model+ reference model

• Object model– encapsulated entities– distinct immutable identity– accessed through well-defined interfaces– implementation and location hidden from clients

• Reference model (see next slide)


136

OMA: Reference model

Common facilitiesApplication objects

Object services

Object Request broker


137


• Object request broker: CORBA– Keep the ORB as simple as

possible– push as much functionality as

possible to other OMA components

Common facilities

Application objects

Object services



138


• Object services– domain-independent services

– used by many distributed programs

– for discovery of other services• naming service

• trading service

– for lifecycle management, security, transactions, ...

Common facilities

Application objects

Object services



139


• Common facilities– horizontal orientation– towards end-user applications– e.g. DDCF Distributed document

Component Facility

• Application objects– not standardised

Common facilities

Application objects

Object services



140

CORBA

• Main features:– ORB core– OMG Interface definition language– Language Mappings– Interface Repository– Stubs and Skeletons– Dynamic Invocation and Dispatch– Object adapters– Inter-ORB protocols


141

CORBA: Architecturesimplified view

foo()

CORBA ORB

Stub Skeleton

Client Server


142

CORBA: architecture

ORB Core

Dyn. Invoc.

IDLStub

ORBIntf

Objectadaptor

DSIIDLSkel

Same for all ORBs

Interface-specificstubs and skeletons

Multiple adaptors possible

ORB-private interface

Client Object Implementation


143

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


144

CORBA: ORB Core

• Task:– deliver requests to objects– return responses

• transparency: ORB hides– object location– object implementation– object execution state– underlying communication mechanisms


145

CORBA: IDL

• Interface Definition Language– language-neutral

• interfaces

• operations• built-in types: short, long, float, boolean, enum,…

• constructed types: struct, union

• template types: string, sequence

• object reference types

– each language has its own IDL mapping


146

CORBA: IDL

module HelloAppCORBA{ interface Hello { string sayHello(); };};

• The Hello.idl file


147

CORBA: IDL to Java mapping

• Mapping Hello.idl from IDL to Java

/* Hello.java as generated by idltojava */package HelloAppCORBA;public interface Hello

extends org.omg.CORBA.Object{

String sayHello();}


148

CORBA: stub/skeleton

foo()

CORBA ORB

Stub Skeleton

Client Server

Static invocation!!


149

CORBA: Dynamic Invocation

• Principle:– Invoke request on any object without having

compile-time knowledge of the object’s interfaces

• Interface repository– gives access to IDL type system– applications can

• can traverse hierarchy of IDL information

• use get_interface on any object


150

CORBA: Dynamic Invocation

• Dynamic invocation– create Request pseudo-object during execution

– invocation• synchronous

• asynchronous– Callback: server calls callback object with result

– Polling: client polls later the valueobject returned by server

• oneway (no result)

• Dynamic skeleton interface– allows for servers without skeletons being compiled

statically into the program


151

CORBA: Inter-ORB Protocols

• Interoperability between different commercial products?

foo()

CORBA ORB

Stub Skeleton

Client Server

System A System B


152


CORBA ORB

Stub

Client

System A

• General Inter-ORB Protocol

Skeleton

Server

System B

CORBA ORBGIOP - IIOP


153


• GIOP: General Inter-ORB Protocol – interoperability between different ORBs

– defines architecture

• standard set of message formats

• transfer syntax

• uses connection-oriented protocol

• IIOP¨: Internet Inter-ORB Protocol

– uses TCP/IP as transport protocol


154


• Conclusion:– extends RPC– allows for distribution of objects – Supports heterogeneity


155

Chapter overview


• Message passing




• Event Systems


156

Generative communication (GC)

• Overview

– goals / motivation

– how?

– the paradigm of GC

– Linda

– typical extensions


157

GC: Goals and Motivation

• basic goals / motivation:– communication paradigm for concurrently

active entities (e.g. processes, ...)– heterogeneous environment

• programming language

• hardware / operating system

• communication media

– support for flexible "open systems"• systems in which entities join and leave

dynamically


158

GC: How ?

• separation– computational aspects– coordination aspects

• uncoupling of concurrent entities no direct communication

calculations

communication


159

GC: the GC paradigm

• a concurrent system– active computational entities

("processes")

– shared data space

– coordination through data exchange• processes drop data into shared spaces

• processes retrieve data from shared spaces– through associative "matching"


160

GC: the GC paradigm

• example "configuration"

WordProcessor LinePrinterPostscriptPrinter

"generate"


161

GC: the GC paradigm

• discussion: how does it "solve" ...– ... concurrent entities– ... heterogeneity– ... open systems

processes

common data format

anonymous communication(no inter-process

references)


162

GC: the GC paradigm

• flexible configurations: new entities join ...WordProcessor

LinePrinterPostscriptPrinter

"genera

te"

PostscriptPrinterno new referencesrequired


163

GC: the GC paradigm

• flexible configurations: entities leave ...

WordProcessor LinePrinterPostscriptPrinter

PostscriptPrinterno dangling references


164

GC: the GC paradigm

• characteristics– non-determinism

• many "retrieve" requests for one data item any one process may get it

• many "dropped" data items, and one requests requesting process receives any one dropped data items

– atomic operations


165

GC: the GC paradigm

• characteristics– "space uncoupling"

• processes may be in different address spaces / on different (distributed) computers

– "time uncoupling"• a sender does not know when some process will

receive the sent items

• the sender may even no longer exist at that time


166

GC: Linda

• Linda– first GC-language– binding with several computational languages

• C, C++, COBOL, Fortran, ...

– data items tuples– shared data space tuple space


167

GC: Linda

• Linda operations

– out ( … , … , … ) “generate a tuple in tuplespace”

– in / rd ( … , … , … ) “retrieve a tuple from tuplespace”

associative matching rules

out (“my name”, 5.2, 6);

float f ; int i;rd (“my name”, ?f, ?i);in (“string”, ?f, 6);


168

GC: Linda

– eval ( … , … , … ) “asynchronously evaluate a tuple”

– create new process, in which "foo" is performed

– when done, generate tuple:

( < result from foo(a,b,c) > , 6 )

eval ( foo (a, b, c) , 6);


169

GC: Linda

• matching rules (in / rd)– “pattern matching”

• actual / formal

• formal / actual

• actual / actual


170

shared tuple space

code generatingentitiescompiling entities

...

GC: Linda: a parallel compiler

while (1) { in ( ?filename ); compile (filename);}

("filename.c")

while (1) { in ( ?filename ); compile (filename);}

...out ("my_main.c");...

...out ("your_main.c");...


171

CG: typical extensions to Linda

• operations that simulate the use of futures– e.g. Bonita

– dispatch = in + continue

– arrived = check if a matching item is found

– obtain = wait until matching item is found

• operations that simulate RPC– e.g. Laura

– tuples = ("procedure name", <parameters>)


172

CG: typical extensions to Linda

• multiple tuple spaces

• object-oriented versions• data items objects

• shared data spaces object spaces

– JavaSpaces– Objective Linda / CO3PS

– matching of objects through a "match" object operation

class A { … bool matchmatch (A a) { … }; …}


173

Chapter overview


• Message passing




• Event Systems


174

Event Systems

• Pure event-driven– events are the basic objects of communication– entities can

• throw particular events• subscribe to other entities for particular events• handle particular events

– Notification = object representing an event– e.g. :

• Jini distributed event specification• Corba Event service


175

Event Systems

• Architecture

subscriberobserverobject of interest

Event service

object of interest

object of interest observer

subscriber

subscriber

3.

1.

2. notification

notification

notification

notification


176

Event Systems

• Main characteristics– Heterogeneous– Asynchronous– Delivery semantics ( multicast communication)


177

Distributed Systems:

Coordination

models and languages

October 2005Distributed systems: coordination models and languages 1 Distributed Systems:...

Documents

Transcript of October 2005Distributed systems: coordination models and languages 1 Distributed Systems:...