Interprocess Communication

Transcription

1 1. Foundations and Architecture distributed system architechtures; network interface 2. Time and Global States clocks and concepts of time; event ordering; synchronization; global states 3. Coordination distributed mutual exclusion; multicast; group communication, byzantine problems (consensus) 4. Inter Process Communication and Middleware inter process communication; middleware; distributed object models; remote invocation; CORBA;.net; name and directory services 5. Security cryptographic algorithms; signatures and certificates; authentication 6. Advanced Topics fault-tolerance; specification and verification 4-1 Stefan Leue 2005 Interprocess Communication Distributed Systems 8 rely on exchanging data and achieving synchronization amongst autonomous distributed processes Inter process communication (IPC) ishared variables imessage passing message passing in concurrent programming languages ilanguage extensions iapi calls Principles of IPC (see also [Andrews and Schneider 83] G. Andrews and F. Schneider, Concepts and Notations for Concurrent Programming, ACM Computing Surveys, Vol. 15, No. 1, March 1983) 8 Concurrent programs: collections of two or more sequential programs executing concurrently 8 Concurrent processes: collection of two or more sequential programs in operation, executing concurrently 4-2 Stefan Leue 2005

2 Interprocess Communication Synchronization 8 concurrent processes on different computers execute at different speeds 8 need for one process to influence computation in another process specify constraints on the ordering of events in concurrent processes message passing isend message happens before receive message Message Passing Primitives 8 send expression_list to destination_designator evaluates expression_list adds a new message instance to channel destination_designator 8 receive variable_list from source_designator assignes received values to variables in variable_list destroys received message Central questions 8 how are destination designators specified? 8 how is communication synchronized? 4-3 Stefan Leue 2005 Interprocess Communication Destination Designation 8 direct naming: source and destination process names serve as designators (a pair of source and destination designators defines a channel) send cur_status to monitor or monitor!cur_status receive message from handler or handler?message easy to implement and use allows a process easy control when to receive which message from which other process used to implement client/server applications iwell suited to implement client/server paradigm if there is one client and one server iotherwise: server should be capable of accepting invocations from any client at any time, and a client should be allowed to invoke many services at a time if more than one server available 4-4 Stefan Leue 2005

3 Interprocess Communication Destination Designation 8 global names or mailboxes: process name-independent destination designator shared by many processes messages sent to a mailbox can be received by any process that executes a receive referring to that mailbox name to implement Client/Server applications iclients send requests to mailbox, an available server picks them up drawback: costly implementation imessage sent to mailbox irelayed to all other sites that could potentially receive from that mailbox iif one site decides to receive, inform all other sites that message is no longer available for receipt imutual exclusion for concurrent access 4-5 Stefan Leue 2005 Interprocess Communication Destination Designation 8 ports: mailbox, but only one process is permitted to receive from that mailbox easy to implement: receives can occur in only one process, no distribution and coordination necessary suitable for multiple clients / single server applications 8 Message destinations in Internet programming hybrid direct naming/port scheme (Internet_address, port_number) port corresponds to many sender/one receiver concept 4-6 Stefan Leue 2005

4 Interprocess Communication Channel Naming 8 static (at compile time) impossible for a program to communicate along a channel not known at compile time inflexibility: if a process might ever need to communicate with a recipient, that channel must be available throughout the entire runtime of the sending programme 8 dynamic (at runtime) administrative overhead at runtime more flexible allocation of communication resources 4-7 Stefan Leue 2005 Interprocess Communication Semantics of message passing primitives 8 Blocking non-blocking: the execution will never delay the invoking process blocking: otherwise 8 Synchronization asynchronous message passing: message passing using buffers with unbounded capacity isender may race ahead an unbounded number of steps isender never blocks ireceiver blocks on empty queue synchronous message passing: no buffering between sender and receiver isender blocks until receiver ready to receive ireceiver blocks until sender ready to send buffered message passing: buffers with bounded, finite capacity isender may race ahead a finite, bounded number of steps isender blocks on full buffer ireceiver blocks on empty buffer 4-8 Stefan Leue 2005

5 Interprocess Communication Non-blocking primitives for asynchronous or buffered message passing 8 receive background variant: process continues, receives interrupt upon arrival ioverhead for implementation ignoring variant: programme polls for availability 8 send sending process waits for empty buffer or drops message to be sent 4-9 Stefan Leue 2005 Interprocess Communication OSI-BRM Internet L7 Application L6 Presentation L5 Session L4 Transport L3 Network L2 Data Link Control L1 Physical smtp ftp telnet http TCP IP LAN (M)WAN proprietary netwoks Pearson Education 2001 Distributed Applications 8 availability of a set of pre-implemented application services, like , ftp, http, etc. 8 what if you want to build your own, customized Internet application? 8 access to Transport Layer services Services provided by Internet Transport Layer 8 UDP: message passing (datagram) 8 TCP: data stream 4-10 Stefan Leue 2005

6 Interprocess Communication Pearson Education 2001 Sockets 8 Internet IPC mechanism of Unix and other operating systems (BSD Unix, Solaris, Linux, Windows NT, Macintosh OS) 8 processes in these OS can send and receive messages via a socket 8 sockets are duplex 8 sockets need to be bound to a port number and an internet address in order to be useable for sending and receiving messages 8 each socket has a transport protocol attribute (TCP or UDP) 8 messages sent to some internet address and port number can only be received by a process using a socket that is bound to this address and port number 8 UDP socket can be connected to a remote IP address and port number 8 processes cannot share ports (exception: TCP multicast) 4-11 Stefan Leue 2005 Interprocess Communication IPC based on UDP datagrams 8 UDP datagram properties: no guarantee of order preservation, message loss and duplications are possible 8 necessary steps create socket bind socket to a port and local Internet address iclient: arbitrary free port iserver: server port 8 receive method: returns Internet address and port of sender, plus message 8 message size: IP allows for messages of up to 2 16 bytes most implementations restrict this to around 8 kbytes larger application messages: application s responsibility to perform fragmentation/reassembling if arriving message is too big for array allocated to receive message content, truncation occurs 4-12 Stefan Leue 2005

7 Interprocess Communication IPC based on UDP datagrams 8 send: non-blocking blocks only until message given to UDP/IP upon arrival placed in per-port queue 8 receive: blocking pre-emption by timeout possible if process wishes to continue while waiting for packet, use separate thread 4-13 Stefan Leue 2005 Interprocess Communication Java API for UDP datagrams 8 Classes DatagramPacket constructor generating message for sending from array of bytes imessage content (byte array) ilength of message iinternet address and port number (destination) similar constructor for receiving a message DatagramSocket class for sending and receiving of UDP datagrams ione constructor with port number as argument, another without ino-argument constructor to use free local port imethods * send and receive * setsotimeout * connect for connecting a socket to a particular remote Internet address and port 4-14 Stefan Leue 2005

8 Interprocess Communication Java API for UDP datagrams 8 Example process creates socket, sends message to server at port 6789, and waits to receive reply import java.net.*; import java.io.*; public class UDPClient{ public static void main(string args[]){ // args give message contents and destination hostname try { DatagramSocket asocket = new DatagramSocket(); // create socket byte [] m = args[0].getbytes(); InetAddress ahost = InetAddress.getByName(args[1]); // DNS lookup int serverport = 6789; DatagramPacket request = new DatagramPacket(m, args[0].length(), ahost, serverport); asocket.send(request); //send nessage byte[] buffer = new byte[1000]; DatagramPacket reply = new DatagramPacket(buffer, buffer.length); asocket.receive(reply); //wait for reply System.out.println("Reply: " + new String(reply.getData())); asocket.close(); catch (SocketException e){system.out.println("socket: " + e.getmessage()); catch (IOException e){system.out.println("io: " + e.getmessage()); // can be caused by send 4-15 Stefan Leue 2005 Interprocess Communication IPC based on TCP streams 8 abstract service: stream of bytes to be written to or received from 8 features message size: no constraint, TCP decides when to send a transport layer message consisting of multiple application messages, immediate transmission can be forced connection oriented retransmission to recover from message lost (timeout-bounded) queue at destination socket blocked on receive flow control to block sender when overflow might occur need to agree on data sent and received server generates new thread for new connection 4-16 Stefan Leue 2005

9 Interprocess Communication API for streams 8 connection establishment using client/server approach, afterwards peer communication client: issue connect requests server: has listening port to receive connect request messages accept of a connection: create new stream socket for new connection Java API for TCP streams 8 Classes ServerSocket class: create socket at server side to listen for connect requests Socket class: for processes with connections iconstructor to create a socket and connect it to remote host and port of a server imethods for accessing input and output stream 4-17 Stefan Leue 2005 Interprocess Communication Example 8 TCP-based server for stream communication import java.net.*; import java.io.*; public class TCPServer { public static void main (String args[]) { try{ int serverport = 7896; // the server port ServerSocket listensocket = new ServerSocket(serverPort); // new server port generated while(true) { Socket clientsocket = listensocket.accept(); // listen for new connection Connection c = new Connection(clientSocket); // launch new thread catch(ioexception e) {System.out.println("Listen socket:"+e.getmessage()); 4-18 Stefan Leue 2005

10 Interprocess Communication Example 8 TCP-based server for stream communication 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(); // read a line of data from the stream out.writeutf(data); // write a line to the stream clientsocket.close(); catch (EOFException e){system.out.println("eof:"+e.getmessage()); catch (IOException e) {System.out.println("readline:"+e.getMessage()); 4-19 Stefan Leue 2005 Interprocess Communication Data Representation 8 data representation problem use agreed external representation, two conversions necessary use sender s or receiver s format and convert at the other end 8 transmission of structured data types data types may not change during transmission usage of a commonly understood flattened transfer format (structured types are reduced to their primitive components) 8 data representation formats SUN Microsystems XDR CORBA CDR ASN.1 (OSI layer 6) 8 marshalling/unmarshalling marshalling: assembling a collection of data items in a form suitable for transmission unmarshalling: disassembling and recovery of original data items usually performed automatically by middleware layer ihand-programming error-prone iuse of compilers for programs working directly at transport API 4-20 Stefan Leue 2005

11 Interprocess Communication CORBA Common Data Represenation (CDR) 8 CORBA: Common Object Request Broker Architecture middleware architecture standardized by the Object Management Group see 8 CORBA CDR supports types allowed in CORBA remote object invocations primitive types ilittle/big endian according to sender s representation format iprimitive values start at indexed byte positions (multiples of 1, 2, 4 or 8) ifloating point according to IEEE standard icharacters using an agreed character set 4-21 Stefan Leue 2005 Interprocess Communication CORBA Common Data Represenation (CDR) 8 structured types definitions Pearson Education 2001 example: struct with value { Smith, London, 1934 Pearson Education Stefan Leue 2005

12 Interprocess Communication CORBA Common Data Represenation (CDR) 8 CORBA marshalling/unmarshalling CORBA Interface Definition Language (IDL) IDL compilers will generate marshalling and unmarshalling operations ( stubs ) that transforms data objects into CDR format 4-23 Stefan Leue 2005 Interprocess Communication Remote Object References 8 needed when a client invokes an object that is located on a remote server 8 reference needed that is unique over space and time space: where is the object located time: correct version of an undeleted object 8 a generic format proposal Pearson Education 2001 internet address/port number: process which created object time: creation time object number: local counter, incremented each time an object is created in the creating process interface: how to access the remote object (if object reference is passed from one client to another) 8 extension: object references that are location transparent 4-24 Stefan Leue 2005

13 Interprocess Communication Client-Server Communication 8 often built over UDP datagrams client-server protocol consists of request/response pairs, hence no acknowledgements at transport layer are necessary avoidance of connection establishment overhead no need for flow control due to small amounts of data tranfered 8 generic protocol example (for RPC or RMI communication): Pearson Education Stefan Leue 2005 Interprocess Communication Client-Server Communication 8 format of protocol messages message type (request/reply) request ID isending process identifier (e.g., IP address/port number) iinteger sequence number incremented by sender with every request object reference method ID and arguments 4-26 Stefan Leue 2005

14 Interprocess Communication Client-Server Communication 8 if implemented over UDP: failure recovery omission failures iuse timeout and resend request when timeout expires and reply hasn t arrived iserver receives repeated request * idempotent operations: same result obtained on every invocation * non-idempotent operations: re-send result stored from previous request, requires maintenance of a history of replies iloss of replies: request - reply - ack reply protocol message duplication: return request ID with reply 4-27 Stefan Leue 2005 Interprocess Communication Client-Server Communication 8 example: Hypertext Transfer Protocol (HTTP) lightweight request - reply protocol for the exchange of network resources between web clients and web servers protocol steps iconnection establishment between client and server (likely TCP, but any reliable transport protocol is acceptable) iclient sends request iserver sends reply iconnection closure inefficient scheme, therefore HTTP 1.1 allows persistent transport connections (remains open for successive request/reply pairs) Resources can have mime-type data types, e.g. itext/plain itext/html iimage/jpeg data is marshalled into ASCII transfer syntax 4-28 Stefan Leue 2005

15 Interprocess Communication Client-Server Communication 8 example: Hypertext Transfer Protocol (HTTP) request Pearson Education 2001 iget: request of resource, identified by URL, may refer to * data: server returns data * program: server runs program and returns output data ihead: request similar like GET, but only meta data on resource is returned (like date of last modification) ipost: specifies resource (for instance, a server program) that can deal with the client data provided with previous request iput: supplied data to be stored in given URL idelete: delete an identified resource on server 4-29 Stefan Leue 2005 Interprocess Communication Client-Server Communication 8 example: Hypertext Transfer Protocol (HTTP) reply Pearson Education Stefan Leue 2005

16 Middleware Applications RMI, RPC and events Request reply protocol External data representation Operating System Middleware layers Functionality in Middleware (Upper Sublayer) 8 Remote Procedure Call (RPC) client calls a procedure implemented and executing on a remote computer call as if it was a local procedure 8 Remote Method Invocation (RMI) local object invoking methods of an object residing on a remote computer invocation as if it was a local method call 8 Event-based Distributed Programming objects receive asynchronous notifications of events happening on remote computers/processes 4-31 Stefan Leue 2005 Middleware Applications RMI, RPC and events Request reply protocol External data representation Operating System Middleware layers Transparency Features of Middleware (Upper Sublayer) 8 location transparency: RMI and RPCs invoked without knowledge of the location of invoked method/procedure 8 transport protocol transparency: e.g., request/reply protocol used to implement RPC can use either transport protocol 8 transparency of computer hardware and operating system e.g., use of external data representations 8 transparency of programming language used e.g., by use of programming language independent Interface Definition Languages, such as CORBA IDL 4-32 Stefan Leue 2005

17 Middleware Interfaces for RMI and RPC 8 interface defined for each module/object 8 provides signatures for a set of methods 8 hides all implementation details 8 accesses can only occur through methods specified in interface 8 specifics for interfaces in distributed systems no direct access to remote variables possible iuse message passing mechanism to transmit data objects and variables * request-reply protocols local parameter passing mechanisms (by value, by reference) not applicable to remote invocations ispecify input, output as attribute to parameters * input: transmitted with request message * output: transmitted with reply message pointers are not valid in remote address spaces icannot be passed as argument along interface 4-33 Stefan Leue 2005 Middleware Interfaces for RMI and RPC 8 RPC and RMI interfaces are often seen as a client/server system service interface (in client server model) ispecification of procedures and methods offered by a server remote interface (in RMI model) ispecification of methods of an object that can be invoked by objects in other processes 4-34 Stefan Leue 2005

18 Middleware Interfaces for RMI and RPC 8 Interface Definition Languages impossible to specify direct access to variables in remote classes hence, access only through specified interface desirable to have language-independent IDL that compiles into access methods in application programming language example: CORBA IDL // In file Person.idl struct Person { string name; string place; long year; ; interface PersonList { readonly attribute string listname; void addperson(in Person p) ; void getperson(in string name, out Person p); long number(); ; 4-35 Stefan Leue 2005 Distributed Objects Components of an object model 8 object references refer to objects of a class can be assigned, queried 8 interfaces 8 actions initiated by an object invoking a method in another object possible effects istate of method invocation receiver may change ican cause further method invocation 8 exceptions system as well as programmer-defined reactions on unexpected or error situations 8 garbage collection disposal of resources (memory) that are occupied by objects that are no longer referenced and will not be needed any more in the future 4-36 Stefan Leue 2005

19 Distributed Objects Distributed Object Model 8 adoption of client-server model servers maintain objects and allow remote objects to access the methods of those objects that are specified for remote use in the interface definition clients invoke the methods offered by servers using remote method invocation (RMI) 8 RMI implemented using a request/reply protocol request carries remote method reference and remote object s in parameters to server reply returns out parameters (results of RMI) to client A request remote invocation reply B local C invocation local E invocation local invocation D remote invocation F 4-37 Stefan Leue 2005 Remote Method Invocation A remote invocation B local C invocation local E invocation local invocation D remote invocation F Remote Object 8 object capable of receiving RMIs (in example at least B and F) Remote Object Reference 8 needed by an object performing a RMI 8 refers to server of RMI 8 typical format 8 can be passed as parameter or result 4-38 Stefan Leue 2005

20 Remote Method Invocation remote object remote interface Data m1 implementation { m2 m3 of methods m4 m5 m6 Remote Interface 8 specifies which methods can be invoked remotely 4-39 Stefan Leue 2005 Remote Method Invocation Actions 8 caused by method invocations 8 if boundary of one process or computer is crossed through invocation, then RMI will be used to cause the action Garbage Collection 8 garbage collection for remote objects 8 determine whether there are remaining references to an object in the system Exceptions 8 recovery from error situations as in non-distributed case 8 specific problems due to distributed environment server may have crashed server may be too busy to reply within reasonable time bounds 8 specific exceptions timeouts specific exceptions due to underlying distributed infrastructure 8 CORBA IDL application level exceptions system generates distribution-specific exceptions 4-40 Stefan Leue 2005

21 Remote Method Invocation RMI usually implemented via request/reply protocol 8 if implemented over UDP, then the following failures may occur message omission messages not delivered in send order message duplication 8 additionally, process failures are possible (crash or arbitrary) 8 consequence: cannot be guaranteed, that remote operations are executed exactly once (as it can be guaranteed for local operations) 4-41 Stefan Leue 2005 Remote Method Invocation Fault tolerance measures Invocation semantics Retransmit request message No Yes Yes Duplicate filtering Not applicable No Yes Re-execute procedure or retransmit reply Not applicable Maybe Re-execute procedure At-least-once Retransmit reply At-most-once Invocation Semantics 8 choices in the implementation retransmit request message until reply or server presumed failed filtering of duplicates at server if retransmit is used when retransmitted request arrives: iresult retransmission if retransmitted request arrives (requires keeping of history at server) or irepeated execution of procedure 8 leads to different invocation semantics 4-42 Stefan Leue 2005

22 Remote Method Invocation Fault tolerance measures Invocation semantics Retransmit request message No Yes Yes Duplicate filtering Not applicable No Yes Re-execute procedure or retransmit reply Not applicable Maybe Re-execute procedure At-least-once Retransmit reply At-most-once Invocation Semantics 8 maybe invoker knows nothing about whether operation is executed iany type of communication or process failure may have happened no fault tolerance mechanisms used 4-43 Stefan Leue 2005 Remote Method Invocation Fault tolerance measures Invocation semantics Retransmit request message No Yes Yes Invocation Semantics 8 at-least-once invoker receives iresult, or iexception, if no result was received if result was received, invoker knows that operation was executed at least once, but knows nothing if exception occurs achieved through retransmissions of requests and re-executions remaining failure modes icrash failure of server (when no fairness for this component) iarbitrary failures caused through re-execution of nonindempotent operation on server Duplicate filtering Not applicable No Yes Re-execute procedure or retransmit reply Not applicable Maybe Re-execute procedure At-least-once Retransmit reply At-most-once 4-44 Stefan Leue 2005

23 Remote Method Invocation Fault tolerance measures Invocation semantics Retransmit request message No Yes Yes Invocation Semantics 8 at-most-once invoker receives iresult, in which case s/he knows that operation was executed exactly once, or iexception informing that no result was received, in which case the operation was performed either once, or not at all requires usage of all fault tolerance measures 8 examples Java RMI and CORBA use at-most-once CORBA allows maybe semantics for RMIs that do not return results Duplicate filtering Not applicable No Yes Re-execute procedure or retransmit reply Not applicable Maybe Re-execute procedure At-least-once Retransmit reply At-most-once 4-45 Stefan Leue 2005 Remote Method Invocation client object A proxy for B Request server skeleton & dispatcher for B s class remote object B Reply Remote Communication reference module module Implementation of RMI 8 communication module request/reply messages uses message type, requestid and remote object reference in server iselect dispatcher for the class of the object to be invoked iobtains local reference from remote reference module by providing remote object identifier delivered with request message ipasses on the local reference to scheduler Communication module Remote reference module 4-46 Stefan Leue 2005

24 Remote Method Invocation client object A proxy for B Request server skeleton & dispatcher for B s class remote object B Reply Remote Communication reference module module Communication module Remote reference module Implementation of RMI 8 remote reference module translation between local and remote object references using remote object table icontains entries for all remote objects maintained by the server iand for all proxies (explained later) used when marshalling and unmarshalling remote object references 4-47 Stefan Leue 2005 Remote Method Invocation client object A proxy for B Request server skeleton & dispatcher for B s class remote object B Reply Remote Communication reference module module Implementation of RMI 8 the RMI sublayer of the middleware architecture consists of proxies (in client): local placeholders for remote objects dispatcher (in server): receives request and uses methodid to select appropriate message in skeleton skeleton (in server): implements methods in the remote interface iunmarshaling arguments iinvokes corresponding method in remote object iwaits for completion of invocation imarshals results, possibly exceptions, and returns them in a reply to invoking method of proxy Communication module Remote reference module 4-48 Stefan Leue 2005

25 Remote Method Invocation client object A proxy for B Request server skeleton & dispatcher for B s class remote object B Reply Remote Communication reference module module Communication module Remote reference module Implementation of RMI 8 implementation of RMI layer (proxies, skeletons and dispatchers) in some systems they can be automatically compiled, e.g. iorbix CORBA, uses IDL descriptions of remote interfaces to compile RMI layer, generates C++ code ijava RMI * proxy, skeleton and dispatcher classes are generated from the class of the remote object 4-49 Stefan Leue 2005 Remote Method Invocation Some more RMI components 8 factory methods remote object interfaces cannot include constructors factory methods replace constructors to create remote objects 8 binders service maintaining mappings from textual object names to remote object references 8 threads in server every remote method invocation is usually given an own thread to execute iadvantages, if RMI invokes other local or remote methods that cause wait times 4-50 Stefan Leue 2005

26 Remote Method Invocation Distributed Garbage Collection 8 free resources occupied by objects that have no more reference to it in the system 8 Java Distributed Garbage Collection algorithm: each server maintains a list of processes that hold remote object references for each of its remote objects when client receives a remote reference to particular remote object X, issuing a addref(x) to the server, server adds X to the list when client s garbage collector notices that a proxy for a remote object X is no longer referenced, it sends removeref(x) to server, which deletes X from list when list is empty, and there are no local references to X, collect resources held by X through server s local garbage collector 4-51 Stefan Leue 2005 Remote Method Invocation Distributed Garbage Collection 8 fault tolerance of Java Distributed Garbage Collection supported by request/reply protocol with at-most-once semantics toleration of communication failures iaddref and removeref are indempotent iif addref(x) returns exception, then client will not instantiate proxy but will send removeref(x) ieffect of removeref(x) is correct no matter whether addref(x) succeeded or not ifailure of removeref(x) is masked by the use of leases leases iservers lease their objects to clients for limited periods of time, starting with addref ihelps tolerate failures of removeref as well as client failures iavoids problem of having to maintain lists of remote object references if all object references are handled through leases 4-52 Stefan Leue 2005

27 SUN Remote Procedure Call client process Request server process Reply client stub procedure client program Communication module Communication module dispatcher server stub procedure service procedure SUN RPC 8 developed by SUN Microsystems to support client-server communication for use in SUN s NFS 8 very similar in concept to RMI 8 any of the delivery semantics of RMI can be implemented 8 only addresses procedure calls no object references 8 client stub procedure corresponds to proxy 8 server stub procedure similar to skeleton 4-53 Stefan Leue 2005 Event Based Distributed Programming Event Based Distributed Programming 8 event typically caused by method invocation or message delivery 8 event changes state of object 8 multiple objects at different locations are informed of the occurrence of an event at a particular object, for example: in a spontaneous computing environment, that a person s PDA has entered a hotel room a client has entered participation in a collaborative work environment an electronic document has been modified 4-54 Stefan Leue 2005

28 Event Based Distributed Programming Event Based Distributed Programming 8 publish-subscribe paradigm object generating events publishes list of events for which other objects can receive notifications object requiring notifications subscribes to the notification service at an object offering notification for this particular event through its publication list 8 characteristics of event based systems heterogeneity of hard- and software asynchronicity isynchronous notification would be highly inefficient at client as well as at server end iclient-polling also rather inefficient 4-55 Stefan Leue 2005 Event Based Distributed Programming object of interest Event service subscriber 1. notification object of interest observer subscriber 2. notification notification object of interest observer subscriber 3. notification Architecture 8 event service maintains database of published events and registered subscriptions event service is notified of events at objects of interest subscribers subscribe for notifications at event service after occurrence of event, notification is sent to all subscribers 8 delivery semantics is implementation dependent e.g., notifications by IP multicast do not guarantee that any notification will ever get delivered to subscriber 4-56 Stefan Leue 2005

29 Event Based Distributed Programming object of interest 1. Event service notification subscriber object of interest observer subscriber 2. notification notification object of interest observer subscriber 3. notification Architecture 8 observer objects: decoupling of an object of interest from subscriber responsible for all subscribers to events in some object subscribers and the types of events they are interested in may be rather heterogeneous - hence, better to have observer deal with this (separation of concerns!) 8 three cases in case 3, the object of interest is outside event service, hence, the observer needs to poll the object of interest for event occurrences 4-57 Stefan Leue 2005 Java RMI Extension of Java object model 8 allows for invocation of methods on remote objects 8 single language system 8 RMI syntactically identical to local method invocations should RMI calls be syntactically transparent, or not? ipro: hiding of the implementation of the method invocation icon: the semantics of local and remote invocation differ, and this should be made explicit in the language 8 however, object making a remote invocation needs to be able to handle RemoteExceptions that are thrown in the event of communication subsystem failures 8 remote object must implement Remote interface 8 example used shared whiteboard ishared use of drawing surface containing graphical objects iserver maintains current shape of drawing iclients can poll server about latest shape of a drawing iserver attaches version numbers to new arriving shapes 4-58 Stefan Leue 2005

30 Remote Interface Java RMI import java.rmi.*; import java.util.vector; public interface Shape extends Remote { int getversion() throws RemoteException; GraphicalObject getallstate() throws RemoteException; 1 public interface ShapeList extends Remote { Shape newshape(graphicalobject g) throws RemoteException; 2 Vector allshapes() throws RemoteException; int getversion() throws RemoteException; 8 GraphicalObject: class representing state of drawing objects should implement Serializable -why? 4-59 Stefan Leue 2005 Remote Interface Java RMI import java.rmi.*; import java.util.vector; public interface Shape extends Remote { int getversion() throws RemoteException; GraphicalObject getallstate() throws RemoteException; 1 public interface ShapeList extends Remote { Shape newshape(graphicalobject g) throws RemoteException; 2 Vector allshapes() throws RemoteException; int getversion() throws RemoteException; 8 Ordinary and remote objects can appear as input and output arguments remote objects: passed by (object) reference i2: newshape returns object with remote interface, i.e., remote object, as result iwhen remote object reference is received, an RMI can be issued on the object refered to by this reference ordinary objects: passed by value inew object created locally, with state differing from original object 4-60 Stefan Leue 2005

31 Insert: Processes and Threads Process 8 software in execution 8 unit of resource management for operating system execution environment iaddress space ithread synchronization and communication resources (e.g., semaphores, sockets) icomputing resources (file systems, windows, etc.) threads ischedulable activities attached to processes iarise from the need for concurrent activities sharing resources within one process * concurrent input/output with problem computation * servers: concurrent processing of client requests, each request handled by one thread 4-61 Stefan Leue 2005 Insert: Processes and Threads Process 8 processes vs. threads threads are lightweight processes iprocesses expensive to create, threads easier to create and destroy 8 process instantiation one thread will be instantiated as well, may instantiate offsprings 4-62 Stefan Leue 2005

32 Java Thread class Processes and Threads Thread(ThreadGroup group, Runnable target, String name) Creates a new thread in the SUSPENDED state, which will belong to group and be identified as name; the thread will execute the run() method of target. setpriority(int newpriority), getpriority() Set and return the thread s priority. run() A thread executes the run() method of its target object, if it has one, and otherwise its own run() method (Thread implements Runnable). start() Change the state of the thread from SUSPENDED to RUNNABLE. sleep(int millisecs) Cause the thread to enter the SUSPENDED state for the specified time. yield() Enter the READY state and invoke the scheduler. destroy() Destroy the thread Stefan Leue 2005 Processes and Threads Thread Groups 8 every thread belongs to one group, assigned at thread creation time 8 thread groups useful to shield various applications running in parallel on one Java Virtual machine thread in one group may not interrupt thread in another group ie.g., an application may not interrupt the windowing (AWT) thread 4-64 Stefan Leue 2005

33 Processes and Threads Java Thread Synchronization 8 each thread s local variables and methods are private to it thread has own stack 8 thread does not have private copies of static (class) variables or object instance variables 8 mutual exclusion via monitor concept abstract data type first implemented in Ada in Java: synchronized keyword iany object can only be accessed through one invocation of any of its synchronized methods ian object can have synchronized and non-synchronized methods example isynchronized addto() and removefrom() methods to serialize requests in worker pool example 4-65 Stefan Leue 2005 Processes and Threads Java Thread Synchronization 8 threads can be blocked and woken up thread awaiting a certain condition calls an object s wait() method other thread calls notify() or notifyall() to awake one or all blocked threads 8 example worker thread discovers no requests to be processed icalls wait() on instance of Queue when IO thread adds request to queue icalls notify() method of queue to wake up worker thread.join(int millisecs) Blocks the calling thread for up to the specified time until thread has terminated. thread.interrupt() Interrupts thread: causes it to return from a blocking method call such as sleep(). object.wait(long millisecs, int nanosecs) Blocks the calling thread until a call made to notify() or notifyall() on object wakes the thread, or the thread is interrupted, or the specified time has elapsed. object.notify(), object.notifyall() Wakes, respectively, one or all of any threads that have called wait() on object Stefan Leue 2005

34 Java RMI Downloading of Classes 8 classes can be transferred from one Java VM to another 8 passing of local or remote object references if recipient does not yet possess class of object passed by value, or proxy to handle remote object reference, the respective code is transferred automatically from the VM where these are implemented RMI Registry: binder for Java RMI 8 runs of every server of remote objects 8 maps local object names of the form //computername:port/objname to object references 8 not a global service - clients need to query a particular host to get reference 4-67 Stefan Leue 2005 Server with main method Java RMI import java.rmi.*; public class ShapeListServer{ public static void main(string args[]){ System.setSecurityManager(new RMISecurityManager()); try{ ShapeList ashapelist = new ShapeListServant(); 1 Naming.rebind("Shape List", ashapelist ); 2 System.out.println("ShapeList server ready"); catch(exception e) { System.out.println("ShapeList server main " + e.getmessage()); Security Manager 8 implements various security policies for client accesses Main method 8 1: create instance of ShapeListServant 8 2: binds name "ShapeList" to newly created instance in RMIRegistry 4-68 Stefan Leue 2005

35 Java RMI ShapeListServant implements ShapeList import java.rmi.*; import java.rmi.server.unicastremoteobject; import java.util.vector; public class ShapeListServant extends UnicastRemoteObject implements ShapeList { private Vector thelist; // contains the list of Shapes 1 private int version; public ShapeListServant()throws RemoteException{... public Shape newshape(graphicalobject g) throws RemoteException { 2 version++; Shape s = new ShapeServant( g, version); 3 thelist.addelement(s); return s; public Vector allshapes()throws RemoteException{... public int getversion() throws RemoteException { : UnicastRemoteObject - objects that live only as long as creating process 8 2: factory method - client can request creation of a new object 4-69 Stefan Leue 2005 Client program Java RMI import java.rmi.*; import java.rmi.server.*; import java.util.vector; public class ShapeListClient{ public static void main(string args[]){ System.setSecurityManager(new RMISecurityManager()); ShapeList ashapelist = null; try{ ashapelist = (ShapeList) Naming.lookup("//bruno.ShapeList") ; 1 Vector slist = ashapelist.allshapes(); 2 catch(remoteexception e) {System.out.println(e.getMessage()); catch(exception e) {System.out.println("Client: " + e.getmessage()); 8 polling loop: 1: look up remote reference 2: invoke allshapes() in remote object 4-70 Stefan Leue 2005

36 Java RMI Callbacks 8 avoid polling: server informs clients whenever an event occurs client creates remote object and provides method for server to call server allows clients to inform it of remote object references for their callback methods server calls clients using these methods whenever an event of interest occurs 8 problems clients may not revoke the callback requests before they exit, hence the list to be maintained in server may be inaccurate iuse leases instead need to make a series of synchronous RMI invocations for every event of interest may block server progress for some time 4-71 Stefan Leue 2005 CORBA Common Object Request Broker Architecture (CORBA) 8 standardized by the Object Management Group (OMG) 8 specifications of interfaces for open distributed object systems heterogeneous ihardware inetwork infrastructure ioperating systems iprogramming languages * multi-language system * definition of an Interface Definition Language that will be compiled into application programming language 4-72 Stefan Leue 2005

37 CORBA Common Object Request Broker Architecture (CORBA) 8 object request broker (ORB): support for transparent object invocation, similar to Java RMIs locate object activate object communicate request returning reply 8 important: clients and servants do not need to be objects, i.e., CORBA also works for non-oo languages like C, Cobol, etc. 8 numerous commercial and public domain implementations are available 8 remote object is called CORBA object 4-73 Stefan Leue 2005 CORBA Common Object Request Broker Architecture (CORBA) 8 static invocation: remote interface of the CORBA object is known at compile time code can be used to generate client stubs (proxies) and server skeletons 8 dynamic invocation: remote interface not known at compile time when a client without necessary proxy needs to invoke a CORBA object example iclient wishes to display information about all known CORBA objects in all servers ican t be expected that client has proxies for all object, since they are dynamically generated and deleted note: CORBA does not allow dynamic loading of proxies as Java RMI would 4-74 Stefan Leue 2005

38 CORBA client program client proxy for A ORB core implementation repository Request Reply interface repository ORB core object adapter server skeleton Servant A or dynamic invocation or dynamic skeleton CORBA Architecture 8 ORB core communications module allows ORB to be started and stopped remote object references to string conversion, and vice versa 4-75 Stefan Leue 2005 CORBA client program client proxy for A ORB core implementation repository Request Reply interface repository ORB core object adapter server skeleton Servant A or dynamic invocation or dynamic skeleton CORBA Architecture 8 Object adapter mediates between CORBA objects with IDL interfaces and the programming language interfaces icreates remote object references for CORBA objects idispatches RMIs via skeleton to servant class iactivates objects maintains object names igenerated at object activation, automatically or specified by user 4-76 Stefan Leue 2005

39 CORBA client program client proxy for A ORB core implementation repository Request Reply interface repository ORB core object adapter server skeleton Servant A or dynamic invocation or dynamic skeleton CORBA Architecture 8 Skeletons generated by IDL compiler scheduling marshaling/unmarshaling of arguments and exceptions 8 Client stubs/proxies in application language generated by IDL compiler from IDL interface definition marshaling/unmarshaling of arguments and exceptions 4-77 Stefan Leue 2005 CORBA client program client proxy for A ORB core implementation repository Request Reply interface repository ORB core object adapter server skeleton Servant A or dynamic invocation or dynamic skeleton CORBA Architecture 8 Implementation repository activation of registered servers on demand locating of servers currently running maintains object adapter names and locations for every CORBA object 4-78 Stefan Leue 2005

40 CORBA client program client proxy for A ORB core implementation repository Request Reply interface repository ORB core object adapter server skeleton Servant A or dynamic invocation or dynamic skeleton CORBA Architecture 8 Interface Repository provide information about registered IDL interfaces to clients inames of methods inames and types of method arguments can be used to emulate JAVA-type reflection iuseful if a client has no proxy for a remote reference it receives 4-79 Stefan Leue 2005 IOR format CORBA IDL interface type name Protocol and address details interface repository identifier IIOP host domain name CORBA Architecture - Remote Object References 8 Interoperable Object References (IOR) IDL Interface Type Name iname stored in Interface Repository, can be used at runtime to retrieve IDL definition of interface protocol and address specifics iinternet Inter-Orb Protocol (IIOP) uses TCP/IP Object Identification 8 Transient IORs persist only as long as hosting process contains address details of server hosting object 8 Persistent IORs survive inactivation periods of CORBA objects contains address details of implementation repository Object key port number adapter name object name 4-80 Stefan Leue 2005

41 CORBA client program client proxy for A ORB core implementation repository Request Reply interface repository ORB core object adapter server skeleton Servant A or dynamic invocation or dynamic skeleton CORBA Architecture - Remote Object References 8 Usage of IOR to locate servant representing CORBA object transient IORs iserver ORB core receives request containing adapter name iuses adapter name to locate adapter iadapter uses object name to locate servant 4-81 Stefan Leue 2005 CORBA client program client proxy for A ORB core implementation repository Request Reply interface repository ORB core object adapter server skeleton Servant A or dynamic invocation or dynamic skeleton CORBA Architecture - Remote Object References 8 Usage of IOR to locate servant representing CORBA object persistent IORs iimlementation Repository receives request and extracts object adapter name iif necessary, activates object at specified host iir returns address details (including object adapter name and object name) to the client ORB, which uses them for the RMI request messages iserver ORB core locates object adapter, adapter uses object name to locate servant 4-82 Stefan Leue 2005

42 CORBA CORBA Object Model 8 object model similar to the generic distributed object model discussed earlier 8 CORBA object (remote object) implements IDL interface has remote object reference capable of responding to remote invocations 8 CORBA does not know the concepts of object and class implementation languages can be non-oo impossible to define classes in CORBA IDL iuse of structs instead * components similar to instance variables of a class * does not have methods impossible to pass classes as arguments or results 4-83 Stefan Leue 2005 CORBA CORBA IDL 8 interface specifies names and methods that clients can use (invoke) 8 extended subset of C++ syntax 8 IDL modules logical grouping of interface and type definitions defines naming scope 8 IDL interface methods that are available in CORBA objects implementing the interface 8 IDL methods specify signatures parameters are labeled as in, out and inout iin passed with request message from client to server iout passed with reply message from server to client oneway indicates that client will not be blocked when invoking this method ithese methods use maybe invocation semantics raises: user-defined exceptions 4-84 Stefan Leue 2005

43 CORBA IDL 8 IDL types always passed by value CORBA Type Examples Use sequence string typedef sequence <Shape, 100> All; typedef sequence <Shape> All bounded and unbounded sequences of Shapes String name; typedef string<8> SmallString; unbounded and bounded sequences of characters Defines a type for a variable-length sequence of elements of a specified IDL type. An upper bound on the length may be specified. Defines a sequences of characters, terminated by the null character. An upper bound on the length may be specified. array typedef octet uniqueid[12]; typedef GraphicalObject GO[10][8] Defines a type for a multi-dimensional fixed-length sequence of elements of a specified IDL type. continued Stefan Leue 2005 CORBA CORBA IDL 8 IDL types Type Examples Use record struct GraphicalObject { string type; Rectangle enclosing; boolean isfilled; ; enumerated enum Rand (Exp, Number, Name); union union Exp switch (Rand) { case Exp: string vote; case Number: long n; case Name: string s; ; 8 special type Object values are remote object references Defines a type for a record containing a group of related entities. Structs are passed by value in arguments and results. The enumerated type in IDL maps a type name onto a small set of integer values. The IDL discriminated union allows one of a given set of types to be passed as an argument. The header is parameterized by an enum, which specifies which member is in use Stefan Leue 2005