DISTRIBUTED SYSTEMS
Lecture 2: Application Layering, Multitiered Client-Server
Architectures & Architectural Styles
Course: Distributed Systems (SWE 06123225)
Md. Shymon Islam
Lecturer
Department of Computer Science and Engineering (CSE)
Shahjalal University of Science and Technology, Sylhet
Primary reference: Tanenbaum & van Steen, Distributed Systems: Principles and Paradigms, 2nd Ed. — Ch. 2.1 & 2.2.1
LECTURE 2 ROADMAP
Today's Agenda
Course Contents: System Architectures & Client-Server Models → Programming Systems and Models
Recap: The Client-Server Model Application Layering
01 02
Request-reply behavior, connectionless vs. connection-oriented User-interface, processing & data levels
Two-Tiered Organizations Three-Tiered Architectures
03 04
Fat clients vs. thin clients A server acting as a client
Architectural Styles Styles in Practice
05 06
Components, connectors & four core styles Layered, object-based, data-centered, event-based
Distributed Systems | SWE 06123225 | Lecture 2
Recap: The Client-Server Model
Lecture 1 introduced the basic request-reply interaction. Today we look inside that model — how an application is organized internally, and how it can be
physically spread across machines.
Connectionless Protocol Connection-Oriented Protocol
Efficient on reliable local networks, but the client can't tell whether a lost reply Used by most Internet applications (TCP/IP) since wide-area links are
means the request never ran — a problem unless the operation is idempotent. inherently unreliable — at the cost of setup/teardown overhead.
Today's Question
A client and a server are roles, not fixed machines. So how do we decide what logic goes where — and what patterns exist for organizing that logic in the first
place?
Distributed Systems | SWE 06123225 | Lecture 2 Book ref: Ch. 2.2.1, pp. 36–38
Application Layering
Most client-server applications split into three logical levels, following the layered architectural style:
1 2 3
User-Interface Level Processing Level Data Level
Display management — from character-based mainframe The application's core logic — e.g. a search engine's Persistent storage: files or a full database, plus
screens to modern GUIs with shared windows and drag- query-to-ranked-results pipeline, or a decision-support consistency rules (e.g. a trigger that fires when a credit-
and-drop. system's analysis. card balance crosses a limit).
Worked Example: Internet Search Engine
UI: Processing: Data:
Keyword box & Query builder, Indexed database
result list ranking, HTML gen of crawled pages
Distributed Systems | SWE 06123225 | Lecture 2 Book ref: Ch. 2.2.1, pp. 38–41
Two-Tiered Organizations: Fat vs. Thin Clients
The three levels can be split across a client machine and a server machine in several ways — each pushes the line between “client” and “server” to a different
place.
Thin client Only terminal-dependent display logic sits on the client; the server has remote control over presentation. 0% app logic on client
The whole user-interface runs on the client, talking to the rest of the app via an application-specific
Graphical front end UI only
protocol.
Part of the processing also moves to the client — e.g. checking a form before submission, or local spell-
Client-side validation UI + partial logic
check.
Most of the application runs on the client; only file/database operations cross the network (e.g. many
Fat client UI + full logic
banking apps).
Fat client + local cache As above, plus part of the data is cached locally — e.g. a browser's cache of recently visited pages. UI + logic + data
Trend: fat clients are more powerful but harder to manage and more platform-dependent — many systems now favor thin clients, pushing more work (and more distribution) onto the server side.
Distributed Systems | SWE 06123225 | Lecture 2 Book ref: Ch. 2.2.1, pp. 41–42
Three-Tiered Architectures
A server can itself act as a client to another server — splitting the processing level onto its own tier.
request / reply request / reply
Client Processing Server Data Server
(user-interface) (application logic) (database)
Transaction Processing Web Site Organization
A transaction-processing monitor coordinates transactions across multiple, A Web server accepts requests and passes them to an application server for
separate data servers on behalf of client requests. processing, which in turn queries a database server for the raw data.
Note: server-side systems are increasingly themselves distributed — a single logical server tier is often several machines.
Distributed Systems | SWE 06123225 | Lecture 2 Book ref: Ch. 2.2.1, pp. 42–43
Architectural Styles: Components & Connectors
Moving to a new syllabus topic — Programming Systems and Models. An architectural style describes a system in terms of its components, connectors, the data
they exchange, and how they're configured together.
Component Connector
A mechanism that mediates communication, coordination, or cooperation
A modular unit with well-defined required & provided interfaces —
between components — e.g. (remote) procedure calls, message passing, or
replaceable, as long as its interfaces are respected.
data streaming.
Four Core Styles for Distributed Systems
01 Layered 02 Object-Based 03 Data-Centered 04 Event-Based
Distributed Systems | SWE 06123225 | Lecture 2 Book ref: Ch. 2.1, pp. 34–35
Layered & Object-Based Architectures
Layered Architecture Object-Based Architecture
Components at layer Li may call components at the underlying layer Li-1, never A far looser style: each object is a component, connected to others through
the reverse. Requests flow down; results flow back up. (remote) procedure calls. This is the software architecture behind the client-
server system architecture.
Application
Middleware
Operating System Obj B
Obj A Obj D
Network
Obj C
Widely used in networking (see Ch. 4)
Object A calls methods on B, C, D via remote procedure calls — the connector is the RPC
mechanism itself.
Distributed Systems | SWE 06123225 | Lecture 2 Book ref: Ch. 2.1, pp. 34–35
Data-Centered & Event-Based Architectures
Data-Centered Architecture Event-Based Architecture
Processes communicate through a common (passive or active) repository Processes communicate by propagating events, optionally carrying data — the
rather than directly with each other. basis of publish/subscribe systems.
P3 Subscriber 1
Publisher Middleware
Shared
Repository Subscriber 2
P1
P2
Loosely coupled — “referentially decoupled”: publishers need not know who (if anyone) is
Examples: shared distributed file systems; Web-based data services (Ch. 12).
listening.
Distributed Systems | SWE 06123225 | Lecture 2 Book ref: Ch. 2.1, pp. 35–36
Combining Styles & Choosing Wisely
Styles are not mutually exclusive — and none of them is free.
Shared Data Spaces = Event-Based + Data-Centered
Combining the two styles decouples processes in time as well as space — they need not both be active when communication happens. Many shared data spaces
offer a SQL-like, description-based interface rather than explicit references (covered in Ch. 13).
No Free Lunch No One-Size-Fits-All Style ≠ Placement
Every style aims at distribution transparency, but that There is no single architecture that covers 90% of A style describes logical organization; where
always trades off against performance, fault tolerance, distributed applications — researchers have largely components physically run (client, server, both) is a
and ease of programming. abandoned that idea. separate decision — our next topic: processes.
Distributed Systems | SWE 06123225 | Lecture 2 Book ref: Ch. 2.1, p. 36
From Programming Models to Processes
We now have a vocabulary for organizing distributed software — layers, objects, shared data, events — and for placing it across tiers. The next course topic
asks: what actually runs inside a single node?
This Lecture Next Lecture — Processes and Threads
Application layering, two- & three-tiered client-server organizations, and
Threads vs. processes, multithreaded clients & servers, virtualization, and
the four core architectural styles (layered, object-based, data-centered,
code migration — Course Contents' next topic.
event-based).
Distributed Systems | SWE 06123225 | Lecture 2 Book ref: Ch. 3.1, p. 69
WRAP-UP
Summary & Next Steps
Key Takeaways Reading Assignment
Tanenbaum & van Steen, Distributed Systems: Principles and Paradigms, 2nd Ed.
• Applications layer into user-interface, processing & data levels — the basis for splitting
work across client and server
Chapter 2.2.1 (Application Layering → Multitiered Architectures), pp. 36–43
• Two-tiered systems range from thin clients to fat clients, with clear management trade-
offs Chapter 2.1 (Architectural Styles), pp. 34–36
• Three-tiered architectures let a server act as a client to another server (e.g. TP
monitors, Web/app/DB tiers)
Next Lecture
• Four architectural styles — layered, object-based, data-centered, event-based —
describe how components communicate, and can be combined (e.g. shared data
spaces) Processes and Threads (Course Contents, Topic 4)
Questions? Let's discuss.
Distributed Systems | SWE 06123225 | Lecture 2