Download 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
Senso r
p rocessor
Senso r
con trol
p rocess
Traffic flo w
p rocessor
Disp lay
p rocess
Traffic ligh t con trol
p rocessor
Ligh t
con trol
p rocess
Traffic ligh ts
Traffic flowsensors and
cameras
•
Op erato r con soles
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
c12
c11
s4
s1
c1
Server p rocess
c10
c5
s2
c6
c7
Client p rocess
s3
c9
c8
Computers in a C/S network
c1
CC1
c2
CC2
c3, c4
CC3
Netwo rk
s1 , s2
s3 , s4
SC2
Server
comp uter
SC1
c5, c6, c7
c8, c9
CC4
CC5
c10 , c11 , c12
CC6
Client
comp uter
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
AT M
AT M
Account serv er
Telep rocessing
m on it o r
AT M
AT M
Cust o mer
acco unt
dat abase
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
HTT P interaction
SQL query
Account serv ice
p rov isio n
Client
Client
Database server
Web server
SQL
Custo mer
acco unt
database
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 request 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
Dat abase 1
In t egrat or 1
Dat abase 2
Rep ort gen.
Visualiser
In t egrat or 2
Dat abase 3
Disp lay

new types of relationship to be mined by adding new integrator objects.