0% found this document useful (0 votes)
28 views42 pages

Lecture-6 Internet and Web Applications Architectures

Uploaded by

bebohassan3200
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
28 views42 pages

Lecture-6 Internet and Web Applications Architectures

Uploaded by

bebohassan3200
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 42

CS 4126 : Internet Technology

Lecture-6
Internet and Web Applications
Architectures
Web Application Development
 (Large) Applications cannot be developed in ad-hoc
manner
 We need design & architecture (SW engineering)
 Concept separation, Component, Relations, …
 There are so many architectural patterns
 Common architectures in web applications
 Multi-layer (Multi-tier), Microservices, …
 MVC, MVP,MVVM, …
Layering Approach
 Common layering in web applications
 Presentation Layer
 Business logic (Functional) Layer
 Persistence Layer
 Data (management/resource) Layer
 These layers are purely abstractions
 Not correspond to physical distribution
 All layers may or may not be on the same machine
Multilayer Architecture
Presentation Layer
 User interface of the application
 GUI
 HTML based browser
 Displays information (processing output) which are
get from the business logic layer
 Gets user’s requests and pass them (with required
data) to the business logic layer
 Note that the user interface of web applications can
be made up client side & server side codes
Presentation Layer
 Component:
 View elements such as text, images, layouts, blocks, and
templates. These are basically built by HTML & CSS.
 Interactive elements, which handle user input and
coordinate actions to help users complete tasks. These
are basically built by JavaScript.
Business Logic Layer
 Implements the core functionality and rules that
drive the business processes and operations.
 The work that the application needs to do
 Processing/Computing/Calculations
 Receives requests from presentation layer
 Fetches required data from data layer
 Process the request & data
 Output is sent back to the presentation layer
Business Logic Layer
 Component
 Business entities/models: Objects that represent key
concepts and data in the business domain.
 Business rules/validation: Enforcement of rules and
constraints to ensure data integrity.
 Workflow/Process Management: Define the steps and
actions involved in executing business processes.
 Business Logic/Operations: Implementing rules and
operations that drive the core functionality.
 Integration with External Systems: Communication
and integration with external systems or services.
Persistence Layer
 Implements activities to store and retrieve data
from database.
 Its typical operations encompass writing,
reading, updating & deleting data.
Persistence Layer
 Component
 Data Access Objects (DAOs): For interacting with
databases and performing CRUD (Create, Read,
Update, Delete) operations.
 Query Language: Allows the definition and execution of
database queries to retrieve and manipulate data.
 Caching Mechanism: In-memory caching of frequently
accessed data to optimize performance.
 Object-Relational Mapping (ORM) frameworks: Helps
in mapping database records to object-oriented models
and simplifies database interactions.
Data Layer
 Provides data access interface to business logic
 Hide data storage details
 Hide heterogeneity of underlining systems
 Stores, maintains, and manages data structurally
and organizationally
 Communicating with data store systems
 Database server
 Messaging system
 …
Data Layer
 Components
 Schema: Defines the structure and organization
of the database, including tables, columns, data
types, relationships, and constraints.
 Tables: Containers that hold the actual data in
rows and columns.
 Indexes: Data structures that enhance query
performance by enabling faster data retrieval
based on specific columns.
 Backup and Recovery mechanisms
What is a “Tier”?
 A "tier" can be referred to as a "layer".

A wedding cake is said to have


tiers while a chocolate cake is
said to have layers, but they
mean the same thing.
Tiers/ Layers Characteristics -
in Software World
 Each tier/layer should be able to be
constructed separately, possibly by different
teams of people with different skills.
 Several tiers/layers should be able to be
joined together to make a whole "something".
 Each tier/layer should contribute something
different to the whole. A chocolate layer cake,
for example, has layers of chocolate cake
and cream.
Tiers/ Layers Characteristics -
in Software World
 There must also be some sort of boundary
between one tier and another.
 Each tier/layer should not be able to operate
independently without interaction with other
tiers/layers.
Tiers vs. Layers in Software
 Tier is a physical unit, where the code / process
runs. E.g.: client, application server, database
server

 Layer is a logical unit, how to organize the code.


E.g.: presentation (view), controller, models,
repository, data access
1-Tier Architecture

 All 3 layers are on the same machine


 All code and processing kept on a single machine
 Presentation, Logic, Data layers are tightly connected
 Scalability: Single processor means hard to increase volume of
processing
 Portability: Moving to a new machine may mean rewriting everything
 Maintenance: Changing the layer requires changing other layers
1-Tier Architecture
1-Tier Architecture (blurry
boundary)
2-Tier Architecture

 Database runs on Server


 Separated from client
 Easy to switch to a different database
 Presentation and logic layers still tightly connected
 Heavy load on server
 Potential congestion on network
 Presentation still tied to business logic
2-Tier Architecture
3-Tier Architecture
Data
Presentati Business
Layer
on Layer Layer
contains
contains contains Database
Data
Presentati Business
Access
on logic logic
logic
Client Server DB Server

 Each layer can potentially run on a different


machine
 Presentation, logic, data layers disconnected
3-Tier Architecture
The Rules of the Multi-tier
Architecture
 The code for each layer must be contained
with separate files which can be maintained
separately.
 Each layer may only contain code which
belongs in that layer. Thus business logic can
only reside in the Business layer,
presentation logic in the Presentation layer,
and data access logic in the Data Access
layer.
Requests and Responses in
the 3 Tier Architecture
The Rules of the Multi-tier
Architecture
 The Presentation layer can only receive
requests from, and return responses to, an
outside agent. This is usually a person, but may
be another piece of software.
 The Presentation layer can only send requests
to, and receive responses from, the Business
layer. It cannot have direct access to either the
database or the Data Access layer.
The Rules of the Multi-tier
Architecture
 The Business layer can only receive requests
from, and return response to, the
Presentation layer.
 The Business layer can only send requests
to, and receive responses from, the Data
Access layer. It cannot access the database
directly.
The Rules of the Multi-tier
Architecture
 The Data Access layer can only receive
requests from, and return responses to, the
Business layer. It cannot issue requests to
anything other than the DBMS which it
supports.
 Each layer should be totally unaware of the
inner workings of the other layers.
The 3-Tier Architecture for
Web Application
 Presentation Layer
 Static or dynamically generated content rendered by
the browser, e.g., HTML, CSS, Javascript (front-end)
 Logic Layer
 A dynamic content processing and generation level
application server, e.g., Java , ASP.NET, PHP,
ColdFusion platform (middleware)
 Data Layer
 A database, comprising both data sets and the
database management system or RDBMS software
that manages and provides access to the data (back-
end)
N-Tier Architecture
Elsewhere Layer
Web services or
external HTML
pages

Requester/ Presentation Business- Accessor Persistance


Consumer Layer Logic Layer Layer Layer
Layer

Web Validation/
browser/ Processing/ Get
XML parser Content Update/
Display Database
or other Providing Delete
client modules modules modules
Design Problems & Decisions
 Construction and testing
 how do we build a web application?
 what technology should we choose?
 Re-use
 can we use standard components?
 Scalability
 how will our web application cope with large numbers of requests?
 Security
 how do we protect against attack, viruses, malicious data access, denial of
service?
 Different data views
 user types, individual accounts, data protection

Need for general and reusable solution: Design Patterns


What is a Design Pattern?
 A general and reusable solution to a commonly
occurring problem in the design of software
 A template for how to solve a problem that has
been used in many different situations
 NOT a finished design
 the pattern must be adapted to the application
 cannot simply translate into code
MVC: Model-View-Controller
 Model
 Does all the computational work
 It contains data and performs computation on it
 View (the user interface)
 Show the results from model or controller
 Controller (of states sequences)
 Handles events/requests affecting model or view
 User inputs/requests go to the controller
 Available commands are determined by controller (based on
model)
 Tells the model what to do
 Examples: Word Processor
MVC Interactions

model

view queries model controller updates


model
model signals changes

controller updates
view view controller

event event is passed to the controller


MVC for Web Applications
 Model
 Database tables (persistent data)
 Session information (current stat data)
 Parts of processing
 View
 (X)HTML
 CSS
 Controller
 Client-side scripting
 Part of processing by server side scripting
MVC for Web Applications
 MVC works fine for desktop application
 The origin is from graphical application development 1970s
 Consider large & distributed web application, e.g.,
online transactions, e-banking, …
 View  Model interactions?!!
 View is in user’s browser

 Model is in back-end server

 User  Controller interaction?


 User don’t have direct access to controller

 Complicated processing on huge data


 Model cannot both hold data & process it
MVC for Web Application

model
2

controller
1
3

browser view
4

Client Server
MVC for Web Application

1. Browser sends a request to controller


2. Controller processes the request, updates
some data
3. Controller forwards the request and data
to view
4. View generates the response that is sent
back to the client
3-tier Architecture vs. MVC
Architecture
 Communication
 3-tier: The presentation layer never communicates
directly with the data layer-only through the logic layer
(linear topology)
 MVC: All layers communicate directly (triangle
topology)
 Usage
 3-tier: Mainly used in web applications where the
client, middleware and data tiers ran on physically
separate platforms
 MVC: Historically used on applications that run on a
single graphical workstation (applied to separate
platforms)
Micro-Service Idea
 Complex process can be divided into multiple
loosely-coupled component
 Each component
 Is autonomous
 Provides well-defined services
 Via Remote API call
 Distributed application
 Easy to scale

 Different technologies can be used


Microservices Architecture
Microservices for Modern Web App

Service-1
Presentation
Layer
web Server DB Service
C
V M
Service-n
Service-2
Client Side
(Browser)
Server Side

HTML + CSS +
Ajax, REST, …
JS + …

You might also like