Distributed Systems Architectures

Architectural design for software

that executes on more than one
processor

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 1

Objectives

To explain the advantages and disadvantages of
distributed systems architectures

To describe different approaches to the
development of client-server systems

To explain the differences between client-server
and distributed object architectures

To describe object request brokers and the
principles underlying the CORBA standards

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 2

Topics covered

Multiprocessor architectures

Client-server architectures

Distributed object architectures

CORBA

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 3

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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 4

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.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 5

Distributed system characteristics

Resource sharing

Openness

Concurrency

Scalability

Fault tolerance

Transparency

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 6

Distributed system disadvantages

Complexity

Security

Manageability

Unpredictability

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 7

Design issue Description
Resource The resources in a distributed system are spread across different
identification computers and a naming scheme has to be devised so that users can
discover and refer to the resources that they need. An example of
such a naming scheme is the URL (Uniform Resource Locator) that
is used to identify WWW pages. If a meaningful and universally
understood identification scheme is not used then many of these
resources will be inaccessible to system users.
Communications The universal availability of the Internet and the efficient
implementation of Internet TCP/IP communication protocols means
that, for most distributed systems, these are the most effective way
for the computers to communicate. However, where there are
specific requirements for performance, reliability etc. alternative
approaches to communications may be used.
Quality of service The quality of service offered by a system reflects its performance,
availability and reliability. It is affected by a number of factors such
as the allocation of processes to processes in the system, the
distribution of resources across the system, the network and the
system hardware and the adaptability of the system.
Software The software architecture describes how the application
architectures functionality is distributed over a number of logical components and
how these components are distributed across processors. Choosing
the right architecture for an application is essential to achieve the
desired quality of service.

Issues in distributed system design

Distributed systems archiectures

Client-server architectures
• Distributed services which are called on by clients. Servers that
provide services are treated differently from clients that use
services

Distributed object architectures
• No distinction between clients and servers. Any object on the
system may provide and use services from other objects

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 9

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

Examples
• Transaction processing monitors
• Data convertors
• Communication controllers

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 10

Multiprocessor architectures

Simplest distributed system model

System composed of multiple processes which
may (but need not) execute on different processors

Architectural model of many large real-time
systems

Distribution of process to processor may be pre-
ordered or may be under the control of a
despatcher

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 11

 p S
rcpS oecnsor T r
p af
o ice f
sl
o
w
r T
r
a
f
i
c
p
r
ol
g
h
est
c
o
n
tr
o
l
A multiprocessor traffic control system

eorntsorl D iproscpelay Li
g
ht
s pesl
c
on
ro
T
rafnicdflow
sreanors O
am peratorconsoles T
r
a
f
i
cl
g
h
t
s
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 12
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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 13

 c
2 c
3 c
4 c1
2c
1 S
e
r
vp
r
o
ce
s
A client-server system

c1c5s1s2s4s3c1c09C
c6c7 c8 l
i
e
n
tp
r
o
c
es
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 14
 Cc
1
1 C 2 c
2 c
3
,
c
C
34
Computers in a C/S network

sS s2 N
1,C etw
ork sS s14coS
3,C eC
rm
tcomv
p
u e
rlipeuntr
c5,c6,c7C
4C 5Cc
8
,
c
9 c
1
0
,
c
61
,
c12
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 15
Layered application architecture

Presentation layer
• Concerned with presenting the results of a computation to
system users and with collecting user inputs

Application 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 layer
• Concerned with managing the system databases

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 16

Application layers
P
rA
pD es
laictatmn
t
a
io
n i
o
p
rllayn
o n
l
a
y
c
e
se
r
i
n
g
eyg erm
nt
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 17
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.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 18

 T
him
n -ocdlien
tC P
r
e
s
n
t
a
lientPi
o
n
Thin and fat clients

S
e
D
a
t
m
a
A
p
l
r
o r
v
n
i
c
e
s g
e
m
t
i
on
t
F
amt-ocdlientC r
e
s
n
A
p
l
i
ct
a
i
o
n
lient mp
r
o
ce
s
i
n
g S
e
D r
v
a
tangem
nt
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 19
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 client

A major disadvantage is that it places a heavy
processing load on both the server and the
network

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 20

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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 21

 A
A
T
M
A
T
MT
Mp
r
o
mA
c
o
T
e
l
-
c
s
i
n
g
t
o
ru
n
t
s
C
u
a
de
r
v
t
o
m
e
c
u
n
t
b
a
sr
A client-server ATM system

A
T
M
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 22
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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 23

 P
r
e
sn
t
a
i
o
n Se rv S e
rv
A 3-tier C/S architecture

C
lient A D
proliecsatiogn m a
tangem
nt
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 24
 C
lCilieennttH
T
P
interactionA
W
e
b
s
e
An internet banking system

c
o
u
n
t
p
r
v
i
sr
v
i
c
e
o
n S
Q
L
q
u
e
r
yD
a
t
S
Q
Lb
a
s
e
r
v
C
u
t
o
m
c
u
n
t
d
a
b
a
s
ee
r
C
lC
ilieenntt
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 25
Use of C/S architectures
Architecture Applications
Two-tier C/S Legacy system applications where separating application
architecture with processing and data management is impractical
thin clients Computationally-intensive applications such as compilers with
little or no data management
Data-intensive applications (browsing and querying) with little
or no application processing.
Two-tier C/S Applications where application processing is provided by
architecture with COTS (e.g. Microsoft Excel) on the client
fat clients Applications where computationally-intensive processing of
data (e.g. data visualisation) is required.
Applications with relatively stable end-user functionality used
in an environment with well-established system management
Three-tier or Large scale applications with hundreds or thousands of clients
multi-tier C/S Applications where both the data and the application are
architecture volatile.
Applications where data from multiple sources are integrated

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 26

Distributed object architectures

There is no distinction in a distributed object
architectures between clients and servers

Each 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, more complex to design than C/S systems

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 27

 o
S1 o
(o1) S2
(o2)S o
3
S
(
o
3
) So
4
(
o
4
)
Distributed object architecture

o5 o
f
t
w
a
r
eb
u
s
(o5) S
S o6
()
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 28
Advantages of distributed object architecture

It allows the system designer to delay decisions
on where and how services should be provided

It is a very open system architecture that allows
new resources to be added to it as required

The system is flexible and scaleable

It is possible to reconfigure the system
dynamically with objects migrating across the
network as required

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 29

Uses of distributed object architecture

As a logical model that allows you to structure and
organise the system. In this case, you think about
how to provide application functionality solely in
terms of services and combinations of services

As a flexible approach to the implementation of
client-server systems. The logical model of the
system is a client-server model but both clients and
servers are realised as distributed objects
communicating through a software bus

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 30

 D
aD
tatbbaassee12 Integrator1R
A data mining system
eV
p o
risuatligseenr.
Datbase3 D Int
eg rat
or2 isplay
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 31
Data mining system

The logical model of the system is not one of
service provision where there are distinguished
data management services

It allows the number of databases that are
accessed to be increased without disrupting the
system

It allows new types of relationship to be mined by
adding new integrator objects

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 32

CORBA

CORBA is an international standard for an Object
Request Broker - middleware to manage
communications between distributed objects

Several implementation of CORBA are available

DCOM is an alternative approach by Microsoft to
object request brokers

CORBA has been defined by the Object
Management Group

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 33

Application structure

Application objects

Standard objects, defined by the OMG, for a
specific domain e.g. insurance

Fundamental CORBA services such as directories
and security management

Horizontal (i.e. cutting across applications)
facilities such as user interface facilities

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 34

 A
pobljiecatsionO
CORBA application structure

bjectC
reO
qu
eRD
f
a
sBo
m
c
tAl a
i
t
e
bsro
k n
es
rervicesCH
o
r
i
z
o
n
t
O
R
B
A
f
c
ia
l
e
s
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 35
CORBA standards

An object model for application objects
• A CORBA object is an encapsulation of state with a well-defined,
language-neutral interface defined in an IDL (interface definition
language)

An object request broker that manages requests for
object services

A set of general object services of use to many
distributed applications

A set of common components built on top of these
services

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 36

CORBA objects

CORBA objects are comparable, in principle, to
objects in C++ and Java

They MUST have a separate interface definition
that is expressed using a common language (IDL)
similar to C++

There is a mapping from this IDL to programming
languages (C++, Java, etc.)

Therefore, objects written in different languages
can communicate with each other

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 37

Object request broker (ORB)

The ORB handles object communications. It
knows of all objects in the system and their
interfaces

Using an ORB, the calling object binds an IDL
stub that defines the interface of the called object

Calling this stub results in calls to the ORB which
then calls the required object through a published
IDL skeleton that links the interface to the service
implementation

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 38

 So 1
(Iso1
)D So
2
(
o
2
)
L
ORB-based object communications

tO u
bjectRb s
equestBI
k
eD
L
l
t
o
n
ror
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 39
Inter-ORB communications

ORBs are not usually separate programs but are a
set of objects in a library that are linked with an
application when it is developed

ORBs handle communications between objects
executing on the sane machine

Several ORBS may be available and each computer
in a distributed system will have its own ORB

Inter-ORB communications are used for distributed
object calls

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 40

 So 1
(ID
o1
)LS o
2
(ID
Inter-ORB communications

2) S
oL o 3
(ID
)LS o
4
(ID
oL
4)
O
bjectR
equestB
rokerN etw
orkO
b
j e
c
tR
e
q
ue
s
t
B
r
ok e
r
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 41
CORBA services

Naming and trading services
• These allow objects to discover and refer to other objects on the
network

Notification services
• These allow objects to notify other objects that an event has
occurred

Transaction services
• These support atomic transactions and rollback on failure

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 42

Key points

Almost all new large systems are distributed systems

Distributed systems support resource sharing,
openness, concurrency, scalability, fault tolerance
and transparency

Client-server architectures involve services being
delivered by servers to programs operating on clients

User interface software always runs on the client and
data management on the server

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 43

Key points

In a distributed object architecture, there is no
distinction between clients and servers

Distributed object systems require middleware to
handle object communications

The CORBA standards are a set of middleware
standards that support distributed object
architectures

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 11 Slide 44