Client/Server Architectures Pictures from, Software Engineering 8, Sommerville
Embed Size (px)
Transcript of Client/Server Architectures Pictures from, Software Engineering 8, Sommerville
- Slide 1
- Client/Server Architectures Pictures from, Software Engineering 8, Sommerville
- Slide 2
- System types Personal systems that are not distributed and that are designed to run on a personal computer or workstation. Embedded systems that run on a single processor or on an integrated group of processors. Distributed systems where the system software runs on a loosely integrated group of cooperating processors linked by a network.
- Slide 3
- Distributed system characteristics Resource sharing Sharing of hardware and software resources. Openness Use of equipment and software from different vendors. Concurrency Concurrent processing to enhance performance. Scalability Increased throughput by adding new resources. Fault tolerance The ability to continue in operation after a fault has occurred.
- Slide 4
- Distributed system disadvantages Complexity Typically, distributed systems are more complex than centralised systems. Security More susceptible to external attack. Manageability More effort required for system management. Unpredictability Unpredictable responses depending on the system organisation and network load.
- Slide 5
- Layered application architecture Presentation layer Concerned with presenting the results of a computation to system users and with collecting user inputs. Application processing layer Concerned with providing application specific functionality e.g., in a banking system, banking functions such as open account, close account, etc. Data management layer Concerned with managing the system databases.
- Slide 6
- Application layers
- Slide 7
- 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.
- Slide 8
- Thin and fat clients Thin-client model Fat-client model Client Server Data management Application processing Presentation Server Data management Presentation Application processing
- Slide 9
- 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. Used in data-intensive applications Web browsing A major disadvantage is that it places a heavy processing load on both the server and the network.
- Slide 10
- Thin clients Text terminals Client presents text to users, reads input from keyboard X windows Protocol to exchange desktop window information Provides for the use of desktop applications that execute on a server Server required to actual create graphical appearance and transmit to client Very slow for wide-area networking Traditional Web Browser Built on text terminal idea Adds photographic images Adds hyperlinks URLs point from one page to another Does not provide complete applications like XWindows Much faster than Xwindows Allows Web to work on global scale
- Slide 11
- Xwindows versus Web Browser Xwindows 1. Server receives user input 2. Server performs application processing 3. Server puts computes changes required to GUI 4. Server sends client GUI changes Traditional Web Browser 1. Server receives user input 2. Server loads text and image resources for client 3. Server provides a set of instructions for putting resources together (HTML) 4. Server sends client resources + instructions
- Slide 12
- 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.
- Slide 13
- Fat client examples Online Multiplayer Games Multimedia Players Eclipse IDE Microsoft Outlook
- Slide 14
- Slide 15
- Hybrid Browser Models Server-Side Scripting Instead of loading resources based on client request, Server loads resources based on application processing Low latency at start-up time Problem: High latency between user events
- Slide 16
- Slide 17
- Hybrid Browser Models Java Applets Client downloads complete application on-demand Application runs inside the browser Strong security, cant execute machine instructions directly Low latency between user events Problem: High latency at start-up time
- Slide 18
- A client-server ATM system
- Slide 19
- 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. More opportunities for caching Move slower components further away from clients to be accessed only when necessary Middle-tier can further be split Gives rise to multi-tier architecture Client Web Server Application Server Data Management Web server provides application routing to different applications hosted on different machines
- Slide 20
- A 3-tier C/S architecture
- Slide 21
- New C/S Approaches Thin Clients AJAX Fat Clients Rich Clients
- Slide 22
- Slide 23
- AJAX Application processing is still on the server But... Client can process several events without loading new pages Originally every interaction with server required a fresh web page to load
- Slide 24
- Slide 25
- Rich Clients Fat Clients with an automatic update feature Application is partitioned into core application and other features through plugins Requires careful application decomposition If changes are require to core, user must download whole new version Takes advantage of dynamic linked libraries Modern compilers can linked together separately compiled class at application startup Classes do not need to be compiled together
- Slide 26
- Use of C/S architectures