ITEC801 Distributed Systems

1. ITEC801Distributed Systems Architectures and Paradigms Coulouris Chapter 2 Liu Chapter 3

2. Architectures • Architecture of a system is its structure in terms of separately specified components • for a distributed system need to consider • placement of components • interaction of components Architectures

3. Paradigms • Paradigm means “a pattern, example, or model.” • In the study of any subject of great complexity, it is useful to identify the basic patterns or models, and classify the detail according to these models. Architectures

4. Distributed Applications • Characteristics that distinguish distributed applications from conventional applications which run on a single machine. • Interprocess communication: A distributed application require the participation of two or more independent entities (processes). To do so, the processes must have the ability to exchange data among themselves. • Event synchronisation: In a distributed application, the sending and receiving of data among the participants of a distributed application may need to be synchronised. Architectures

5. Architectures • Some important terms • platform • network operating system • middleware Architectures

6. Platform • Lowest level hardware and software layers • often used to refer to a combination of CPU and operating system, eg., • Intel x86/Windows • Sun SPARC/SunOS • Intel x86/Linux • PowerPC/MacOS Architectures

7. Network Operating Systems • A network operating system is not an operating system • a network operating system allows users to make use of services on other machines in the network • facilities typically provided include • remote login • file system services Architectures

8. Network Operating System Machine A Machine B Machine C Distributed Applications NOS Services NOS Services NOS Services Platform Platform Platform Network Architectures

9. Advantages/Disadvantages • NOS are not transparent • they do not present a view of the system as a single coherent system • they are scalable and (usually) open • they will work over heterogeneous platforms Architectures

10. Examples • NFS • Novell Netware Architectures

11. Middleware • A layer of software whose purpose is to • mask heterogeneity • provide a convenient programming model for application programmers • it shares the former with NOS, but not the second • simplifies the construction of software components that can work with one another in a distributed system Architectures

12. Abstraction • Middleware raises level of communication by support of abstractions • such as • remote method invocation • group communication • event notification • shared data replication Architectures

13. Other Services • Some middleware offer other services, including • naming • security • transactions • persistent storage Architectures

14. Examples • Early systems include Sun RPC and ISIS • object oriented middleware • CORBA • Java RMI • Microsoft DCOM • RM-ODP Architectures

15. Middleware Machine A Machine B Machine C Distributed Applications Middleware NOS Services NOS Services NOS Services Platform Platform Platform Network Architectures

16. Problems • A number of standards exist • these standards are generally incompatible • products from different manufacturers claiming to implement the same standard rarely internetwork • not all communication activities can be abstracted away from the applications • some reliability handling needs to remain there Architectures

17. Distributed Application Architectures • Client-Server • Peer-to-Peer Architectures

18. The Client-Server Paradigm • each computer or process on the network is either a client or a server (or both) • Servers: computers or processes implementing a specific service • for example, disk drives (file servers), printers (print servers), • Clients: PCs or workstations on which users run applications • Clients rely on servers for resources, such as files, devices, and even processing power Architectures

19. Client-Server Client Server Invocation (request) Client result Client Architectures

20. The Client-Server Paradigm • the client/server model roles are asymmetric • the server is a service provider which waits passively for the arrival of requests. • the client issues specific requests to the server and awaits its response.   Architectures

21. Client-Server • Simple in concept, the client-server model provides an efficient abstraction for the delivery of network services. • Operations required include those for a server process to listen and to accept requests, and for a client process to issue requests and accept responses. Architectures

22. Client-Server • By assigning asymmetric roles to the two sides, event synchronization is simplified: the server process waits for requests, and the client in turn waits for responses. • Many Internet services are client-server applications. • These services are often known by the protocol that the application implements. • Eg., HTTP, FTP, DNS, finger, gopher, etc. Architectures

23. Client-Server • Most widely used distributed architecture • servers may in turn be clients of other servers • for, example web server may be client of file server • Communication between client server may be • Simple connectionless protocol • Reliable connection-oriented protocol Architectures

24. Peer-to-Peer • an architecture where computer resources and services are directly exchanged between computer systems. • exchange of information, processing cycles, cache storage, and disk storage for files. • http://www.peer-to-peerwg.org/whatis/index.html Architectures

25. Peer-to-Peer • the participating processes play equal roles, with equivalent capabilities and responsibilities • hence the use of the term “peer” • Each participant may issue a request to another participant and receive a response. Architectures

26. Peer Processes • Co-operative • all processes play similar roles • code in the peer processes • maintain consistency of application-level resources • synchronise application-level actions (as required) Architectures

27. Peer Processes Peer response request request response Peer request Peer response Architectures

28. Peer Processes Peer request response request response Peer Architectures

29. Peer Process Example • Co-operative modification of a document • application process on each computer • middleware layer • performs event notification • group communication • so all application instances are informed of updates • interactive response would be better than with client server architecture Architectures

30. Peer-to-Peer distributed computing • the client-server paradigm is an ideal model for a centralised network service • the peer-to-peer paradigm is more appropriate for other applications • instant messaging, peer-to-peer file transfers, video conferencing, and collaborative work. • It is also possible for an application to be based on both the client-server model and the peer-to-peer model. Architectures

31. Example • A well-known example of a peer-to-peer file transfer service is Napster.com or similar sites which allow files (primarily audio files) to be transmitted among computers on the Internet. It makes use of a server for directory in addition to the peer-to-peer computing. Architectures

32. Example Architectures

33. Peer-to-Peer • The peer-to-peer paradigm can be implemented using any tool that provides message-passing Architectures

34. Example: JXTA • “Project JXTA is a set of open, generalized peer-to-peer protocols that allow any connected device (cell phone, to PDA, PC to server) on the network to communicate and collaborate. JXTA is short for Juxtapose, as in side by side. It is a recognition that peer to peer is juxtaposed to client server or Web based computing -- what is considered today's traditional computing model. “ Architectures

35. Distributed Application Paradigms Level of abstraction high Object space Network service, object request broker, mobile agent Remote procedure call, remote method invocation Message passing low Architectures

36. Message Passing • fundamental paradigm for distributed applications. • A process sends a message representing a request. • The message is delivered to a receiver, which processes the request, and sends a message in response. • In turn, the reply may trigger a further request, which leads to a subsequent reply, and so forth. Architectures

37. Message Passing Machine 1 Machine 2 Request message Process A Process B Response message Request message Architectures

38. Message Passing - Operations • The basic operations required to support the message passing are • Send • Receive. • For connection-oriented communication, also require the operations • Connect • Disconnect Architectures

39. Message Passing • processes perform input and output to each other, in a manner similar to file I/O. • The I/O operations encapsulate the detail of network communication at the operating-system level. • The socket application programming interface is based on this paradigm. • http://java.sun.com/javase/7/docs/api/ • http://www.sockets.com/ Architectures

40. Remote Procedure Call • As applications grew increasingly complex, it became desirable to have a paradigm which allows distributed software to be programmed in a manner similar to conventional applications which run on a single processor. • The Remote Procedure Call (RPC) model provides such an abstraction. • Using this model, inter-process communications proceed as procedure, or function, calls, which are familiar to application programmers. Architectures

41. Remote Procedure Calls (RPC) • Make network communication look like procedure calling • the emphasis is on hiding network communication. • Essentially calling a procedure on a remote machine. • Parameters shipped transparently. • Procedure executed on remote machine. • Results passed back to calling procedure. • Calling procedure ignorant on network communication. Architectures

42. RPC • RPC involves two independent processes, which may reside on separate machines. • A process, A, wishing to make a request to another process, B, issues a procedure call to B, passing with the call a list of argument values. • As in the case of local procedure calls, a remote procedure call triggers a predefined action in a procedure provided by process B. • At the completion of the procedure, process B returns to process A – possibly with values Architectures

43. RPC Machine 1 Machine 2 RPC call, with parameters Process A Process B Return, possibly with return values Architectures

44. Remote Procedure Call • RPC (and RMI) • allows programmers to build network applications using a programming construct similar to the local procedure call, • provides a convenient abstraction for both inter-process communication and event synchronisation. • Since its introduction in the early 1980s, the Remote Procedure Call model has been widely in use in network applications. Architectures

45. APIs • There are two prevalent APIs for Remote Procedure Calls. • The Open Network Computing Remote Procedure Call, evolved from the RPC API originated from Sun Microsystems in the early 1980s. • The Open Group Distributed Computing Environment (DCE) RPC. • Both APIs provide a tool, rpcgen, for transforming remote procedure calls to local procedure calls to the stub. Architectures

46. Distributed Objects Paradigms • The idea of applying object orientation to distributed applications is a natural extension of object-oriented software development. • Applications access objects distributed over a network. • Objects provide methods, through the invocation of which an application obtains access to services. Architectures

47. Object-oriented paradigms include: • Remote method invocation (RMI) • Network services • Object request broker • Object spaces Architectures

48. Remote Method Invocation (RMI) • Remote method invocation is the object-oriented equivalent of remote procedure calls. • In this model, a process invokes the methods in an object, which may reside in a remote host. • each object located on a particular machine • its interface is exported to many machines Architectures

49. Remote Method Invocation (RMI) • the remote interfaces transform method invocations into a message to the actual object • As with RPC, arguments may be passed with the invocation. Architectures

50. Remote Method Invocation Architectures