System Models

Contents Introduction Physical models Architectural models Fundamental models

Contents Introduction Physical models Architectural models Fundamental models

Introduction Distributed system design can be explained through three different models: Physical models – models that capture the hardware composition of a system in terms of computer and their interconnecting networks Architectural models – models that describe the system in terms of the computational and communication tasks performed by its computational elements Fundamental models – models that describe an abstraction of individual items in distributed systems. Three models; interaction, failure, and security models

Contents Introduction Physical models Architectural models Fundamental models

Physical models Basic physical models - baseline physical model Model that shows hardware and software components located at networked computers communicate and coordinate their actions by passing message Three generations of distributed systems: Early distributed systems Internet-scale distributed systems Contemporary distributed systems

Physical models

Source: Google

Source: Google

Contents Introduction Physical models Architectural models Fundamental models

Architectural models Architecture? Why architecture? The structure of a system specifying its components and their interrelationships Why architecture? To ensure that the structure will meet the current and future demands on it To provide a reliable, manageable, adaptable and cost-effective system

Architectural models Architectural elements: How to understand the fundamental building blocks of a distributed system? What are the entities that are communicating in the distributed system (communicating entities)? How do they communicate, or, what communication paradigm is used (communication paradigms)? What roles and responsibilities do they have in the overall architecture (roles and responsibilities)? How do they mapped on to the physical distributed architecture (what is their placement)?

Architectural models Communicating entities: Processes Objects Components Web services

Architectural models Communication paradigms Interprocess communication – low-level process support. E.g. message passing primitives, direct access to API, multicast communication Remote invocation – common communication paradigm in distributed systems. Two-way exchange between communicating entities, common techniques; RPC, RMI, request-reply protocols Indirect communication– E.g. group communication, publish-subscribe systems, message queues, tuple spaces, distributed shared memory

Architectural models

Architectural models Roles and responsibilities Client-server Peer-to-peer

Architectural models Clients invoke individual servers

Architectural models Peer-to-peer architecture

Architectural models A service provided by multiple servers

Architectural models Placement strategies: Mapping of services to multiple servers – several servers process services in separate hosts. Example: Sun Network Information Service (NIS) Caching – storing recently used data objects. Example: web proxy server Mobile code – Code can be downloaded and run on user’s machine. Example: Applet Mobile agents – Code and data travel in a network and performing specific tasks on behalf of the users. Example: Web crawler program

Architectural models Web proxy server

Architectural models Web applets

Architectural models Architectural patterns: Layering –complex system is partitioned into a number of layers. The top layer utilizes the services of the lower layer. Tiered architecture – complementary to layering, organizes the functionality of the given layer and place it in appropriate server (physical nodes). Thin clients – software layer that supports window-based user interface in remote computers. Other patterns : e.g. proxy, brokerage, reflection

Architectural models Software and hardware service layers in distributed systems

Architectural models Two-tier and three-tier architectures

Architectural models Thin clients and compute servers Thin Client Application Process Network computer or PC Compute server network Thin clients and compute servers

Architectural models Middleware

Source: http://www. locher

Source: http://ntl.bts.gov/lib/jpodocs/repts_te/13777.html

Source: http://www.ecosys.net/ecosys-epc/technology-architecture/

Contents Introduction Physical models Architectural models Fundamental models

Fundamental models

Fundamental models 3 categories of fundamental models: Interaction Failure Security

Fundamental models Interaction model Process interaction in a distributed system are affected by: Performance of communication channels: latency, bandwidth, jitter Computer clocks – Clock drift rate Latency: delay between sending and receipt of a message including Network access time. Time for first bit transmitted through a network to reach its destination. Processing time within the sending and receiving processes. Bandwidth: total amount of information transmitted per time unit. Jitter: variation in the time taken to deliver multiple messages of the same type (relevant to multimedia data). Clock drift rate refers to the relative amount a computer clock differs from a perfect reference clock.

Fundamental models Failure model defines the ways in which failure may occur in order to provide an understanding of its effects. Categories of failures: Omission failures - Process or channel failed to do something Arbitrary failures - Any type of error can occur in processes or channels (worst) Timing failures - Applicable only to synchronous distributed systems where time limits may not be met

Fundamental models Processes and channels send receive m Process p Process q Communication channel send Outgoing message buffer Incoming message buffer receive m Processes and channels

Fundamental models Omission and arbitrary failures Class of failure Affects Description Fail-stop Process Process halts and remains halted. Other processes may detect this state. Crash not be able to detect this state. Omission Channel A message inserted in an outgoing message buffer never arrives at the other end’s incoming message buffer. Send-omission A process completes a send, but the message is not put in its outgoing message buffer. Receive-omission A message is put in a process’s incoming message buffer, but that process does not receive it. Arbitrary (Byzantine) Process or channel Process/channel exhibits arbitrary behaviour: it may send/transmit arbitrary messages at arbitrary times, commit omissions; a process may stop or take an incorrect step. Omission and arbitrary failures

Fundamental models Timing failures Class of Failure Affects Description Clock Process Process’s local clock exceeds the bounds on its rate of drift from real time. Performance Process exceeds the bounds on the interval between two steps. Channel A message’s transmission takes longer than the stated bound. Timing failures

Fundamental models Security model - Secure processes and channels and protect objects encapsulated against unauthorized access. Protecting access to objects - Access rights, authentication of clients Protecting processes and interactions Threats to processes: problem of unauthenticated requests / replies. e.g., "man in the middle" Threats to communication channels: enemy may copy, alter or inject messages as they travel across network. Use of “secure” channels, based on cryptographic methods.

Fundamental models Objects and principals

Fundamental models The enemy m m’ p q Copy of The enemy Process Communication channel Copy of m Process p q The enemy m’ The enemy

Fundamental models Secure channels B A p q Principal Process

Topics INTRODUCTION The API for the INTERNET PROTOCOLS EXTERNAL DATA REPRESENTATION CLIENT-SERVER COMMUNICATION GROUP COMMUNICATION

Introduction The java API for interprocess communication in the internet provides both datagram and stream communication. The two communication patterns that are most commonly used in distributed programs: Client-Server communication The request and reply messages provide the basis for remote method invocation (RMI) or remote procedure call (RPC).

Introduction Group communication The same message is sent to several processes.

This chapter is concerned with middleware. Introduction This chapter is concerned with middleware. Figure 1. Middleware layers Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005

Remote Method Invocation (RMI) Introduction Remote Method Invocation (RMI) It allows an object to invoke a method in an object in a remote process. E.g. CORBA and Java RMI Remote Procedure Call (RPC) It allows a client to call a procedure in a remote server. Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005

Introduction The application program interface (API) to UDP provides a message passing abstraction. Message passing is the simplest form of interprocess communication. API enables a sending process to transmit a single message to a receiving process. The independent packets containing theses messages are called datagrams. In the Java and UNIX APIs, the sender specifies the destination using a socket. Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005

Introduction Socket is an indirect reference to a particular port used by the destination process at a destination computer. The application program interface (API) to TCP provides the abstraction of a two-way stream between pairs of processes. The information communicated consists of a stream of data items with no message boundaries.

Introduction Request-reply protocols are designed to support client-server communication in the form of either RMI or RPC. Group multicast protocols are designed to support group communication.

Introduction Group multicast is a form of interprocess communication in which one process in a group of processes transmits the same message to all members of the group.

The API for the Internet Protocols The CHARACTERISTICS of INTERPROCESS COMMUNICATION SOCKET UDP DATAGRAM COMMUNICATION TCP STREAM COMMUNICATION

The Characteristics of Interprocess Communication SYSTEM MODEL The Characteristics of Interprocess Communication Synchronous and asynchronous communication In the synchronous form, both send and receive are blocking operations. In the asynchronous form, the use of the send operation is non-blocking and the receive operation can have blocking and non-blocking variants.

The Characteristics of Interprocess Communication Message destinations A local port is a message destination within a computer, specified as an integer. A port has an exactly one receiver but can have many senders.

The Characteristics of Interprocess Communication Reliability A reliable communication is defined in terms of validity and integrity. A point-to-point message service is described as reliable if messages are guaranteed to be delivered despite a reasonable number of packets being dropped or lost. For integrity, messages must arrive uncorrupted and without duplication.

The Characteristics of Interprocess Communication Ordering Some applications require that messages be delivered in sender order.

Sockets Internet IPC mechanism of Unix and other operating systems (BSD Unix, Solaris, Linux, Windows NT, Macintosh OS) Processes in the above OS can send and receive messages via a socket. Sockets need to be bound to a port number and an internet address in order to send and receive messages. Each socket has a transport protocol (TCP or UDP).

Sockets 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. Processes cannot share ports (exception: TCP multicast).

Sockets Both forms of communication, UDP and TCP, use the socket abstraction, which provides and endpoint for communication between processes. Interprocess communication consists of transmitting a message between a socket in one process and a socket in another process. (Figure 2)

Sockets Figure 2. Sockets and ports

UDP Datagram Communication UDP datagram properties No guarantee of order preservation Message loss and duplications are possible Necessary steps Creating a socket Binding a socket to a port and local Internet address A client binds to any free local port A server binds to a server port

UDP Datagram Communication Receive method It returns Internet address and port of sender, plus message.

UDP Datagram Communication Issues related to datagram communications are: Message size IP allows for messages of up to 216 bytes. Most implementations restrict this to around 8 kbytes. Any application requiring messages larger than the maximum must fragment. If arriving message is too big for array allocated to receive message content, truncation occurs.

UDP Datagram Communication Blocking Send: non-blocking upon arrival, message is placed in a queue for the socket that is bound to the destination port. Receive: blocking Pre-emption by timeout possible If process wishes to continue while waiting for packet, use separate thread

UDP Datagram Communication Timeout Receive from any

UDP Datagram Communication UDP datagrams suffer from following failures: Omission failure Messages may be dropped occasionally, Ordering

Java API for UDP Datagrams The Java API provides datagram communication by two classes: DatagramPacket It provides a constructor to make an array of bytes comprising: Message content Length of message Internet address Local port number It provides another similar constructor for receiving a message. array of bytes containing message | length of message| Internet address | port number|

Java API for UDP Datagrams DatagramSocket This class supports sockets for sending and receiving UDP datagram. It provides a constructor with port number as argument. No-argument constructor is used to choose a free local port. DatagramSocket methods are: send and receive setSoTimeout connect

Java API for UDP Datagrams Example – The process creates a socket, sends a message to a server at port 6789 and waits to receive a reply. (Figure 3)

Java API for UDP Datagrams 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());} } finally{if (aSocket !=null)aSocket.close()} } Figure 3. UDP client sends a message to the server and gets a reply

Java API for UDP Datagrams Example – The process creates a socket, bound to its server port 6789 and waits to receive a request message from a client. (Figure 4)

Java API for UDP datagrams 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()} Figure 4. UDP server repeatedly receives a request and sends it back to the client

TCP Stream Communication The API to the TCP protocol provides the abstraction of a stream of bytes to be written to or read from. Characteristics of the stream abstraction: Message sizes Lost messages Flow control Message destinations

TCP Stream Communication Issues related to stream communication: Matching of data items Blocking Threads

TCP Stream Communication Use of TCP Many services that run over TCP connections, with reserved port number are: HTTP (Hypertext Transfer Protocol) FTP (File Transfer Protocol) Telnet SMTP (Simple Mail Transfer Protocol)

TCP Stream Communication Java API for TCP streams The Java interface to TCP streams is provided in the classes: ServerSocket It is used by a server to create a socket at server port to listen for connect requests from clients. Socket It is used by a pair of processes with a connection. The client uses a constructor to create a socket and connect it to the remote host and port of a server. It provides methods for accessing input and output streams associated with a socket. Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005

Java API for UDP Datagrams Example – The client process creates a socket, bound to the hostname and server port 6789. (Figure 5)

Java API for UDP Datagrams Example – The server process opens a server socket to its server port 6789 and listens for connect requests. (Figure 6,7)

TCP Stream Communication 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 socket:"+e.getMessage());} Figure 6. TCP server makes a connection for each client and then echoes the client’s request

TCP 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(); out.writeUTF(data); } catch (EOFException e){System.out.println("EOF:"+e.getMessage()); } catch (IOException e) {System.out.println("readline:"+e.getMessage());} } finally {try{clientSocket.close();}catch(IOException e){/*close failed*/}} Figure 7. TCP server makes a connection for each client and then echoes the client’s request

External Data Representation The information stored in running programs is represented as data structures, whereas the information in messages consists of sequences of bytes. Irrespective of the form of communication used, the data structure must be converted to a sequence of bytes before transmission and rebuilt on arrival.

External Data Representation External Data Representation is an agreed standard for the representation of data structures and primitive values. Data representation problems are: Using agreed external representation, two conversions necessary Using sender’s or receiver’s format and convert at the other end

External Data Representation Marshalling Marshalling is the process of taking a collection of data items and assembling them into a form suitable for transmission in a message. Unmarshalling Unmarshalling is the process of disassembling a collection of data on arrival to produce an equivalent collection of data items at the destination.

External Data Representation Three approaches to external data representation and marshalling are: CORBA Java’s object serialization XML

External Data Representation Marshalling and unmarshalling activities is usually performed automatically by middleware layer. Marshalling is likely error-prone if carried out by hand. Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005

CORBA Common Data Representation (CDR) CORBA CDR is the external data representation defined with CORBA 2.0. It consists 15 primitive types: Short (16 bit) Long (32 bit) Unsigned short Unsigned long Float(32 bit) Double(64 bit) Char Boolean(TRUE,FALSE) Octet(8 bit) Any(can represent any basic or constructed type) Composite type are shown in Figure 8. Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005

CORBA Common Data Representation (CDR) Figure 8. CORBA CDR for constructed types Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005

CORBA Common Data Representation (CDR) Constructed types: The primitive values that comprise each constructed type are added to a sequence of bytes in a particular order, as shown in Figure 8.

CORBA Common Data Representation (CDR) Figure 9 shows a message in CORBA CDR that contains the three fields of a struct whose respective types are string, string, and unsigned long.

CORBA Common Data Representation (CDR) example: struct with value {‘Smith’, ‘London’, 1934} Figure 9. CORBA CDR message

Java object serialization In Java RMI, both object and primitive data values may be passed as arguments and results of method invocation. An object is an instance of a Java class. Example, the Java class equivalent to the Person struct Public class Person implements Serializable { Private String name; Private String place; Private int year; Public Person(String aName ,String aPlace, int aYear) { name = aName; place = aPlace; year = aYear; } //followed by methods for accessing the instance variables

Java object serialization The serialized form is illustrated in Figure 10. Figure 10. Indication of Java serialization form

Remote Object References Remote object references are needed when a client invokes an object that is located on a remote server. A remote object reference is passed in the invocation message to specify which object is to be invoked. Remote object references must be unique over space and time.

Remote Object References In general, may be many processes hosting remote objects, so remote object referencing must be unique among all of the processes in the various computers in a distributed system. generic format for remote object references is shown in Figure 11. Figure 11. Representation of a remote object references Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005

Remote Object References 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) Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005

Client-Server Communication The client-server communication is designed to support the roles and message exchanges in typical client-server interactions. In the normal case, request-reply communication is synchronous because the client process blocks until the reply arrives from the server. Asynchronous request-reply communication is an alternative that is useful where clients can afford to retrieve replies later. Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005

Client-Server Communication 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 are transferred

Client-Server Communication The request-reply protocol was based on a trio of communication primitives: doOperation, getRequest, and sendReply shown in Figure 12.

Client-Server Communication The request-reply protocol is shown in Figure 12. Figure 12. Request-reply communication

Client-Server Communication The designed request-reply protocol matches requests to replies. If UDP datagrams are used, the delivery guarantees must be provided by the request-reply protocol, which may use the server reply message as an acknowledgement of the client request message. Figure 13 outlines the three communication primitives.

Client-Server Communication Figure 13. Operations of the request-reply protocol

Client-Server Communication The information to be transmitted in a request message or a reply message is shown in Figure 14. Figure 14. Request-reply message structure

Client-Server Communication In a protocol message The first field indicates whether the message is a request or a reply message. The second field request id contains a message identifier. The third field is a remote object reference . The forth field is an identifier for the method to be invoked.

Client-Server Communication Message identifier A message identifier consists of two parts: A requestId, which is taken from an increasing sequence of integers by the sending process An identifier for the sender process, for example its port and Internet address.

Client-Server Communication Failure model of the request-reply protocol If the three primitive doOperation, getRequest, and sendReply are implemented over UDP datagram, they have the same communication failures. Omission failure Messages are not guaranteed to be delivered in sender order.

Client-Server Communication RPC exchange protocols Three protocols are used for implementing various types of RPC. The request (R) protocol. The request-reply (RR) protocol. The request-reply-acknowledge (RRA) protocol. (Figure 15)

Client-Server Communication Figure 15. RPC exchange protocols

Client-Server Communication In the R protocol, a single request message is sent by the client to the server. The R protocol may be used when there is no value to be returned from the remote method. The RR protocol is useful for most client-server exchanges because it is based on request-reply protocol. RRA protocol is based on the exchange of three messages: request-reply-acknowledge reply.

Client-Server Communication HTTP: an example of a request-reply protocol HTTP is a request-reply protocol for the exchange of network resources between web clients and web servers.

Client-Server Communication HTTP protocol steps are: Connection establishment between client and server at the default server port or at a port specified in the URL client sends a request server sends a reply connection closure

Client-Server Communication HTTP 1.1 uses persistent connections. Persistent connections are connections that remains open over a series of request-reply exchanges between client and server. Resources can have MIME-like structures in arguments and results.

Client-Server Communication A Mime type specifies a type and a subtype, for example: text/plain text/html image/gif image/jpeg

Client-Server Communication HTTP methods GET Requests the resource, identified by URL as argument. If the URL refers to data, then the web server replies by returning the data If the URL refers to a program, then the web server runs the program and returns the output to the client. Figure 16. HTTP request message

Client-Server Communication HEAD This method is similar to GET, but only meta data on resource is returned (like date of last modification, type, and size)

Client-Server Communication POST Specifies the URL of a resource (for instance, a server program) that can deal with the data supplied with the request. This method is designed to deal with: Providing a block of data to a data-handling process Posting a message to a bulletin board, mailing list or news group. Extending a dataset with an append operation

Client-Server Communication PUT Supplied data to be stored in the given URL as its identifier. DELETE The server deletes an identified resource by the given URL on the server. OPTIONS A server supplies the client with a list of methods. It allows to be applied to the given URL

Client-Server Communication TRACE The server sends back the request message

Client-Server Communication A reply message specifies The protocol version A status code Reason Some headers An optional message body Figure 17. HTTP reply message

A multicast operation is more appropriate. Group Communication The pairwise exchange of messages is not the best model for communication from one process to a group of other processes. A multicast operation is more appropriate. Multicast operation is an operation that sends a single message from one process to each of the members of a group of processes. Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005

Multicasting has the following characteristics: Group Communication The simplest way of multicasting, provides no guarantees about message delivery or ordering. Multicasting has the following characteristics: Fault tolerance based on replicated services A replicated service consists of a group of servers. Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005

Group Communication Client requests are multicast to all the members of the group, each of which performs an identical operation. Finding the discovery servers in spontaneous networking Multicast messages can be used by servers and clients to locate available discovery services in order to register their interfaces or to look up the interfaces of other services in the distributed system. Couloris,Dollimore and Kindberg Distributed Systems: Concepts & Design Edn. 4 , Pearson Education 2005

Group Communication Better performance through replicated data Data are replicated to increase the performance of a service. Propagation of event notifications Multicast to a group may be used to notify processes when something happens.

Group Communication IP multicast IP multicast is built on top of the Internet protocol, IP. IP multicast allows the sender to transmit a single IP packet to a multicast group. A multicast group is specified by class D IP address for which first 4 bits are 1110 in IPv4.

Group Communication The membership of a multicast group is dynamic. A computer belongs to a multicast group if one or more processes have sockets that belong to the multicast group.

Group Communication The following details are specific to IPv4: Multicast IP routers IP packets can be multicast both on local network and on the wider Internet. Local multicast uses local network such as Ethernet. To limit the distance of propagation of a multicast datagram, the sender can specify the number of routers it is allowed to pass- called the time to live, or TTL for short.

Group Communication Multicast address allocation Multicast addressing may be permanent or temporary. Permanent groups exist even when there are no members. Multicast addressing by temporary groups must be created before use and cease to exit when all members have left. The session directory (sd) program can be used to start or join a multicast session. session directory provides a tool with an interactive interface that allows users to browse advertised multicast sessions and to advertise their own session, specifying the time and duration.

Group Communication Java API to IP multicast The Java API provides a datagram interface to IP multicast through the class MulticastSocket, which is a subset of DatagramSocket with the additional capability of being able to join multicast groups. The class MulticastSocket provides two alternative constructors , allowing socket to be creative to use either a specified local port, or any free local port. (Figure 18)

Group Communication import java.net.*; import java.io.*; public class MulticastPeer{ public static void main(String args[]){ // args give message contents and destination multicast group (e.g. "228.5.6.7") MulticastSocket s =null; try { InetAddress group = InetAddress.getByName(args[1]); s = new MulticastSocket(6789); s.joinGroup(group); byte [] m = args[0].getBytes(); DatagramPacket messageOut = new DatagramPacket(m, m.length, group, 6789); s.send(messageOut); byte[] buffer = new byte[1000]; for(int i=0; i< 3;i++) { // get messages from others in group DatagramPacket messageIn = new DatagramPacket(buffer, buffer.length); s.receive(messageIn); System.out.println("Received:" + new String(messageIn.getData())); } s.leaveGroup(group); }catch (SocketException e){System.out.println("Socket: " + e.getMessage()); }catch (IOException e){System.out.println("IO: " + e.getMessage()); }finally {if(s != null) s.close();} Figure 18. Multicast peer joins a group and sends and receives datagrams

Group Communication A process can join a multicast group with a given multicast address by invoking the joinGroup method of its multicast socket. A process can leave a specified group by invoking the leaveGroup method of its multicast socket. The Java API allows the TTL to be set for a multicast socket by means of the setTimeToLive method. The default is 1, allowing the multicast to propagate only on the local network.

Figure 4.15 Types of overlay table continues on the next slide Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 4.15 (continued) Types of overlay Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 4.16 Skype overlay architecture Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 4.17 An overview of point-to-point communication in MPI Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 4.18 Selected send operations in MPI Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Remote invocation

Figure 5.1 Middleware layers Applications Remote invocation, indirect communication Middleware Underlying interprocess communication primitives: layers Sockets, message passing, multicast support, overlay networks UDP and TCP Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 5.2 Request-reply communication Client Server Request doOperation message getRequest select object (wait) execute method Reply message sendReply (continuation) Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 5.3 Operations of the request-reply protocol public byte[] doOperation (RemoteRef s, int operationId, byte[] arguments) sends a request message to the remote server and returns the reply. The arguments specify the remote server, the operation to be invoked and the arguments of that operation. public byte[] getRequest (); acquires a client request via the server port. public void sendReply (byte[] reply, InetAddress clientHost, int clientPort); sends the reply message reply to the client at its Internet address and port. Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 5.4 Request-reply message structure messageType requestId remoteReference operationId arguments int (0=Request, 1= Reply) int RemoteRef int or Operation array of bytes Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 5.5 RPC exchange protocols Name Messages sent by Client Server Client R Request R R Request Reply R R A Request Reply Acknowledge reply Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 5.6 HTTP request message GET //www.dcs.qmw.ac.uk/index.html HTTP/ 1.1 URL or pathname method HTTP version headers message body Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 5.7 HTTP Reply message 200 OK resource data HTTP version status code reason headers message body Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 5.8 CORBA IDL example // 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(); }; Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 5.9 Call semantics Fault tolerance measures Call semantics Retransmit request message Duplicate filtering Re-execute procedure or retransmit reply No Yes Not applicable Retransmit reply At-most-once At-least-once Maybe Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 5.10 Role of client and server stub procedures in RPC Request Reply Communication module dispatcher service client stub server stub procedure client process server process program Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 5.11 Files interface in Sun 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; }; program FILEREADWRITE { version VERSION { void WRITE(writeargs)=1; 1 Data READ(readargs)=2; 2 }=2; } = 9999; Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 5.12 Remote and local method invocations B C D E F Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 5.13 A remote object and its remote interface Data implementation object { of methods Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 5.14 Instantiation of remote objects Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 5.15 The role of proxy and skeleton in remote method invocation Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 5.16 Java Remote interfaces Shape and ShapeList 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; Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 5.17 The Naming class of Java RMIregistry 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 15.18, 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.20 line 1. A remote object reference is returned. String [] list() This method returns an array of Strings containing the names bound in the registry. Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 5.18 Java class ShapeListServer with main method 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());} } Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 5.19 Java class ShapeListServant implements interface 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 private int version; public ShapeListServant()throws RemoteException{...} public Shape newShape(GraphicalObject g) throws RemoteException { 1 version++; Shape s = new ShapeServant( g, version); 2 theList.addElement(s); return s; } public Vector allShapes()throws RemoteException{...} public int getVersion() throws RemoteException { ... } Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 5.20 Java client of ShapeList 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());} } Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 5.21 Classes supporting Java RMI RemoteServer UnicastRemoteObject <servant class> Activatable RemoteObject Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Indirect Communication

Figure 6.1 Space and time coupling in distributed systems Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 6.2 Open and closed groups Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Figure 6.3 The role of group membership management Join Group address expansion Multicast communication send Fail Group membership management Leave Process group Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 6.4 The architecture of JGroups Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 6.5 Java class FireAlarmJG import org.jgroups.JChannel; public class FireAlarmJG { public void raise() { try { JChannel channel = new JChannel(); channel.connect("AlarmChannel"); Message msg = new Message(null, null, "Fire!"); channel.send(msg); } catch(Exception e) { Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 6.6 Java class FireAlarmConsumerJG import org.jgroups.JChannel; public class FireAlarmConsumerJG { public String await() { try { JChannel channel = new JChannel(); channel.connect("AlarmChannel"); Message msg = (Message) channel.receive(0); return (String) msg.GetObject(); } catch(Exception e) { return null; } Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 6.7 Dealing room system Dealer’s computer Information provider Dealer External source Notification Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Figure 6.8 The publish-subscribe paradigm Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Figure 6.9 A network of brokers Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Figure 6.10 The architecture of publish-subscribe systems Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Figure 6.11 Filtering-based routing upon receive publish(event e) from node x 1 matchlist := match(e, subscriptions) 2 send notify(e) to matchlist; 3 fwdlist := match(e, routing); 4 send publish(e) to fwdlist - x; 5 upon receive subscribe(subscription s) from node x 6 if x is client then 7 add x to subscriptions; 8 else add(x, s) to routing; 9 send subscribe(s) to neighbours - x; 10 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Figure 6.12 Rendezvous-based routing upon receive publish(event e) from node x at node i rvlist := EN(e); if i in rvlist then begin matchlist :=match(e, subscriptions); send notify(e) to matchlist; end send publish(e) to rvlist - i; upon receive subscribe(subscription s) from node x at node i rvlist := SN(s); if i in rvlist then add s to subscriptions; else send subscribe(s) to rvlist - i; Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Figure 6.13 Example publish-subscribe system Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Figure 6.14 The message queue paradigm Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Figure 6.15 A simple networked topology in WebSphere MQ Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Figure 6.16 The programming model offered by JMS Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Figure 6.17 Java class FireAlarmJMS import javax.jms.*; import javax.naming.*; public class FireAlarmJMS { public void raise() { try { 1 Context ctx = new InitialContext(); 2 TopicConnectionFactory topicFactory = 3 (TopicConnectionFactory)ctx.lookup ("TopicConnectionFactory"); 4 Topic topic = (Topic)ctx.lookup("Alarms"); 5 TopicConnection topicConn = 6 topicConnectionFactory.createTopicConnection(); 7 TopicSession topicSess = topicConn.createTopicSession(false, 8 Session.AUTO_ACKNOWLEDGE); 9 TopicPublisher topicPub = topicSess.createPublisher(topic); 10; TextMessage msg = topicSess.createTextMessage(); 11 msg.setText("Fire!"); 12 topicPub.publish(message); 13 } catch (Exception e) { 14 } 15 } Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Figure 6.18 Java class FireAlarmConsumerJMS import javax.jms.*; import javax.naming.*; public class FireAlarmConsumerJMS public String await() { try { 1 Context ctx = new InitialContext(); 2 TopicConnectionFactory topicFactory = 3 (TopicConnectionFactory)ctx.lookup("TopicConnectionFactory"); 4 Topic topic = (Topic)ctx.lookup("Alarms"); 5 TopicConnection topicConn = 6 topicConnectionFactory.createTopicConnection(); 7 TopicSession topicSess = topicConn.createTopicSession(false, 8 Session.AUTO_ACKNOWLEDGE); 9 TopicSubscriber topicSub = topicSess.createSubscriber(topic); 10 topicSub.start(); 11 TextMessage msg = (TextMessage) topicSub.receive(); 12 return msg.getText(); 13 } catch (Exception e) { 14 return null; 15 }16 } Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Figure 6.19 The distributed shared memory abstraction Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Figure 6.20 The tuple space abstraction Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Figure 6.21 (1) Replication and the tuple space operations [Xu and Liskov 1989] write 1. The requesting site multicasts the write request to all members of the view; 2. On receiving this request, members insert the tuple into their replica and acknowledge this action; 3. Step 1 is repeated until all acknowledgements are received. read 1. The requesting site multicasts the read request to all members of the view; 2. On receiving this request, a member returns a matching tuple to the requestor; 3. The requestor returns the first matching tuple received as the result of the operation (ignoring others); 4. Step 1 is repeated until at least one response is received. continued on next slide Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Figure 6.21 (continued) Replication and the tuple space operations [Xu and Liskov 1989] take Phase 1: Selecting the tuple to be removed 1. The requesting site multicasts the take request to all members of the view; 2. On receiving this request, each replica acquires a lock on the associated tuple set and, if the lock cannot be acquired, the take request is rejected; 3. All accepting members reply with the set of all matching tuples; 4. Step 1 is repeated until all sites have accepted the request and responded with their set of tuples and the intersection is non-null; 5. A particular tuple is selected as the result of the operation (selected randomly from the intersection of all the replies); 6. If only a minority accept the request, this minority are asked to release their locks and phase 1 repeats. Phase 2: Removing the selected tuple 1. The requesting site multicasts a remove request to all members of the view citing the tuple to be removed; 2. On receiving this request, members remove the tuple from their replica, send an acknowledgement and release the lock; 3. Step 1 is repeated until all acknowledgements are received. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Figure 6.22 Partitioning in the York Linda Kernel Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Figure 6.23 The JavaSpaces API Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Figure 6.24 Java class AlarmTupleJS import net.jini.core.entry.*; public class AlarmTupleJS implements Entry { public String alarmType; public AlarmTupleJS() { } } public AlarmTupleJS(String alarmType) { this.alarmType = alarmType;} Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Figure 6.25 Java class FireAlarmJS import net.jini.space.JavaSpace; public class FireAlarmJS { public void raise() { try { JavaSpace space = SpaceAccessor.findSpace("AlarmSpace"); AlarmTupleJS tuple = new AlarmTupleJS("Fire!"); space.write(tuple, null, 60*60*1000); catch (Exception e) { } Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Figure 16.26 Java class FireAlarmReceiverJS import net.jini.space.JavaSpace; public class FireAlarmConsumerJS { public String await() { try { JavaSpace space = SpaceAccessor.findSpace(); AlarmTupleJS template = new AlarmTupleJS("Fire!"); AlarmTupleJS recvd = (AlarmTupleJS) space.read(template, null, Long.MAX_VALUE); return recvd.alarmType; } catch (Exception e) { return null; Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Figure 6.27 Summary of indirect communication styles Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Figure 8.1 Distributed objects Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012 186

Figure 8.2 IDL interfaces Shape and ShapeList struct Rectangle{ 1 long width; long height; long x; long y; } ; struct GraphicalObject { 2 string type; Rectangle enclosing; boolean isFilled; }; interface Shape { 3 long getVersion() ; GraphicalObject getAllState() ; // returns state of the GraphicalObject }; typedef sequence <Shape, 100> All; 4 interface ShapeList { 5 exception FullException{ }; 6 Shape newShape(in GraphicalObject g) raises (FullException); 7 All allShapes(); // returns sequence of remote object references 8 long getVersion() ; }; Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 8.3 IDL module Whiteboard struct Rectangle{ ...} ; struct GraphicalObject { ...}; interface Shape { typedef sequence <Shape, 100> All; interface ShapeList { }; Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 8.4 IDL constructed types – 1 Examples Use sequence typedef sequence <Shape, 100> All; Defines a type for a variable-length typedef sequence <Shape> All sequence of elements of a specified bounded and unbounded sequences IDL type. An upper bound on the o f Shapes length may be specified. string String name; Defines a sequences of characters, typedef string<8> SmallString; terminated by the null character. An unbounded and bounded upper bound on the length may be sequences of characters specified. array typedef octet uniqueId[12]; Defines a type for a multi-dimensional fixed-length sequence of elements of a typedef GraphicalObject GO[10][8] specified IDL type. this figure continues on the next slide Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 8.4 IDL constructed types – 2 Examples Use record struct GraphicalObject { Defines a type for a record containing a string type; group of related entities. Structs are Rectangle enclosing; passed by value in arguments and boolean isFilled; results. }; enumerated enum Rand The enumerated type in IDL maps a (Exp, Number, Name); type name onto a small set of integer values. union union Exp switch (Rand) { The IDL discriminated union allows case Exp: string vote; one of a given set of types to be passed case Number: long n; as an argument. The header is case Name: string s; parameterized by an enum , which specifies which member is in use. }; Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 8.5 The main components of the CORBA architecture client server proxy or dynamic invocation implementation repository object adapter ORB skeleton or dynamic skeleton program interface Request Reply core for A Servant A Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 8.6 CORBA Services (1) this figure continues on the next slide Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 8.6 CORBA Services (continued) Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012 193

Figure 8.7 Java interfaces generated by idlj from CORBA interface ShapeList public interface ShapeListOperations { Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException; Shape[] allShapes(); int getVersion(); } public interface ShapeList extends ShapeListOperations, org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity { } Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 8.8 ShapeListServant class of the Java server program for CORBA interface ShapeList import org.omg.CORBA.*; import org.omg.PortableServer.POA; class ShapeListServant extends ShapeListPOA { private POA theRootpoa; private Shape theList[]; private int version; private static int n=0; public ShapeListServant(POA rootpoa){ theRootpoa = rootpoa; // initialize the other instance variables } // continued on the next slide Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 8.8 continued public Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException { 1 version++; Shape s = null; ShapeServant shapeRef = new ShapeServant( g, version); try { org.omg.CORBA.Object ref = theRoopoa.servant_to_reference(shapeRef); 2 s = ShapeHelper.narrow(ref); } catch (Exception e) {} if(n >=100) throw new ShapeListPackage.FullException(); theList[n++] = s; return s; } public Shape[] allShapes(){ ... } public int getVersion() { ... } Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 8.9 Java class ShapeListServer import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; import org.omg.CORBA.*; import org.omg.PortableServer.*; public class ShapeListServer { public static void main(String args[]) { try{ ORB orb = ORB.init(args, null); 1 POA rootpoa = POAHelper.narrow(orb.resolve_initial_references("RootPOA"));2 rootpoa.the_POAManager().activate(); 3 ShapeListServant SLSRef = new ShapeListServant(rootpoa); 4 org.omg.CORBA.Object ref = rootpoa.servant_to_reference(SLSRef); 5 ShapeList SLRef = ShapeListHelper.narrow(ref); org.omg.CORBA.Object objRef =orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); 6 NameComponent nc = new NameComponent("ShapeList", ""); 7 NameComponent path[] = {nc}; 8 ncRef.rebind(path, SLRef); 9 orb.run(); 10 } catch (Exception e) { ... } }} Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 8.10 Java client program for CORBA interfaces Shape and ShapeList import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; import org.omg.CORBA.*; public class ShapeListClient{ public static void main(String args[]) { try{ ORB orb = ORB.init(args, null); 1 org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); NameComponent nc = new NameComponent("ShapeList", ""); NameComponent path [] = { nc }; ShapeList shapeListRef = ShapeListHelper.narrow(ncRef.resolve(path)); 2 Shape[] sList = shapeListRef.allShapes(); 3 GraphicalObject g = sList[0].getAllState(); 4 } catch(org.omg.CORBA.SystemException e) {...} } Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 8.11 An example software architecture Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 8.12 The structure of a container Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 8.13 Application servers Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 8.14 Transaction attributes in EJB. Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 8.15 Invocation contexts in EJB Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 8.16 An example component configuration in Fractal Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 8.17 The structure of a Fractal component Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012

Figure 8.18 Component and ContentController Interfaces in Fractal Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 © Pearson Education 2012