A CLIENT–SERVER ARCHITECTURE is a distributed system model showing how data and processing are distributed across a range of components. It consists of: · a set of STAND-ALONE SERVERS providing specific services — printing, data management, and so on · a set of CLIENTS calling on those services · a NETWORK enabling clients to access servers Clients may have to know the names of available servers and the services they provide. Servers, however, need not know the identity of clients or how many there are. Clients access the services provided by a server through REMOTE PROCEDURE CALLS using a request–reply protocol such as HTTP. Note that clients and servers are LOGICAL PROCESSES, not necessarily separate machines. Several logical servers may run on one physical machine, and the mapping of processes to processors is a separate decision. THE THREE LOGICAL LAYERS of any information system — this split is what makes the whole topic tractable: PRESENTATION LAYER presenting information to the user and managing all user interaction APPLICATION / implementing the business logic and the PROCESSING LAYER rules DATA MANAGEMENT database operations, persistence LAYER The client–server question is simply: WHERE DO YOU DRAW THE LINE BETWEEN CLIENT AND SERVER ACROSS THESE THREE LAYERS?

TWO-TIER CLIENT–SERVER ARCHITECTURE — the application is organised as a server (or multiple identical servers) and a set of clients. It takes two forms. THIN-CLIENT MODEL All the application processing and data management is carried out on the SERVER. The client is responsible only for running the presentation software. CLIENT: presentation SERVER: application logic + data management ADVANTAGES · simple, low-cost approach when migrating a legacy system to a client–server architecture — the legacy system acts as a server in its own right, with a graphical interface implemented on a client · client machines can be cheap, and need almost no management — no software to install or update on each · SECURITY is easier: logic and data never leave the server · ONE PLACE TO DEPLOY a change DISADVANTAGES · places a HEAVY PROCESSING LOAD on both the server and the network — every interaction is a round trip · POOR RESPONSIVENESS for interaction-heavy work, because network latency is on the critical path of every action · does not make effective use of the (often considerable) processing power available on the client FAT-CLIENT MODEL The server is responsible only for DATA MANAGEMENT. The software on the client implements the application logic and the interactions with the system user. CLIENT: presentation + application logic SERVER: data management ADVANTAGES · makes effective use of available processing power · RESPONSIVE — local logic means no round trip for every interaction · reduces server and network load DISADVANTAGES · SYSTEM MANAGEMENT IS MORE COMPLEX. Application functionality is spread across many computers, so when the application changes, the new version must be installed on ALL clients — a significant cost in a large organisation. · the client must be powerful enough to run the logic · SECURITY: business rules on the client can be inspected and bypassed. Any rule that matters MUST ALSO BE ENFORCED ON THE SERVER — a client-side check is a convenience for the user, never a control. THE ATM EXAMPLE (Sommerville's): an ATM is a thin client of a teleprocessing monitor, which is itself a client of the account database server — showing that a component can be a server to one thing and a client to another simultaneously.

THREE-TIER CLIENT–SERVER ARCHITECTURE Each of the three logical layers — presentation, application processing, data management — is a SEPARATELY EXECUTABLE PROCESS, and they may execute on different processors. TIER 1 CLIENT presentation only TIER 2 APPLICATION business logic, one or many SERVER instances TIER 3 DATABASE data management SERVER ADVANTAGES over both two-tier forms · SCALABILITY: because the application logic is on its own tier, more application servers can be added behind a load balancer without touching clients or the database. Neither two-tier form scales this way. · MAINTAINABILITY: a logic change is deployed to the application tier only — the thin client's deployment advantage, with the fat client's separation of concerns. · SECURITY: the database is reachable only from the application tier, never from the client. This is the layered-architecture security argument realised physically. · the tiers can be tuned independently — more CPU for the application tier, more memory and disk for the database. DISADVANTAGE · more complex to build, deploy and operate than two-tier; more moving parts, more places to fail, more network hops. MULTI-TIER (N-TIER) When a single application server cannot meet demand, or when the system must integrate several existing systems, further servers are added — a web server, a caching tier, an integration tier, separate services per business capability. This is a natural extension of the three-tier model and is what most large web systems actually are. WHEN TO USE WHICH — the standard guidance table: ARCHITECTURE APPLICATION ───────────────────────────────────────────────────────────── Two-tier legacy system where separating THIN CLIENT application and data management is impractical; computationally intensive applications such as compilers with little or no data management; data-intensive applications (browsing, querying) with little application processing Two-tier applications where the processing is FAT CLIENT provided by off-the-shelf software (e.g. Excel) on the client; applications where computationally intensive processing of data (e.g. visualisation) is required; applications with relatively stable end-user functionality used in an environment with well-established system management Three-tier or large-scale applications with hundreds multi-tier or thousands of clients; applications where both the data and the application are volatile; applications where data from multiple sources are integrated READ THE FAT-CLIENT ROW CAREFULLY: "relatively stable end-user functionality" and "well-established system management". The fat client is a good choice only when you rarely need to change the logic, precisely because changing it means touching every client.

THE FEATURE: an officer fills a 20-field licence application form, with validation on each field. THIN CLIENT — every validation is a server round trip. network round-trip time (RTT), same-city: 30 ms server processing per validation: 5 ms per-field cost: 35 ms 20 fields: 20 × 35 = 700 ms Acceptable — barely. Now the same form over a rural 3G link: RTT 300 ms: per-field cost: 305 ms 20 fields: 20 × 305 = 6.1 SECONDS of pure waiting, spread across the form. The officer experiences the system as broken, and no server upgrade fixes it, because the cost is LATENCY, not throughput. FAT CLIENT — validation runs locally. per-field cost: ~1 ms 20 fields: ~20 ms one submit at the end: 1 × 305 = 305 ms total ~325 ms even on the 3G link — a 19× improvement (18.8×), obtained purely by moving where the code runs. BUT: the client-side rules are now inspectable and bypassable. A malicious client can POST an application with a fee of zero. SO THE SERVER MUST STILL VALIDATE EVERYTHING. The rules are DUPLICATED — implemented twice, and they can drift apart. THREE-TIER, WITH THE RULES IN ONE PLACE: · validation rules defined once, in the application tier · exported to the client as data (a JSON schema or rule set) rather than as code · the client applies them for instant feedback · the application tier applies THE SAME rules authoritatively on submit → one definition, two enforcement points, no drift THE GENERAL PRINCIPLE THIS ILLUSTRATES: CLIENT-SIDE CHECKS ARE FOR USER EXPERIENCE. SERVER-SIDE CHECKS ARE FOR CORRECTNESS AND SECURITY. They are not alternatives, and treating a client-side check as a control is one of the most common real security defects in web systems. CAPACITY CHECK — the other half of the decision. Suppose 500 concurrent officers, thin client, each generating one validation request every 3 seconds while typing: request rate = 500 / 3 ≈ 167 requests/second at 5 ms of server CPU each = 0.833 CPU-seconds per second → about 1.2 cores of pure validation work, plus overhead Fat/three-tier client: those 167 req/s vanish entirely; only the 500 submissions over the whole session reach the server. So moving validation to the client saved BOTH the latency AND the server capacity — which is why the hybrid is the standard answer.