1. ICS362 – Distributed Systems Dr. Ken Cosh Week 2

2. Review Introduction Goals of DS – Available Resources – Transparency – Openness – Scalability Types of DS – Computing Systems – Information Systems – Pervasive Systems

3. This Week Architectures – Architectural Styles – System Architectures – Architectures vs Middleware

4. Software/System Architectures Logical Organisation of components vs Physical Organisation Design decisions – Centralised vs Decentralised Architectures – Middleware Layers – Adaptive Systems? (Autonomic Systems?)

5. Architectural Style Essential for successful system development In this case: Interrelated Components and Connectors – A component is a modular unit with well-defined required and provides interfaces that is replaceable within its environment. – A connector is a mechanism that mediates communication, co-ordination or co-operation between components.

6. Architectural Styles Key styles for Distributed Systems – Layered Architectures – Object-based Architectures – Data-centered Architectures – Event-based Architectures

7. Layered Architectures Components at layer L i are allowed to call components at underlying layers L i-1, but not the other way around. Database Layer Data Management Layer Applications Layer User Interface Layer RequestsResults

8. Object-based Architectures Looser Organisation Each Object is a ‘component’ with required and provides interface. Object Method Calls

9. Data-centred Architecture Processes communicate through a common (passive or active) data repository. – E.g. Web based systems where processes communicate through shared web-based data services.

10. Event-based Architectures Processes communicate through event propagation – ‘Publish/Subscribe’ systems Processes subscribed to events will receive them. Benefit is components are loosely coupled; – i.e. they don’t need to explicitly refer to each other.

11. System Architectures Organising Systems based on placement of software components – Centralised Architectures – Decentralised Architectures – Hybrid Architectures

12. Centralised Architectures Simply: Client Server Architectures – Easy way to understand & manage complexity in DS Server – Process implementing a particular service Client – Process requesting the service and waiting for a reply.

13. Request-Reply Behaviour Client Server Request Reply Provide Service Wait for Result Time

14. Message Reliability? Reliable Connections? – Resend upon failure? “Transfer $10,000 from my account” “How much money do I have” – Idempotency: Operation can be repeated without harm Connectionless vs Connection-oriented protocols? – Cost of setting up and maintaining a connection.

15. Client Server Architecture What is a client? What is a server? – Can we really distinguish between the two? – What is the database server needs to request a service from another file server? Nonetheless, essentially Client Server architecture has 3 ‘layers’ – User Interface Layer – Processing Layer – Data Layer

16. User Interface Layer Growing sophistication – Text based screen – GUI, with menus etc. – Drag ‘n’ Drop interface – Ajax!

17. Processing Layer Example: Web Search User Interface Database Query Generator Ranking Algorithm HTML Generator

18. Data Layer Data is persistent – When applications stop, the data doesn’t A file-system? A database? Often responsible for data management; – Security – Verification – Consistency

19. Thin and Fat Clients 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. 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.

20. Thin and Fat Clients

21. Thin Client Model 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 A major disadvantage is that it places a heavy processing load on both the server and the network

22. Fat Client Model More processing is delegated to the client as the application processing is locally executed Most suitable for new C/S systems where the capabilities of the client system are known in advance More complex than a thin client model especially for management. New versions of the application have to be installed on all clients

23. A Client-server ATM System

24. Three-tier Architectures In a three-tier architecture, each of the application architecture layers may execute on a separate processor Allows for better performance than a thin- client approach and is simpler to manage than a fat-client approach A more scalable architecture - as demands increase, extra servers can be added

25. A 3-tier C/S Architecture

26. An Internet Banking System

27. Use of C/S Architectures

28. Server as Client Application Server Database Server Request Reply Provide Service Wait for Data Time User Interface Wait for Result Request Reply

29. Centralised vs Decentralised Architectures Centralised Architectures – Vertical Distribution – Logical for many Business Environments Decentralised Architectures – Horizontal Distribution – Client (or Server) split up into logically equivalent parts where each part operates on its own share of the complete data set – Peer-to-peer systems

30. Decentralised or Peer-to-peer Architectures Each process acts as a client & a server (a servent). How to logically organise the processes? – Through an overlay network Nodes are processes & links are possible communication channels – In general processes can’t just communicate with another process at will, instead they have to follow the available communication channels.

31. Structured Peer-to-peer Architectures 1 Common Option – Distributed Hash Table assigns each node and each data item a random key. – Each data item is mapped to a node based on distance. – Nodes (and hence their data items) can then be stored in a linked list like structure. – Operations include; Lookup, Join, Leave etc.

32. Structured Peer-to-peer Architectures Alternative option – Data is assigned a location in a multi-dimensional Cartesian co-ordinate space E.g. (0.3,0.4) in a 2 dimensional space. – Nodes are then allocated regions of data to manage When a node joins it divides another existing nodes region in two. When a node leaves it’s region merges with a neighbour

33. Unstructured Peer-to-peer Architectures Where data is effectively randomly allocated to nodes – Searching requires flooding the network. When a node joins, it contacts an arbitrary node from a list of access points (highly available nodes) Superpeers can maintain an index of data items to improve search

34. Superpeers Peers connect to Superpeers who connect to a superpeer network. Further challenges exist; – Which is the best superpeer for this peer to connect with? – What happens when a superpeer leaves? – How do we decide which nodes become superpeers?

35. Hybrid Architectures Client Server solutions combined with decentralised architectures. – Edge Server Systems E.g. Users connecting to an ISP which resides at the “edge” of the internet. – Bit Torrent Trackers which keep an account of active nodes across the decentralised network.

36. Middleware? Software layer between applications and platforms providing distribution transparency If middleware is molded to an architectural style, designing applications is easier – But then the middleware might be too bloated for the application developer’s needs