1 / 70

ITEC801 Distributed Systems

ITEC801 Distributed Systems. Architectures and Paradigms Coulouris Chapter 2 Liu Chapter 3. 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.

marlon
Download Presentation

ITEC801 Distributed Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related