optional · CSS study notes
9. Web Application Layered Architecture (Client-Server, n-Layered, JSP Model, Struts, OOHDM)
CSS Optional — Paper-II, Section-B · P-II.VI.9 · CSS 2018 asked to elaborate three-tier architecture with reference to presentation, business logic and data access layers — model answer in section 3.
1. Why Layers?
Layering separates concerns: each layer has one responsibility and talks only to adjacent layers. Benefits: maintainability, replaceability (change the database without touching the UI), parallel development, security (the database is never exposed directly), scalability (scale each tier separately).
Layer vs tier: a layer is a logical separation of code; a tier is a physical separation onto different machines/processes. Three layers can run on one tier (a small server) or three tiers.
2. Client-Server (2-tier)
graph LR
C["Client: UI + business logic"] <-->|"SQL over network"| S["Server: database"]
- Thin client: client only displays; the server does processing (web browser model).
- Fat (thick) client: client holds UI and much of the business logic (classic desktop apps).
- Pros: simple, fast to build for small user groups. Cons: poor scalability (each client holds a DB connection), business logic duplicated on clients, hard updates, security risk (direct DB access).
3. Three-Tier Architecture — Model Answer (CSS 2018)
graph TD
P["Presentation layer: browser, HTML/CSS/JS, UI controllers"] -->|"HTTP requests"| B["Business logic layer: application server, rules, validation, workflows"]
B -->|"queries via data access objects"| D["Data access layer: DAO/ORM + database server"]
D -->|"results"| B
B -->|"HTML/JSON response"| P
| Layer | Responsibility | Technologies | Example (online banking) |
|---|---|---|---|
| Presentation | Display data, capture user input, basic client-side validation; no business rules | HTML, CSS, JavaScript, React; server templates (Blade, JSP) | Funds-transfer form and confirmation screen |
| Business logic (application / middle tier) | Apply rules, calculations, workflows, authorization, transactions | PHP/Laravel, Java/Spring, Node.js, .NET | Check balance ≥ amount, daily limit, OTP; compute fee |
| Data access | Store and retrieve data; hide database details from business layer | DAO/Repository, ORM (Eloquent, Hibernate), SQL; MySQL, Oracle | Debit account A, credit account B in one transaction |
Flow: user submits transfer → presentation sends request → business layer validates rules → data layer executes an atomic transaction → result returns up → confirmation page shown.
Advantages: separation of concerns; each tier scaled independently (add app servers under load); database hidden behind the business tier (security); UI can change (web → mobile) without changing rules; reusable business logic; easier testing.
Disadvantages: more complexity and network hops (latency); more infrastructure to manage.
4. n-Layered (n-Tier) Architecture
Extends 3-tier with more specialized tiers: CDN/static tier, web tier, application tier, service/integration tier, cache tier, data tier, and sometimes search or analytics tiers.
- Pros: high scalability, fault isolation, flexibility, reuse via services.
- Cons: complexity, latency, cost; distributed debugging.
5. JSP Model 1 vs Model 2
Java Server Pages (JSP) architectures from Sun's J2EE blueprints.
graph LR
subgraph M1["Model 1"]
B1["Browser"] --> J1["JSP page: control + view"]
J1 --> JB1["JavaBean"]
JB1 --> DB1[("DB")]
end
subgraph M2["Model 2 (MVC)"]
B2["Browser"] --> S2["Servlet: Controller"]
S2 --> JB2["JavaBean: Model"]
JB2 --> DB2[("DB")]
S2 --> J2["JSP: View"]
J2 --> B2
end
| Point | JSP Model 1 | JSP Model 2 |
|---|---|---|
| Request handled by | JSP page directly | A controller servlet |
| Pattern | Page-centric (page controller) | MVC (front controller) |
| Logic placement | Presentation and control mixed in JSP (scriptlets) | Control in servlet, data in beans, display in JSP |
| Suitable for | Small, simple apps | Large, maintainable apps |
| Maintenance | Hard as app grows ("spaghetti") | Easier; roles separated |
6. Apache Struts
- Open-source Java web framework (Craig McClanahan, 2000) that implements JSP Model 2 / MVC.
- Struts 1 components: ActionServlet (front controller) reads struts-config.xml (maps URLs to actions); Action classes (call business logic); ActionForm beans (hold and validate form data); JSP views with Struts tag libraries; ActionForward decides the next view.
- Request flow: browser → ActionServlet → populate ActionForm → validate → Action.execute() → model → ActionForward → JSP → response.
- Struts 2 (merged with WebWork): filter-based dispatcher, interceptors (validation, logging), POJO actions, OGNL expression language. Struts 1 reached end of life in 2013.
- Lesson from practice: a Struts 2 vulnerability (CVE-2017-5638) left unpatched led to the 2017 Equifax data breach — an example of "vulnerable and outdated components".
7. OOHDM — Object-Oriented Hypermedia Design Method
Schwabe & Rossi (1995). Separates what the data is, how users navigate it, and how it looks.
| Phase | Concern | Product |
|---|---|---|
| Requirements gathering | Actors, tasks, scenarios | Use cases, user interaction diagrams |
| Conceptual design | Application domain | Conceptual class schema (classes, relationships) |
| Navigational design | Navigation as views over conceptual classes | Navigational class schema (nodes, links) + navigational context schema (index, guided tour) |
| Abstract interface design | How navigation objects appear and react | Abstract Data Views (ADVs) |
| Implementation | Map to a concrete platform | Running web application |
Key idea: different user profiles can have different navigational views over the same conceptual model (e.g. students and faculty see different navigation for the same courses).
🎯 CSS Exam Angle
For three-tier questions: diagram + 3-row table (responsibility, technology, example) + flow of one request + advantages/disadvantages. For JSP/Struts, draw Model 1 vs Model 2 side by side. For OOHDM, the 5-phase table is the answer.
📌 Past CSS Paper Frequency
| Year | Question |
|---|---|
| 2018 | Elaborate three-tier architecture with reference to presentation, business logic and data access layers |
⚠️ MCQ Traps
- Layer = logical, tier = physical.
- JSP Model 2 = MVC with a servlet as controller; Model 1 is page-centric.
- In Struts, ActionServlet is the controller; the mapping file is struts-config.xml.
- OOHDM's navigational design is a view over the conceptual model, not a new data model.
- In 3-tier, the presentation tier never accesses the database directly.
✅ Self-Check (with Answers)
Q1. Why is 3-tier more secure than 2-tier client-server?
Ans: In 2-tier, clients connect directly to the database (credentials on every client, database exposed). In 3-tier, only the business tier talks to the database, enforcing authorization and validation and keeping the database behind the network boundary.
Q2. Where would you place "a student can't register for more than 21 credit hours"?
Ans: In the business logic layer (optionally duplicated as a convenience check in the presentation layer, but the business layer must enforce it).
Q3. Give two differences between JSP Model 1 and Model 2.
Ans: In Model 1 the JSP handles both request control and presentation (page-centric); in Model 2 a servlet controller handles requests and JSP only renders views (MVC). Model 2 is more maintainable for large applications.
Q4. Name the main components of Struts 1.
Ans: ActionServlet (front controller), struts-config.xml (mappings), Action classes, ActionForm beans, ActionForward, and JSP views with tag libraries.
Q5. What are the design models of OOHDM?
Ans: Conceptual model (classes), navigational model (navigational class schema and context schema), abstract interface model (ADVs), followed by implementation.
Q6. Layer vs tier?
Ans: Layers are logical code separations (presentation, business, data); tiers are physical deployments on separate machines/processes. Layers can be deployed on one or many tiers.
📜 Past-Paper Questions & MCQs (CSS 2016–2026)
2018 · Paper-II · Q8(A), 2022 · Paper-II · Q7(a), 2025 · Paper-II · Q8(c) · 8 marks each
Q. Elaborate the concept of three-tier architecture with reference to the presentation, business-logic and data-access layers.
Ans.
- Three-tier architecture divides a web application into three separate layers, each with its own job. Each layer talks only to its neighbour.
Client (browser) → [ 1. Presentation tier ] → [ 2. Business-logic tier ] → [ 3. Data tier ]
HTML, CSS, JS user interface rules, processing, database server,
application server data-access code
- 1. Presentation tier: the user interface that displays information and collects input (HTML, CSS, JavaScript, mobile app). It has no business rules.
- 2. Business-logic (application) tier: the application server code that applies rules, validation and workflows (PHP, Java, ASP.NET, Node.js). It processes requests, and talks to both the other tiers.
- 3. Data-access (data) tier: the database and the code that reads and writes it (DAO or ORM, SQL). It stores and retrieves data and keeps integrity.
- Advantages: separation of concerns, each tier can be changed or replaced independently, scalability (add servers to one tier), better security (the database is not exposed to the browser), reuse and easier testing and maintenance.
- Disadvantages: more complexity and some extra delay between tiers.
- Example: in an online shop, the browser shows a product list (presentation), a server script checks stock and prices (logic), and the database holds the products (data).
MCQs
2026 P-II · Q11. In modern micro-frontend architectures, the primary benefit of independently deployed UI fragments is:
- (A) Tighter coupling across teams
- (B) Improved runtime bundling only
- (C) Enhanced isolation and autonomous deployment pipelines ✅
- (D) None of these
- Answer: (C).
- Why: a micro-frontend splits a large web UI into fragments that separate teams can build, test and release on their own. Teams are decoupled, so a change or failure in one fragment does not force a redeploy of the others. Tighter coupling is the opposite of the goal.