©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 1 Distributed Systems Architectures

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 2 Topics covered l 11.1 Multiprocessor architectures l 11.2 Client-server architectures l 11.3 Distributed object architectures l 11.4 Inter-organisational computing

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 3 Distributed systems l Virtually all large computer-based systems are now distributed systems. l Information processing is distributed over several computers rather than confined to a single machine. l Distributed software engineering is therefore very important for enterprise computing systems.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 4 System types l Personal systems that are not distributed and that are designed to run on a personal computer or workstation. l Embedded systems that run on a single processor or on an integrated group of processors. l Distributed systems where the system software runs on a loosely integrated group of cooperating processors linked by a network.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 5 Distributed system characteristics l Resource sharing Sharing of hardware and software resources. l Openness Use of equipment and software from different vendors. l Concurrency Concurrent processing to enhance performance. l Scalability Increased throughput by adding new resources. l Fault tolerance The ability to continue in operation after a fault has occurred.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 6 Distributed system disadvantages l Complexity Typically, distributed systems are more complex than centralised systems. l Security More susceptible to external attack. l Manageability More effort required for system management. l Unpredictability Unpredictable responses depending on the system organisation and network load.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 7 Distributed systems architectures l Client-server architectures Distributed services which are called on by clients. Servers that provide services are treated differently from clients that use services. l Distributed object architectures No distinction between clients and servers. Any object on the system may provide and use services from other objects.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 8 Middleware l Software that manages and supports the different components of a distributed system. In essence, it sits in the middle of the system. l Middleware is usually off-the-shelf rather than specially written software. l Examples Transaction processing monitors Data converters

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 9 Multiprocessor architectures l Simplest distributed system model. l System composed of multiple processes which may (but need not) execute on different processors. l Architectural model of many large real-time systems. l Distribution of process to processor may be pre-ordered or may be under the control of a dispatcher. l Example: Producer-consumer with buffers

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 10 A multiprocessor traffic control system

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide Client-server architectures l The application is modelled as a set of services that are provided by servers and a set of clients that use these services. l Clients know of servers but servers need not know of clients. l Clients and servers are logical processes l The mapping of processors to processes is not necessarily 1 : 1.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 12 A client-server system

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 13 Computers in a C/S network

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 14 Layered application architecture l Presentation layer Concerned with presenting the results of a computation to system users and with collecting user inputs. l Application processing layer Concerned with providing application specific functionality e.g., in a banking system, banking functions such as open account, close account, etc. l Data management layer Concerned with managing the system databases.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 15 Application layers

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 16 Thin and fat clients l Thin-client model In a thin-client model, all of the application processing and data management is carried out on the server. The client is simply responsible for running the presentation software. l Fat-client model In this model, the server is only responsible for data management. The software on the client implements the application logic and the interactions with the system user.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 17 Thin and fat clients

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 18 Thin client model l Used when legacy systems are migrated to client server architectures. The legacy system acts as a server in its own right with a graphical interface implemented on a client. l A major disadvantage is that it places a heavy processing load on both the server and the network.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 19 Fat client model l More processing is delegated to the client as the application processing is locally executed. l Most suitable for new C/S systems where the capabilities of the client system are known in advance. l More complex than a thin client model especially for management. New versions of the application have to be installed on all clients.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 20 Three-tier architectures l In a three-tier architecture, each of the application architecture layers may execute on a separate processor. l Allows for better performance than a thin- client approach and is simpler to manage than a fat-client approach. l A more scalable architecture - as demands increase, extra servers can be added.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 21 A 3-tier C/S architecture

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 22 An internet banking system

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide Distributed object architectures l There is no distinction in a distributed object architectures between clients and servers. l Each distributable entity is an object that provides services to other objects and receives services from other objects. l Object communication is through a middleware system called an object request broker (ORB). l However, distributed object architectures are more complex to design than C/S systems. l CORBA is often used with distributed objects

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 24 Distributed object architecture

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 25 Advantages of distributed object architecture l It allows the system designer to delay decisions on where and how services should be provided. l It is a very open system architecture that allows new resources to be added to it as required. l The system is flexible and scaleable. l It is possible to reconfigure the system dynamically with objects migrating across the network as required.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide Peer-to-peer architectures l Peer to peer (p2p) systems are decentralised systems where computations may be carried out by any node in the network. l The overall system is designed to take advantage of the computational power and storage of a large number of networked computers. l Most p2p systems have been personal systems but there is increasing business use of this technology.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 27 P2p architectural models l The logical network architecture Decentralised architectures; Semi-centralised architectures. l Application architecture The generic organisation of components making up a p2p application. l Focus here on network architectures.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 28 Decentralised p2p architecture

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 29 Semi-centralised p2p architecture

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 30 Service-oriented architectures l Based around the notion of externally provided services (web services). l A web service is a standard approach to making a reusable component available and accessible across the web A tax filing service could provide support for users to fill in their tax forms and submit these to the tax authorities.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 31 Web services

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 32 Services and distributed objects l Provider independence. l Public advertising of service availability. l Potentially, run-time service binding. l Opportunistic construction of new services through composition. l Pay for use of services. l Smaller, more compact applications. l Reactive and adaptive applications.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 33 Services standards l Services are based on agreed, XML-based standards so can be provided on any platform and written in any programming language. l Key standards SOAP - Simple Object Access Protocol; WSDL - Web Services Description Language; UDDI - Universal Description, Discovery and Integration.

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 34 l Distributed systems support resource sharing, openness, concurrency, scalability, fault tolerance and transparency. l Client-server architectures involve services being delivered by servers to programs operating on clients. l User interface software always runs on the client and data management on the server. Application functionality may be on the client or the server. l In a distributed object architecture, there is no distinction between clients and servers. Key points

©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 35 Key points l Distributed object systems require middleware to handle object communications and to add and remove system objects. l The CORBA standards are a set of middleware standards that support distributed object architectures. l Peer to peer architectures are decentralised architectures where there is no distinction between clients and servers. l Service-oriented systems are created by linking software services provided by different service suppliers.