Transcript Introduction - kashanu.ac.ir

Distributed Configuration
1. T.C Software + T.C. Hardware = One OS
in a multiprocessor system (DOS)
Communication: shared memory
2. T.C. Software + L.C. Hardware =
Homogeneous OS in network (DOS)
Communication: message passing
3. L.C. Software + L.C. Hardware =
Heterogeneous OS in network (NOS)
Communication: file sharing, network
commands
1(DOS)
2(DOS)
3(NOS)
Transparency
very high
high
low
Multi OS
no
no
yes
OS Copies
1
>1
>1
Communication
shared
memory
messages
files
Resource
Management
global,
central
global,
distributed,
local
Scalability
no
reasonable
yes
Openness
no
no
yes
NOS & DOS
Communications in NOS & DOS
NOS->DOS
transparency
•
•
•
L.C. Software + L.C. Hardware + Middleware:
NOS->DOS :
near really distributed system + complexity reduction
Middlewares
•
•
1. distributed file systems
file level transparency (remote file using)
•
•
2. RPC
process level transparency (remote procedure call)
•
•
3. distributed objects
object level transparency (remote object call)
•
•
4. distributed documents (web)
document level transparency (remote document call)
Communiction in middlewares
like ORB
T.C. software + L.C. hardware ->
T.C software + T.C harware
why?
communication by shared data
(control mechanisms: semaphores , monitors)
is easier
communication by message
(control mechanisms : algorithms:
reliable group communication)
Solution: virtual memory
(DSM)
Distrubution Architectures
Multiprocessor architectures
Sens or
p roces sor
Sens or
co ntro l
p roces s
Traffic flow
p roces sor
Disp lay
p roces s
Traffic ligh t con tro l
p roces sor
Ligh t
co ntro l
p roces s
Traffic ligh ts
Trafficflow sensors and
cameras
•
Operator co nso les
A multiprocessor traffic control system
characteristics
•
Simplest distributed system model.
•
System composed of multiple processes
which may 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 dispatcher.
Client-server architectures
c3
c2
c4
c1 2
c1 1
s4
s1
c1
Serv er pro cess
c1 0
c5
s2
c6
c7
Client pro cess
s3
c9
c8
Computers in a C/S network
c1
CC1
c2
CC2
c3 , c4
CC3
Netwo rk
s1 , s 2
s3 , s 4
SC2
Serv er
co mpu ter
SC1
c5 , c6, c7
c8 , c9
CC4
CC5
c1 0 , c1 1 , c1 2
CC6
Client
co mpu ter
characteristics
-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
Film and picture library
Logical design of C/S
characteristics
Presentation layer
presenting the results of a computation to system
users and with collecting user inputs.
Application processing layer
providing functionality e.g., in a banking system,
banking functions such as open account, close
account, etc.
Data management layer
managing the system databases.
Thin and fat clients
characteristics
Thin:Used when legacy systems are migrated to
client server architectures. The legacy system acts
as a server with a graphical interface implemented
on a client.
Fat:suitable for new C/S systems where the
capabilities of the client system are known in advance.
More complex than a thin client model.
Fat C/S
ATM
ATM
Acco u nt server
Tel ep roces sin g
mon ito r
ATM
ATM
Cus tomer
acco un t
d atabase
New Approach
(using mobile code: applet, activex
Fat + Thin: A 3-tier C/S architecture
characteristics
-each of the application architecture layers may
execute on a separate processor.
-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.
An internet banking system
Client
Client
HTTP interactio n
SQL q u ery
Acco u nt service
p rov is ion
Client
Client
Database server
Web serv er
SQL
Cus tomer
acco un t
d atabase
Use of C/S architectures
Architecture
Applications
thin
-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 and querying) with little or no
application processing.
fat
-Applications where application processing is provided by off-the-shelf
software (e.g. Microsoft Excel) on the client.
-Applications where computationally-intensive processing of data (e.g.
data visualisation) is required.
Three-tier
-Large scale applications with hundreds or thousands of clients
-Applications where both the data and the application are volatile.
-Applications where data from multiple sources are integrated.
Distributed object architectures
o1
o2
o3
o4
S (o 1)
S (o 2)
S (o 3)
S (o 4)
Object req u est brok er
o5
o6
S (o 5)
S (o 6)
characterictics
No distinction between clients and servers.
Each distributable entity is an object that provides
services to other objects and receives services from
other objects.
Object communication: a middleware:ORB.
More complex to design than C/S systems.
Advantages
allows to delay design decisions: where and how
services should be provided.
a very open system architecture: new resources to be
added to it.
The system is flexible and scaleable.
reconfigure the system dynamically with objects
migrating across the network as required.
A data mining system
Database 1
In teg rator 1
Database 2
R ep ort gen .
Vis ualis er
In teg rator 2
Database 3
Disp lay

new types of relationship to be mined by adding new integrator objects.