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

2. October 2005Distributed 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. October 2005Distributed systems: coordination models and languages 3 Introduction Communication –data representation Synchronization –how express cooperation? Data transfer Synchronization

4. October 2005Distributed systems: coordination models and languages 4 This chapter: overview Data representation Message passing Remote procedure calls Object request brokers Generative communication Event Systems

5. October 2005Distributed systems: coordination models and languages 5 This chapter: overview Applications, services Middleware layers request-reply protocol marshalling and external data representation UDP and TCP RMI and RPC

6. October 2005Distributed systems: coordination models and languages 6 Data representation Problem int System A int = 2-complement, 32 bits System B int = 1-complement, 40 bits on the wire: int = ??

7. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 8 Data representation (cont.) 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. October 2005Distributed systems: coordination models and languages 9 Data representation (cont.) 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. October 2005Distributed systems: coordination models and languages 10 Data representation (cont.) 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

11. October 2005Distributed systems: coordination models and languages 11 Data representation (cont.) CORBA CDR The flattened form represents aPerson struct with value: {‘Smith’, ‘London’, 1934} 0–3 4–7 8–11 12–15 16–19 20-23 24–27 5 "Smit" "h___" 6 "Lond" "on__" 1934 index in sequence of bytes4 bytes notes on representation length of string ‘Smith’ length of string ‘London’ unsigned long Struct Person{ string name; string place; unsigned long year; };

12. October 2005Distributed systems: coordination models and languages 12 Data representation (cont.) 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. October 2005Distributed systems: coordination models and languages 13 Data representation (cont.) 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. October 2005Distributed systems: coordination models and languages 14 Data representation (cont.) 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.String name: 6 London h0 java.lang.String place: 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. October 2005Distributed systems: coordination models and languages 15 Data representation (cont.) XML –Markup language defined by World Wide Web consortium –Data items tagged with ‘markup’ strings –Users can define their own tags Smith London 1934

16. October 2005Distributed systems: coordination models and languages 16 Data representation (cont.) 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. October 2005Distributed systems: coordination models and languages 17 This chapter: overview Data representation Message passing Remote procedure calls Object request brokers Generative communication Event Systems

18. October 2005Distributed systems: coordination models and languages 18 Message passing Basic functionality –Procedure Send (p: PortId; m: Message); –Procedure Receive (p: PortId; VAR m: Message);

19. October 2005Distributed systems: coordination models and languages 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 accept or check for message arrival

20. October 2005Distributed systems: coordination models and languages 20 Message passing (cont.) Semantics: synchronous <> asynchronous

21. October 2005Distributed systems: coordination models and languages 21 Message passing (cont.) 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. October 2005Distributed systems: coordination models and languages 22 Message passing (cont.) Semantics: synchronous <> asynchronous Send (p, m)  m ? b Receive(p, b) 

23. October 2005Distributed systems: coordination models and languages 23 Message passing (cont.) Semantics: synchronous <> asynchronous Example: Mach style Sender: ….. send(….); {message is in buffer!!! arrival??} Receiver: …. receive(….); {message available } …. Communication  NO synchronisation point

24. October 2005Distributed systems: coordination models and languages 24 Message passing (cont.) Semantics: synchronous <> asynchronous Port p Send (p, m)

25. October 2005Distributed systems: coordination models and languages 25 Message passing (cont.) Semantics: synchronous <> asynchronous Send(p, m) Port p receive(p,b)

26. October 2005Distributed systems: coordination models and languages 26 Message passing (cont.) Semantics: message destinations –message destination = communication identifier preference for location independent identifiers –types of message destination: process port mailbox

27. October 2005Distributed systems: coordination models and languages 27 Message passing (cont.) Semantics: message destinations process Send (p, m) Process p

28. October 2005Distributed systems: coordination models and languages 28 Message passing (cont.) Semantics: message destinations port Send (p, m) port p port q

29. October 2005Distributed systems: coordination models and languages 29 Message passing (cont.) Semantics: message destinations mailbox Send (p, m) mailbox p mailbox q

30. October 2005Distributed systems: coordination models and languages 30 Message passing (cont.) 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. October 2005Distributed systems: coordination models and languages 31 Message passing (cont.) 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. October 2005Distributed systems: coordination models and languages 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 Message passing (cont.)

33. October 2005Distributed systems: coordination models and languages 33 Message passing (cont.) Semantics: reliability –sender of message gets no reply? no distinction between process failure communication failure

34. October 2005Distributed systems: coordination models and languages 34 Message passing (cont.) Case study: UDP/TCP –Sockets <> ports Socket bound to (TCP) port + Internet address message agreed port any port socket Internet address = 138.37.88.249Internet address = 138.37.94.248 other ports client server

35. October 2005Distributed systems: coordination models and languages 35 Message passing (cont.) Case study UDP –Messages: Restricted packet size: < 2 16, < 2 13 (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. October 2005Distributed systems: coordination models and languages 36 Message passing (cont.) 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. October 2005Distributed systems: coordination models and languages 37 Message passing (cont.) 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. October 2005Distributed systems: coordination models and languages 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 hostname DatagramSocket 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 40 Message passing (cont.) 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. October 2005Distributed systems: coordination models and languages 41 Message passing (cont.) 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. October 2005Distributed systems: coordination models and languages 42 Message passing (cont.) Case study TCP: Java API –Class ServerSocket Socket Accept() –Class Socket getInputStream() getOutputStream() –Class DataInputStream readUTF, … (Universal Transfer Format) –Class DataOutputStream writeUTF, …

43. October 2005Distributed systems: coordination models and languages 43 Message passing (cont.) 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. October 2005Distributed systems: coordination models and languages 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 destination Socket 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.3 String 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 47 Message passing (cont.) 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. October 2005Distributed systems: coordination models and languages 48 Message passing (cont.) 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. October 2005Distributed systems: coordination models and languages 49 Message passing (cont.) Client-server communication Request ServerClient doOperation (wait) (continuation) Reply message getRequest execute method message select object sendReply

50. October 2005Distributed systems: coordination models and languages 50 Message passing (cont.) 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. October 2005Distributed systems: coordination models and languages 51 Message passing (cont.) –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. October 2005Distributed systems: coordination models and languages 52 Message passing (cont.) Case: Client-server communication: HTTP –Interactions : Open connection Client sends request Server sends reply Connection closed New 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. October 2005Distributed systems: coordination models and languages 53 Message passing (cont.) Case: Client-server communication: HTTP Request message Reply message GET//www.dcs.qmw.ac.uk/index.htmlHTTP/ 1.1 URL or pathnamemethodHTTP versionheadersmessage body HTTP/1.1200OK resource data HTTP versionstatus codereasonheadersmessage body

54. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 55 This chapter: overview Data representation Message passing Remote procedure calls Object request brokers Generative communication Event Systems

56. October 2005Distributed systems: coordination models and languages 56 Remote procedure calls Overview Basic principles Design issues Implementation aspects Case studies Asynchronous RPC

57. October 2005Distributed systems: coordination models and languages 57 Remote procedure calls Basic principles View on traditional application: –no OO yet! –application = main program +procedures (functions)  familiar paradigm: procedure call

58. October 2005Distributed systems: coordination models and languages 58 Remote procedure calls Basic principles View on traditional application: Main program … …. … ….... end Procedure AProcedure B

59. October 2005Distributed systems: coordination models and languages 59 Remote procedure calls Basic principles 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. October 2005Distributed systems: coordination models and languages 60 Remote procedure calls Basic principles Basic view on client-server model Main program … …. … ….... end clientserver RPC middleware Procedure A Procedure B

61. October 2005Distributed systems: coordination models and languages 61 Remote procedure calls Basic principles RPC technology: client side Main program … …. … ….... end Client stub procedure A Client stub procedure B

62. October 2005Distributed systems: coordination models and languages 62 Remote procedure calls Basic principles RPC technology: server side Server stub … …. … ….... end Procedure A Procedure B

63. October 2005Distributed systems: coordination models and languages 63 Remote procedure calls Basic principles RPC technology Server stub … …. … ….... end Procedure A Procedure B Main program … …. … ….... end Client stub procedure A Client stub procedure B Message subsystem

64. October 2005Distributed systems: coordination models and languages 64 Remote procedure calls Basic principles RPC technology client Request Reply Communication module dispatcher service client stub server stub procedure client processserver process procedure program

65. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 68 Remote procedure calls Design issues Classes of RPC systems Interface Definition language Exception handling Semantics of RPC Transparency

69. October 2005Distributed systems: coordination models and languages 69 Remote procedure calls Design issues 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. October 2005Distributed systems: coordination models and languages 70 Remote procedure calls Design issues Interface Definition language –describes operation signatures –interface compilers for generating client and server stubs in different languages (e.g. C, Pascal,…)

71. October 2005Distributed systems: coordination models and languages 71 Remote procedure calls Design issues 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. October 2005Distributed systems: coordination models and languages 72 Remote procedure calls Design issues 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. October 2005Distributed systems: coordination models and languages 73 Remote procedure calls

74. October 2005Distributed systems: coordination models and languages 74 Remote procedure calls Design issues 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 76 Remote procedure calls Implementation aspects Binding: linking client to server at execution time Binder interface Procedure Register (serviceName: String; serverPort: Port; version: integer); Procedure Withdraw (…); Procedure Lookup(serviceName: String; version:…): Port;

77. October 2005Distributed systems: coordination models and languages 77 Remote procedure calls Implementation aspects 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 80 Remote procedure calls Sun RPC: Interface in XDR Program FILEREADWRITE { version VERSION { void WRITE ( writeargs) = 1; Data READ (readargs) = 2; } = 2; } = 9999;

81. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 88 Remote procedure calls Asynchronous RPC Problem: throughput RPC? Process args marshal send Receive unmarshal execute request marshal send Receive unmarshal process results …. clientserver time Idle time!

89. October 2005Distributed systems: coordination models and languages 89 Remote procedure calls Asynchronous RPC Timing: Synchronous RPCAsynchronous RPC

90. October 2005Distributed systems: coordination models and languages 90 Remote procedure calls Asynchronous RPC 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. October 2005Distributed systems: coordination models and languages 91 Remote procedure calls Asynchronous RPC Extensions: –call streams: mix of synchronous and asynchronous calls message ordering preserved connection oriented connection breaks when semantics cannot be guaranteed

92. October 2005Distributed systems: coordination models and languages 92 Remote procedure calls Asynchronous RPC 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 94 This chapter: overview Data representation Message passing Remote procedure calls Object request brokers Generative communication Event Systems

95. October 2005Distributed systems: coordination models and languages 95 Object request brokers Basics: Object request broker = Objects + RPC +...

96. October 2005Distributed systems: coordination models and languages 96 Object request brokers Overview –distributed object systems –case study: Java RMI –case study: OMG Corba

97. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 98 ORB: Distributed object model Local <> remote invocation invocation remote invocation remote local invocation A B C D E F

99. October 2005Distributed systems: coordination models and languages 99 ORB: Distributed object model requirements –synchronous invocation semantics location transparency: location transparent object references access transparency: local & remote object invocations identical –inheritance –polymorphism

100. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 101 ORB: Distributed object model Remote object & its remote interface interface remote m1 m2 m3 m4 m5 m6 Data implementation remoteobject { of methods

102. October 2005Distributed systems: coordination models and languages 102 ORB: Distributed object model 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. October 2005Distributed systems: coordination models and languages 103 ORB: Distributed object model 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. October 2005Distributed systems: coordination models and languages 104 ORB: Object invocations object A object B skeleton Request proxy for B Reply Communication Remote Remote referenceCommunication module reference module module for B’s class & dispatcher remote client server servant

105. October 2005Distributed systems: coordination models and languages 105 ORB: The object bus Object Bus Client Server foo() Client - the invoking application object Server - the invoked application object

106. October 2005Distributed systems: coordination models and languages 106 ORB: The object bus Broker Stub/ProxySkeleton ClientServer foo() Application Object Bus

107. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 108 ORB: The object bus Broker StubSkeleton ClientServer foo() Conceptual invocation

109. October 2005Distributed systems: coordination models and languages 109 ORB: The object bus foo() Broker StubSkeleton ClientServer Method call

110. October 2005Distributed systems: coordination models and languages 110 ORB: The object bus foo() Broker StubSkeleton ClientServer Reified invocation

111. October 2005Distributed systems: coordination models and languages 111 ORB: The object bus foo() Broker StubSkeleton ClientServer Reified invocation

112. October 2005Distributed systems: coordination models and languages 112 ORB: The object bus foo() Broker StubSkeleton ClientServer Method call

113. October 2005Distributed systems: coordination models and languages 113 ORB: The object bus foo() Broker StubSkeleton ClientServer Return value

114. October 2005Distributed systems: coordination models and languages 114 ORB: The object bus foo() Broker StubSkeleton ClientServer Reified return value

115. October 2005Distributed systems: coordination models and languages 115 ORB: The object bus foo() Broker StubSkeleton ClientServer Reified return value

116. October 2005Distributed systems: coordination models and languages 116 ORB: The object bus foo() Broker StubSkeleton ClientServer Return value

117. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 119 Object request brokers Overview –distributed object systems –case study: Java RMI –case study: OMG Corba

120. October 2005Distributed systems: coordination models and languages 120 Java RMI JAVA –Driven by SUN Micro systems –Platform independent JAVA + RMI  distribution: –Remote Method Invocation  Distributed Java applications

121. October 2005Distributed systems: coordination models and languages 121 Java RMI: Architecture Java Runtime Environment StubSkeleton ClientServer foo() implements java.rmi.remote extends java.rmi.UnicastRemoteObject generated by rmic

122. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 123 Java RMI: Naming Service void 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. October 2005Distributed systems: coordination models and languages 124 Java RMI Tools: –rmic - Java RMI Stub Compiler –rmiregistry - Java Remote Object Registry –rmid - Java RMI Activation System Daemon

125. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 127 Java RMI: Remote interface package HelloAppRMI; interface Hello extends java.rmi.Remote { String sayHello() throws java.rmi.RemoteException; }

128. October 2005Distributed systems: coordination models and languages 128 Java RMI: Server package 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 130 RMI: Client package 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. October 2005Distributed systems: coordination models and languages 131 Object request brokers Overview –distributed object systems –case study: Java RMI –case study: OMG Corba

132. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 133 OMG CORBA OMG (cont.) –approach to standardization define requirements issue Requests for Proposals evaluate  revised proposals selection –major result: CORBA

134. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 136 OMA: Reference model Common facilitiesApplication objects Object services Object Request broker

137. October 2005Distributed systems: coordination models and languages 137 OMA: Reference model 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 Object Request broker

138. October 2005Distributed systems: coordination models and languages 138 OMA: Reference model 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 Object Request broker

139. October 2005Distributed systems: coordination models and languages 139 OMA: Reference model 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 Object Request broker

140. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 141 CORBA: Architecture simplified view foo() CORBA ORB StubSkeleton ClientServer

142. October 2005Distributed systems: coordination models and languages 142 CORBA: architecture ORB Core Dyn. Invoc. IDL Stub ORB Intf Object adaptor DSI IDL Skel Same for all ORBs Interface-specific stubs and skeletons Multiple adaptors possible ORB-private interface ClientObject Implementation

143. October 2005Distributed systems: coordination models and languages 143 CORBA: architecture client server proxy or dynamic invocation implementation repository object adapter ORB skeleton or dynamic skeleton client program interface repository Request Reply core for A Servant A

144. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 146 CORBA: IDL module HelloAppCORBA { interface Hello { string sayHello(); }; The Hello.idl file

147. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 148 CORBA: stub/skeleton foo() CORBA ORB StubSkeleton ClientServer Static invocation!!

149. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 151 CORBA: Inter-ORB Protocols Interoperability between different commercial products? foo() CORBA ORB StubSkeleton ClientServer System A System B

152. October 2005Distributed systems: coordination models and languages 152 CORBA: Inter-ORB Protocols CORBA ORB Stub Client System A General Inter-ORB Protocol Skeleton Server System B CORBA ORB GIOP - IIOP

153. October 2005Distributed systems: coordination models and languages 153 CORBA: Inter-ORB Protocols 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. October 2005Distributed systems: coordination models and languages 154 Object request brokers Conclusion: –extends RPC –allows for distribution of objects –Supports heterogeneity

155. October 2005Distributed systems: coordination models and languages 155 Chapter overview Data representation Message passing Remote procedure calls Object request brokers Generative communication Event Systems

156. October 2005Distributed systems: coordination models and languages 156 Generative communication (GC) Overview –goals / motivation –how? –the paradigm of GC –Linda –typical extensions

157. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 158 GC: How ? separation –computational aspects –coordination aspects uncoupling of concurrent entities  no direct communication calculations communication

159. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 160 GC: the GC paradigm example "configuration" WordProcessor LinePrinter PostscriptPrinter "generate"

161. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 162 GC: the GC paradigm flexible configurations: new entities join... WordProcessor LinePrinter PostscriptPrinter "generate" PostscriptPrinter no new references required

163. October 2005Distributed systems: coordination models and languages 163 GC: the GC paradigm flexible configurations: entities leave... WordProcessor LinePrinter PostscriptPrinter no dangling references

164. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 168 GC: Linda –eval ( …, …, … )“asynchronously evaluate a tuple” –create new process, in which "foo" is performed –when done, generate tuple: (, 6 ) eval ( foo (a, b, c), 6);

169. October 2005Distributed systems: coordination models and languages 169 GC: Linda matching rules (in / rd) –“ pattern matching” actual / formal formal / actual actual / actual

170. October 2005Distributed systems: coordination models and languages 170 shared tuple space code generating entities compiling 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. October 2005Distributed systems: coordination models and languages 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", )

172. October 2005Distributed systems: coordination models and languages 172 CG: typical extensions to Linda multiple tuple spaces object-oriented versions data items  objects shared data spaces  object spaces –JavaSpaces –Objective Linda / CO 3 PS –matching of objects through a "match" object operation class A { … match bool match (A a) { … }; … }

173. October 2005Distributed systems: coordination models and languages 173 Chapter overview Data representation Message passing Remote procedure calls Object request brokers Generative communication Event Systems

174. October 2005Distributed systems: coordination models and languages 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. October 2005Distributed systems: coordination models and languages 175 Event Systems Architecture subscriberobserverobject of interest Event service object of interest observer subscriber 3. 1. 2. notification

176. October 2005Distributed systems: coordination models and languages 176 Event Systems Main characteristics –Heterogeneous –Asynchronous –Delivery semantics ( multicast communication)

177. October 2005Distributed systems: coordination models and languages 177 Distributed Systems: Coordination models and languages