Client/Server Architectures
Pictures from, Software Engineering 8, Sommerville
System types

Personal systems that are not distributed and that are
designed to run on a personal computer or workstation.

Embedded systems that run on a single processor or on an
integrated group of processors.

Distributed systems where the system software runs on a
loosely integrated group of cooperating processors linked by a
network.
Distributed system characteristics

Resource sharing


Openness


Concurrent processing to enhance performance.
Scalability


Use of equipment and software from different vendors.
Concurrency


Sharing of hardware and software resources.
Increased throughput by adding new resources.
Fault tolerance

The ability to continue in operation after a fault has occurred.
Distributed system disadvantages

Complexity


Security


More susceptible to external attack.
Manageability


Typically, distributed systems are more complex than centralised
systems.
More effort required for system management.
Unpredictability

Unpredictable responses depending on the system organisation and
network load.
Layered application architecture

Presentation layer


Application processing layer


Concerned with presenting the results of a computation to system users
and with collecting user inputs.
Concerned with providing application specific functionality e.g., in a
banking system, banking functions such as open account, close account,
etc.
Data management layer

Concerned with managing the system databases.
Application layers
Thin and fat clients

Thin-client model


In a thin-client model, all of the application processing and data
management is carried out on the server. The client is simply
responsible for running the presentation software.
Fat-client model

In this model, the server is only responsible for data
management. The software on the client implements the
application logic and the interactions with the system user.
Thin and fat clients
Presentation
Thin-client
model
Data management
Application processing
Client
Presentation
Application processing
Fat-client
model
Client
Server
Server
Data management
Thin client model

Used when legacy systems are migrated to client server
architectures.


Used in data-intensive applications


The legacy system acts as a server in its own right with a
graphical interface implemented on a client.
Web browsing
A major disadvantage is that it places a heavy processing
load on both the server and the network.
Thin clients

Text terminals


Client presents text to users, reads input from keyboard
X windows



Protocol to exchange desktop window information
Provides for the use of desktop applications that execute on a server
Server required to actual create graphical appearance and transmit to
client


Very slow for wide-area networking
Traditional Web Browser

Built on text terminal idea


Adds photographic images
Adds hyperlinks



URLs point from one page to another
Does not provide complete applications like XWindows
Much faster than Xwindows

Allows Web to work on global scale
Xwindows versus Web Browser


Xwindows
1. Server receives user input
2. Server performs application processing
3. Server puts computes changes required to GUI
4. Server sends client GUI changes
Traditional Web Browser
1. Server receives user input
2. Server loads text and image resources for client
3. Server provides a set of instructions for putting
resources together (HTML)
4. Server sends client resources + instructions
Fat client model



More processing is delegated to the client as the
application processing is locally executed.
Most suitable for new C/S systems where the capabilities
of the client system are known in advance.
More complex than a thin client model especially for
management. New versions of the application have to be
installed on all clients.
Fat client examples




Online Multiplayer Games
Multimedia Players
Eclipse IDE
Microsoft Outlook
Hybrid Browser Models



Server-Side Scripting
JavaScript
Java Applets
Hybrid Browser Models

Server-Side Scripting

Instead of loading resources based on client request,
Server loads resources based on application processing

Low latency at start-up time

Problem: High latency between user events
Hybrid Browser Models

JavaScript

Client performs minor application processing but only related
to beautifying the user interface

Example: Drop down menus, drag and drop, etc...

Low latency at startup-time

Low latency between user events

Problem: Limited to GUI
Hybrid Browser Models

Java Applets

Client downloads complete application on-demand

Application runs inside the browser

Strong security, can’t execute machine instructions directly

Low latency between user events

Problem: High latency at start-up time
A client-server ATM system
AT M
AT M
Account serv er
Telep rocessing
mon ito r
AT M
AT M
Custo mer
acco unt
database
Three-tier architectures


In a three-tier architecture, each of the application
architecture layers may execute on a separate processor.
Allows for better performance than a thin-client approach and
is simpler to manage than a fat-client approach.



More opportunities for caching
Move slower components further away from clients to be accessed
only when necessary
Middle-tier can further be split

Gives rise to multi-tier architecture


Client – Web Server – Application Server – Data Management
Web server provides application routing to different applications
hosted on different machines
A 3-tier C/S architecture
New C/S Approaches

Thin Clients


AJAX
Fat Clients

Rich Clients
AJAX


Asynchronous JavaScript and XML
Event-based architecture


For web browsers


Asynchronous, concurrent, communication with server
Which use Javascript
Client/Server communicate through XML messages

Why?


Client loads large Javascript file at startup which contains most user
interface instructions
Further communication with server doesn’t need UI information so
HTML is redundant
AJAX


Application processing is still on the server
But ...


Client can process several events without loading new pages
Originally every interaction with server required a fresh web
page to load
AJAX
Rich Clients





Fat Clients with an automatic update feature
Application is partitioned into core application and other
features through plugins
Requires careful application decomposition
If changes are require to core, user must download whole
new version
Takes advantage of dynamic linked libraries


Modern compilers can linked together separately compiled
class at application startup
Classes do not need to be compiled together
Use of C/S architectures
Arc hit ecture
Appli cations
Two-tier C/S
archit ecture with
thin c li ents
Legacy system appli cations whe re separating appli cation p rocessing and
data manage ment is impractical.
Computationa ll y-intens ive appli cations such as compil ers wit h littl e or
no data management.
Data-intens ive appli cations (browsing and que rying) wit h littl e or no
appli cation processing .
Two-tier C/S
archit ecture with
fat cli ents
App li cations whe re appli cation p rocessing is provided by o ff -the-shelf
soft ware (e.g. M ic rosoft Exc el) on the cli ent.
App li cations whe re computationa ll y-intensive p rocessing of data (e.g.
data visua lis ation) is requir ed.
App li cations wit h relatively stable end -use r func tiona lit y u sed in an
env ir onment wit h well -establi shed system management.
Thre e-tier or
multi -tier C/S
archit ecture
Large scale applications with hund reds or thousand s of cli ents
App li cations whe re both the data and the appli cation are vo latil e.
App li cations whe re data fr om multi ple sour ces are integrated.