WEB APPLICATIONS AND

D E V E L O P M E N T

Chapter 2: Web Application Architectures

Chapter Outline

 Introduction
 Methods, approaches
 Specifics of Web architecture
 Typical components of architectures
 Client Server Architecture.
 2-Tier Architecture.
 N-Tier Architecture.

2
Architectures

 Large systems are always decomposed into

sub-systems that provide some related set of
services.
 The initial design process of identifying these
subsystems and establishing a framework for
subsystem control and communication is
called architectural design.

3
Architectures
 Architectural design is the first stage in the
design process and represents a critical link
between the design and requirements
engineering process.
 The architectural design process is concerned
with establishing a basic structural
framework that identifies the major
components of a system and the
communications between these components.

4
Architectures

 Consider a large number of requirements and

constraints
 Range
⚫ Functional requirements : online product order
⚫ Quality requirements : performance, availability
⚫ Integration of existing systems
 Normally not developed “from scratch”

5
What is an Architecture?

 Architecture describes structure.

 According to (Bass et al.1998),the architecture
of a software system consists of its:
⚫ Structures,
⚫ The decomposition into components, and
⚫ Their interfaces and relationships.

6
What is an Architecture?

 It describes both the static and the dynamic

aspects of that software system, so that it can
be considered a building design and flowchart
for a software product.
 Architecture forms the transition from analysis
to implementation:

7
What is Architecture?
 When we create architecture we try to break
the functional requirements and quality
requirements down into software components
and their relationships and interfaces in an
iterative approach.
 This process is supported by a number of
approaches, such as the Unified Process.
 Its development is primarily influenced by
requirements.

8
Developing Architecture

9
Developing Architecture

 The architecture should be developed in an

iterative way.
 Advantages:
⚫ It reduces risks resulting from insecure
requirements.
⚫ Constraints are calculateable and controlable

10
Developing Architecture

 Bass et al (2003) states 3 advantages of

explicitly designing and documenting a
software architecture:
⚫ Stakeholder communication.
⚫ System analysis.
⚫ Large-scale reuse.

11
Stakeholder Communication

 The architecture is a high-level presentation

of the system that may be used as a focus for
discussion by a range of different
stakeholders.

12
System analysis

 Making the system architecture explicit at an

early stage in the system development
requires some analysis.
 Architectural design decisions have a
profound effect on whether the system can
meet critical requirements such as
performance, reliability and maintainability.

13
Large-Scale Reuse

 A system architecture model is a compact,

manageable description of how a system is
organised and how the components
interoperate.
 The system architecture is often the same for
systems with similar requirements and so can
support large-scale software reuse.

14
Architectures
 Architectural design stage forces software
designers to consider key design aspects early
in the process.
 Hofmeister et al (2000) suggest that the
software architectures can serve as a design
plan that is used to negotiate system
requirements and as a means of structuring
discussions with clients, developers and
managers.

15
Architectures

 They also suggest that it is an essential tool

for complexity management.
 It hides details and allows the designers to
focus on the key system abstractions.
 The system architectures affects the
performance, robustness, distributability and
maintainability of a system (Bosch 2000).

16
Architectures

 The particular style and structure chosen for

an application may therefore depend on the
non-functional system requirements:
⚫ Performance.
⚫ Security.
⚫ Safety.
⚫ Availability.
⚫ Maintainability.

17
Performance.

 If performance is a critical requirement, the

architecture should be designed to localise
critical operations within a small number of
subsystems, with as little communication as
possible between these subsystems.
 This may mean using relatively large-grain
rather than fine-grain components to reduce
component communication.

18
Security

 If security is a critical requirement, a layered

structure for the architecture should be used,
with the most critical assets protected in the
innermost layers and with a high level of
security validation applied to these layers.

19
Safety

 If safety is a critical requirement, the

architecture should be designed so that
safety-related operations are all located in
either a single subsystem or in a small
number of subsystems.
 This reduces the costs and problems of safety
validation and makes it possible to provide
related protection systems.

20
Availability

 If availability is a critical requirement, then it

should be designed to include redundant
components and so that it is possible to
replace and update components without
stopping the system.

21
Maintainability

 If maintainability is a critical requirement, the

system architecture should be designed using
fine-grain, self-contained components that
may readily be changed.
 Producers of data should be separated from
consumers and shared data structures should
be avoided.

22
Architectures

 Obviously, there is potential conflict between

some of these requirements.
 E.g. using large-grain components improves
performance, and using fine-grain
components improves maintainability.
 If both of these requirements are important
system requirements, then some compromise
solution must be found.

23
Patterns

 Describe recurring design problem, which

arise in a specific design context, and propose
solutions.
 Solutions describe the participating
components, their responsibilities, the
relationships between these components, and
the interplay of these components within the
specific problem.

24
Patterns

 Patterns enable us to reuse proven and

consolidated design knowledge

25
Framework

 This is another option to reuse existing

architecture knowledge.
 It contains architectural knowledge
 Framework is a reusable software system with
general functionality already implemented.
 Have to be weighed against its disadvantage
⚫ High degree of training effort

⚫ Lack of standard.

26
Architectural Design Decisions

 Architectural design is a creative process

where you try to establish a system
organisation that will satisfy the functional
and non-functional requirements.

27
Architectural design decisions

 Because architectural design is a creative

process, the activities within the process
differ radically depending on the:
⚫ Type of system being developed.
⚫ Background experience of the system architect.
⚫ Specific requirements of the system

28
Architectural design decisions
 Is there a generic application architecture that can be
used?
 How will the system be distributed?
 What architectural styles are appropriate?
 What approach will be used to structure the system?
 How will the system be decomposed into modules?
 What control strategy should be used?
 How will the architectural design be evaluated?
 How should the architecture be documented?

29
Architecture reuse

 Although each software system is unique,

systems in the same domain often have
similar architectures that reflect domain
concepts.
 E.g. application product lines are built around
a core architecture with variants that satisfy
particular customer requirements.

30
Architectural styles

 The architectural model of a system may

conform to a generic architectural model or
style.
 An architectural style is a pattern of system
organisation such as client-server
organisation or layered architecture.

31
Architectural Styles

 An awareness of these styles, their

applications, and their strengths and
weaknesses can simplify the problem of
defining system architectures.
 However, most large systems are
heterogeneous and do not follow a single
architectural style.

32
Architectural Styles

 In some cases, the overall system architecture

may be a composite architecture that is
created by combining different architectural
styles.

33
Architectural Structure

 A designer has to choose the most

appropriate structure such as client-server or
layered structuring, that will allow the system
requirements to be met.

34
System decomposition

 To decompose structural system units into

modules, a designer decides on the strategy
for decomposing subsystems into their
components or modules.
 The approaches that can be used allow
different types of architecture to be
implemented.

35
Control Strategy

 In the control modeling, a designer makes

decisions about how the execution of
subsystems is controlled.
 A general model of the control relationships
is developed between the parts of the system.

36
Architecture Evaluation

 Evaluating an architecture is difficult because

the true test of an architecture is how well it
meets its functional and non-functional
requirements after it has been developed.
 However, some evaluation can be done by
comparing the design against reference or
generic architectural models.

37
Architecture Documentation

 The product of the architectural design

process is an architectural design
documentation.
 It may include a number of graphical
representations of the system along with
associated descriptive text.

38
Architecture Documentation

 It should describe how the system is

structured into subsystems, the approach
adopted and how each subsystem is
structured into modules.
 The graphical models present different
perspectives on the architecture.

39
Architectural Models

 Architecture models that may be developed

may include:
⚫ A static structural model

⚫ A dynamic process model.

⚫ An interface model.

⚫ Relationship models.

⚫ A distribution model.

40
Architectural Models

 Static models shows the subsystems or

components that are to be developed as
separate units.
 Dynamic models shows how the system is
organized into processes at run-time.
 Interface models define the services offered
by each subsystem through its public
interface.

41
Architectural models

 Relationships model such as a data-flow model

shows relationships between the subsystems.
 Distribution model that shows how sub-
systems are distributed across computers.

42
System organisation
 This reflects the basic strategy that is used to
structure a system.
 Designers must make decisions on the overall
organisational model of a system early in the
architectural design process.
 Three organisational styles are widely used:
⚫ A shared data repository style;
⚫ A shared services and servers style;
⚫ An abstract machine or layered style.

43
The repository model
 Sub-systems must exchange data so that they
can work together effectively.
 This may be done in two ways:
⚫ Shared data is held in a central database or
repository and may be accessed by all sub-
systems;
⚫ Each sub-system maintains its own database
and passes data explicitly to other sub-
systems.

44
Repository Model

 When large amounts of data are to be shared,

the repository model of sharing is most
commonly used.
 This model is therefore suited to applications
where data is generated by one subsystem and
used by another.
 Examples of these systems are command and
control systems, management information
systems, CAD systems and CASE toolsets.

45
Advantages of Repository model

 Efficient way to share large amounts of

data as there is no need to transmit data
explicitly from one subsystem to another.
 Sub-systems that produce data need not
be concerned with how that data is used
by other systems.
 Activities such as backup, security, access
control and recovery from error are
centralised.

46
Advantages of Repository Model

 Sharing model is published as the repository

schema and it is therefore straightforward to
integrate new tools given that they are
compatible with the agreed data model.

47
Disadvantages of Repository Model

 Sub-systems must agree on a repository data

model.
⚫ Inevitably, this is a compromise between specific
needs of each tool.
⚫ Performance may be adversely affected by this
compromise.
⚫ It may be difficult or impossible to integrate new
subsystems if their data model does not fit the
agreed scheme.

48
Disadvantages of Repository Model

 Evolution may be difficult as large volume of

information is generated according to an agreed
data model.
⚫ Translating this to a new model will
certainly be expensive, it may be difficult or
even impossible

49
Disadvantages of Repository Model

 Different subsystems may have different

requirements for security, recovery and
backup policies.
⚫ The repository model forces the same policy
on all models.
 It may be difficult to distribute the
repository over a number of machines.

50
Client-Server Model

 The client-server architectural model is a

system model where the system is organised
as a set of services and associated servers
and clients that access and use the services.
 It is a distributed system model which shows
how data and processing is distributed across
a range of components.

51
Components of a Client-server model

 The major components are:

⚫ Set of stand-alone servers.
⚫ Set of clients .
⚫ Network.

52
 Client Server Model

C
l N
i e
e t
n w
t o
s r
k

Server

53
Servers
 A set of servers offer services to other
subsystems.
 Examples of servers are:
⚫ Print servers that offer printing services.
⚫ File servers that offer file management
services.
⚫ Compile servers which offers programming
language compilation services.
⚫ Application servers.

54
Clients

 A set of clients call on the services offered by

servers.
 These are normally sub-systems in their own
right.
 There may be several instances of a client
program executing concurrently.

55
Network

 A network allows the clients to access these

services.
 This is not strictly necessary as both the
clients and the servers could run on a single
machine.
 However, in practice, most client-server
systems are implemented as distributed
systems.

56
Client-server Model

 Clients may have to know the names of the

available servers and the services that they
provide.
 However, servers need not know either the
identify of clients or how many clients there
are.

57
Client-server Model

 Clients access the services provided by a

server through Remote Procedure Calls
(RPC) using a request-reply protocol such as
HTTP protocol.
 Essentially, a client makes a request to a
server and waits until it receives a reply.

58
Advantages of Client-server characteristics

 Distribution of data is straightforward;

 Makes effective use of networked systems.
 May require cheaper hardware;
 Easy to add new servers and integrate it with
the rest of the system or upgrade existing
servers transparently without affecting other
parts of the system.

59
Disadvantages of Client-Server Model
 There may be no shared data model across
servers and sub-systems use different data
organisation.
⚫ This means that data interchange may be
inefficient;
 Redundant management in each server;
 No central register of names and services - it
may be hard to find out what servers and
services are available.

60
Abstract machine (layered) model

 Used to model the interfacing of sub-systems.

 Organises a system into a set of layers (or
abstract machines) each of which provide a set
of services.
 Supports the incremental development of sub-
systems in different layers.

61
Layered Model

 Each layer can be thought of as an abstract

machine whose machine language is defined by
the services provided by the layer.
 This ‘language’ is used to implement the next
level of abstract machine.
 E.g. the OSI reference model of network
protocols.

62
Layered Model

 When a layer interface changes, only the

adjacent layer is affected.
 However, often artificial to structure
systems in this way is difficult.
 Also, performance can also be a problem
because of the multiple levels of
command interpretation that are
sometimes required.

63
Modular decomposition styles

 These are Styles of decomposing sub-systems

into modules.
 There is no rigid distinction between system
organisation and modular decomposition.

64
Sub-systems and modules

 A sub-system is a system in its own right

whose operation is independent of the
services provided by other sub-systems.
 Subsystems are composed of modules and
have defined interfaces, which are used for
communication with other subsystems.

65
Subsystems and Modules

 A module is normally a system component that

provides services to other components but
would not normally be considered as a separate
system.
⚫ Modules are usually composed from a
number of other simpler system
components.

66
Modular decomposition

 Is a another structural level where sub-systems

are decomposed into modules.
 There are two main strategies that can be used
when decomposition a subsystem into
modules:
⚫ An object-oriented decomposition.

⚫ Function-oriented pipelining.

67
Object models

 Structures the system into a set of loosely

coupled objects with well-defined interfaces.
 Object-oriented decomposition is concerned
with identifying object classes, their
attributes and operations.
 When implemented, objects are created from
these classes and some control model used to
coordinate object operations.

68
Invoice processing system

69
Object model advantages
 Objects are loosely coupled so their
implementation can be modified without
affecting other objects.
 The objects may reflect real-world entities.
 OO implementation languages are widely
used.
 However, object interface changes may cause
problems and complex entities may be hard
to represent as objects.

70
Function-oriented pipelining
 Functional transformations process their
inputs to produce outputs.
 May be referred to as a pipe and filter model
(as in UNIX shell).
 Variants of this approach are very common.
When transformations are sequential, this is a
batch sequential model which is extensively
used in data processing systems.
 Not really suitable for interactive systems.

71
Invoice processing system

72
Advantages of Pipeline model
 Supports transformation reuse.
 Intuitive organisation for stakeholder
communication since they think of their work
in terms of output and input processing.
 Easy to add new transformations.
 Relatively simple to implement as either a
concurrent or sequential system.

73
Disadvantage of Pipelining Model

 Requires a common format for data transfer

along the pipeline and difficult to support
event-based interaction.

74
Reference architectures
 Architectural models may be specific to some
application domain.
 Two types of domain-specific model
⚫ Generic models which are abstractions from a number of
real systems and which encapsulate the principal
characteristics of these systems. Covered in Chapter 13.
⚫ Reference models which are more abstract, idealised
model. Provide a means of information about that class of
system and of comparing different architectures.
 Generic models are usually bottom-up models;
Reference models are top-down models.

75
Reference architectures

 Reference models are derived from a study of

the application domain rather than from
existing systems.
 May be used as a basis for system
implementation or to compare different
systems.

76
Reference Architectures

 It acts as a standard against which systems

can be evaluated.
 OSI model is a layered model for
communication systems.

77
OSI reference model

7 Applic a tion Applic a tion

6 Pres ent a tion Pres ent a tion

5 Sess ion Sess ion

4 Trans por t Trans por t

3 Netw ork Netw or k Netw or k

2 Data lin k Data lin k Data lin k

1 Physical Physical Physical

Comm unica tions medium

78
Categorizing Architectures

 Architectures can be categorized using the

following criteria:
⚫ Layering aspect.
⚫ Data aspect.

79
Categorizing Architectures: Layering
 Software systems are structured in several tiers
to implement the principle of “separation of
concerns”.

80
Layering Aspect: Data Aspect

 Data can be.

⚫ Structured

 Relational DB

 XML

⚫ Non-structured

 Multimedia contents

 Images, audio, video

81
Specifics of Web Application Architectures

 Web application requirements are more

demanding than other Software systems
⚫ Changeability, performance, security,
scalability, availability
 Thus there is need to distinguish web
infrastructure (platform) and web application
architecture .

82
Specifics of Web Application Architectures
 Platform
⚫ J2EE, .NET
 Problems
⚫ Using of wide range of different systems is
increasingly difficult
⚫ Wide variety of problems
⚫ Inhomogeneity (lack of uniformity)
⚫ Immaturity (lack of experience).

83
Components of a Generic Web Application
Architecture

84
Components of a Generic Web Application
Architecture: Client

 The Client, generally a browser (user agent) is

controlled by a user to operate the Web
application.
 The client’s functionality can be expanded by
installing plug-ins and applets.

85
Client Applications (Software)
 Provides user interface
 Stores some settings
 Can do some data processing
 Little to no application data storage
⚫ Same view of data no matter where
you login

86
Components of a Generic Web Application
Architecture :Firewall

 This is piece of software regulating the

communication between insecure networks
(e.g. the Internet) and secure networks (e.g.
corporate LANs).

 This communication is filtered by access rules.

87
Components of a Generic Web Application
Architecture: Proxy

 A proxy is typically used to temporarily store

Web pages in a cache.

 However , proxies can also assume other

functionalities, e.g., adapting the contents for
users (customization), or user tracking.

88
Server Applications (Software)

 Management and maintenance of

Data including
⚫ User login data
⚫ Application data
 Data processing
 Centralized
 Access via Login

89
Components of a Generic Web Application
Architecture: Web Server

 A Web server is a piece of software that

supports various Web protocols like HTTP and
HTTPS, etc., to process client requests.

90
Components of a Generic Web Application
Architecture : Database server

 This server normally supplies an organization’s

production data in structured form ,e.g., in
tables.

91
Components of a Generic Web Application
Architecture : Media server:

 This component is primarily used for content

streaming of non-structured bulk data (e.g.
audio or video).

92
Components of a Generic Web Application
Architecture: Content management server

 Similar to a database server, a content

management server holds contents to serve an
application.
 These contents are normally available in the
form of semi-structured data ,e.g., XML
documents.

93
Components of a Generic Web Application
Architecture: Application server

 An application server holds the functionality

required by several applications, e.g., workflow
or customization.

94
Components of a Generic Web Application
Architecture: Legacy application

 A legacy application is an older system that

should be integrated as an internal or external
component.

95
 2 Layered Architecture
 The 2-layer architecture can take different forms
with in the environment of Web applications.

96
Classic Example:
Early Banking Systems

 Network: Local Area Network (LAN) covering

local office branch.
 Server: Mainframe-like server “in the back”
running custom banking system
 Client: Windows PC with client interface for each
bank teller.
 Data is the same no matter what teller you go to.
 Data is NOT the same if you go to another branch
unless servers exchanged some data at night.

97
Classic Example:
Early Banking Systems

The Obvious Future:

 Change the LAN to a wide area network
covering all the branches.
 Get rid of the individual servers at each
branch
 Have clients connect to central server where
ALL the banking data is stored.

98
Classic Example:
Early Banking Systems

The Obvious Problems:

 Large banks could have thousands of tellers
connecting to the central server.
 Combining data from all branches requires
severs with lots of storage capacity.
 Branch data could be stored in different
formats.
 Lack of Standardization.

99