lecturer: sebastian coope ashton building, room g.18 e-mail: [email protected] comp 201...

29
Software Engineering COMP 201 Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: [email protected] COMP 201 web-page: http://www.csc.liv.ac.uk/~coopes/comp201 Lecture 16 – Distributed System Architectures

Upload: amara-swingle

Post on 14-Dec-2015

215 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

Software EngineeringCOMP 201

Lecturer: Sebastian CoopeAshton Building, Room G.18

E-mail: [email protected]

COMP 201 web-page:http://www.csc.liv.ac.uk/~coopes/comp201

Lecture 16 – Distributed System Architectures

Page 2: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

Distributed Systems Architectures

Architectural design for software that executes on more than one processor

l 2l COMP201 - Software Engineering

Page 3: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

Distributed Systems

Virtually all large computer-based systems are now distributed systems

Information processing is distributed over several computers rather than confined to a single machine

Distributed software engineering is now very important

l 3l COMP201 - Software Engineering

Page 4: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

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.

l 4l COMP201 - Software Engineering

Page 5: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

Distributed System Characteristics

Resource sharingOpennessConcurrencyScalabilityFault toleranceTransparency

Distributed system disadvantages :

l Complexityl Securityl Manageabilityl Unpredictability

l 5l COMP201 - Software Engineering

Page 6: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

Distributed Systems Architectures

Client-server architecturesDistributed services which are called on by clients. Servers

that provide services are treated differently from clients that use services

Distributed object architecturesNo distinction between clients and servers. Any object on

the system may provide and use services from other objects

l 6l COMP201 - Software Engineering

Page 7: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

Middleware

Software that manages and supports the different components of a distributed system. In essence, it sits in the middle of the system

Middleware is usually off-the-shelf rather than specially written software

ExamplesTransaction processing monitorsData convertersCommunication controllers

l 7l COMP201 - Software Engineering

Page 8: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

1. Multiprocessor Architectures

Simplest distributed system modelSystem composed of multiple processes which may (but

need not) execute on different processorsArchitectural model of many large real-time systemsDistribution of process to processor may be pre-ordered

or may be under the control of a dispatcher

l 8l COMP201 - Software Engineering

Page 9: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

A Multiprocessor Traffic Control System

Traffic lights

Lightcontrolprocess

Traffic light controlprocessor

Traffic flowprocessor

Operator consolesTraffic flow sensors

and cameras

Sensorprocessor

Sensorcontrolprocess

Displayprocess

l 9l COMP201 - Software Engineering

Page 10: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

2. Client-Server Architectures

The application is modelled as a set of services that are provided by servers and a set of clients that use these services

Clients know of servers but servers need not know of clients

Clients and servers are logical processes The mapping of processors to processes is not necessarily

1 : 1

l 10l COMP201 - Software Engineering

Page 11: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

A Client-Server System

s1

s2 s3

s4c1

c2 c3 c4

c5

c6c7 c8

c9

c10

c11

c12

Client process

Server process

l 11l COMP201 - Software Engineering

Page 12: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

Computers in a C/S Network

Network

SC1SC2

CC1 CC2 CC3

CC5 CC6CC4

Servercomputer

Clientcomputer

s1, s2 s3, s4

c5, c6, c7

c1 c2 c3, c4

c8, c9 c10, c11, c12

l 12l COMP201 - Software Engineering

Page 13: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

Layered Application Architecture

Presentation layerConcerned with presenting the results of a computation to

system users and with collecting user inputsApplication processing layer

Concerned with providing application specific functionality e.g., in a banking system, banking functions such as open account, close account, etc.

Data management layerConcerned with managing the system databases

l 13l COMP201 - Software Engineering

Page 14: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

Application Layers

Presentation layer

Application processinglayer

Data managementlayer

l 14l COMP201 - Software Engineering

Page 15: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

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.

l 15l COMP201 - Software Engineering

Page 16: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

Thin and Fat Clients

Thin-clientmodel

Fat-clientmodel Client

Client

Server

Data managementApplicationprocessing

Presentation

Server

Datamanagement

PresentationApplication processing

l 16l COMP201 - Software Engineering

Page 17: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

Thin Client Model

Used when legacy systems are migrated to client server architectures. The legacy system acts as a server in its own right with a

graphical interface implemented on a clientA major disadvantage is that it places a heavy processing

load on both the server and the network

l 17l COMP201 - Software Engineering

Page 18: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

Fat Client Model

More processing is delegated to the client as the application processing is locally executed

Most suitable for new client-server 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

l 18l COMP201 - Software Engineering

Page 19: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

A Client-Server ATM System

Account server

Customeraccountdatabase

Tele-processing

monitor

ATM

ATM

ATM

ATM

l 19l COMP201 - Software Engineering

Page 20: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

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

A more scalable architecture - as demands increase, extra servers can be added to the data management or application processing layers.

l 20l COMP201 - Software Engineering

Page 21: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

A 3-Tier Client-Server Architecture

Client

Server

Datamanagement

PresentationServer

Applicationprocessing

l 21l COMP201 - Software Engineering

Page 22: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

An Internet Banking System

Database server

Customeraccountdatabase

Web server

Client

Client

Client

Client

Account serviceprovision

SQLSQL query

HTTP interaction

l 22l COMP201 - Software Engineering

Page 23: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

Use of Client-Server Architectures

l COMP201 - Software Engineering l 23

Architecture Applications

Two-tier C/S with thin clients

Legacy system applications where separating application processing and data management is impractical. Computationally-intensive applications such as compilers with little or no data management. Data-intensive applications (browsing/querying) with little or no application processing.

Two-tier C/S with fat clients

Applications where processing uses off-the-shelf software (eg. Microsoft Excel) on the client. Applications with relatively stable end-user functionality used in an environment with well-established system management.

Three-tier or multi-tier C/S architecture

Large-scale applications with hundreds or thousands of clients. Applications where both the data and applications are volatile.

Page 24: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

3. Distributed Object ArchitecturesThere is no distinction in a distributed object

architectures between clients and serversEach distributable entity is an object that

provides services to other objects and receives services from other objects

Object communication is through a middleware system called an object request broker (software bus)

However, they can be more complex to design than client-server systems

l 24l COMP201 - Software Engineering

Page 25: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

Distributed Object Architecture

Software bus

o1 o2 o3 o4

o5 o6

S (o1) S (o2) S (o3) S (o4)

S (o5) S (o6)

l 25l COMP201 - Software Engineering

Page 26: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

Advantages of Distributed Object Architecture

It allows the system designer to delay decisions on where and how services should be providedService-providing objects can execute on any node of the

network and thus the distinction between thin/fat-client models becomes irrelevant.

It is a very open system architecture that allows new resources to be added to it as requiredObject communication standards have been developed

allowing objects written in different languages to communicate with each other.

l 26l COMP201 - Software Engineering

Page 27: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

Advantages of Distributed Object Architecture

The system is flexible and scalableNew objects can be added as the load on the system

increases without disrupting the other system objects. Replicated object can be created to cope with load.

It is possible to reconfigure the system dynamically with objects migrating across the network as requiredThis may be important when there is fluctuating patterns of

demand on services. A service-providing object can migrate to the same processor as service-requesting objects, thus improving performance.

l 27l COMP201 - Software Engineering

Page 28: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

Lecture Key Points

Client-server systems are distributed systems where the system is modelled as a set of services provided by servers to client processes.

In a client-server system, the user interface always runs on a client and data management is always provided by a shared server.

Application functionality may be implemented on the client computer or the server.

l COMP201 - Software Engineering l 28

Page 29: Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: coopes/comp201 Lecture

Lecture Key Points

In a distributed object architecture, there is no distinction between clients and servers; objects provide general services that may be called on by other objects.

Distributed object systems require middleware to handle object communications and to allow objects to be added or removed from the system.

l COMP201 - Software Engineering l 29