Chapter 2 Architectural Models

Chapter 2: Architectural Models
From Coulouris, Dollimore, Kindberg and

Blair
Distributed Systems:
Concepts and Design
Edition 5, © Addison-Wesley 2012
DISTRIBUTED SYSTEM DESIGN
• There are various descriptive models used to describe the properties and
design issues of Distributed systems:
• Physical Models: these models describe the system in terms of hardware
(Computer, other devices and cell phones) and their interconnecting network
• Architectural Models: in terms of computational and communication tasks
performed by its computational elements as individual as well as aggregate
and communication interconnection
• Fundamental Models: an abstract perspective to examine the individual
aspect of distributed system e.g., interaction models, failure models, security
models.
Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 2
© Pearson Education 2012
• Physical Models:
• Baseline physical model: is a minimal physical model
• Computer node interconnected by a network for required passing of
messages.
• Three generations of baseline model
• Emerged in late 1970s and early 1980s after LAN and Ethernet
• Typically consisted of 10 to 100 nodes
• Limited Internet connectivity
• Limited services like Shared local printer, file servers, email, file
transfer across internet.
• Internet-scale distributed systems: emerged in 1990s on its
foundation after dramatic growth of the Internet (Google in
1996)
• Exploits the internet to become truly global

• High level of heterogeneity in terms of networks, computer
architecture, operating system, language employed, and
development team.
• Emphasized on open standards and middleware
technologies e.g., CORBA and web services.
• Additional services are end-to-end QoS.
• Contemporary distributed systems: emerging of mobile phones
demanded service discovery and spontaneous interoperation
• Ubiquitous computing led to move from discrete nodes to architecture
with embedded computers in everyday life objects
• Emergence of cloud and cluster computing led to move from
autonomous nodes for specific role to pools of nodes providing service
collectively
• Heterogeneity increased from tinniest device to a grid computing
architecture
• Distributed System of Systems: ultra large-scale (ULS) distributed
Systems
• This architecture is a system-of-systems
• A system of systems can be defined as a complex system consisting of a
series of subsystems that are systems in their own right and that come
together to perform a particular task or tasks.
• For example, an environmental management system for flood prediction
• Can be a sensor networks deployed to monitor the state of various
environmental parameters relating to rivers, flood plains, tidal effects
and so on.
FIGURE 2.1: GENERATIONS OF DISTRIBUTED 7
SYSTEMS
Instructor’s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5
• Architectural Models:
• The architecture of a system is its structure in terms of
separately specified components and their interrelationships.
• The overall goal is to ensure that the structure will meet present
and likely future demands on it.
• It focuses to make the system reliable, manageable, adaptable,
and cost-effective.
• It should be architectural design of the building that depict not
only the appearance of the building but also its general
structure and architectural style.
• It is a consistent frame of reference for design.
• Architectural styles of distributed systems are:
• Client-server model
• Peer-to-peer approaches
• Distributed objects
• Distributed components
• Distributed event bases systems
• Architectural elements
• What are entities communicating in distributed
system?
• (How they comm)What communication paradigm is
used?
• What are their roles and responsibilities in the
system.
• What is their placement?
• Architectural Models: Architectural elements
• Communicating Entities
• Typically processes or nodes or threads
communicate in distributed systems
• Hence an inter-process paradigm, or sensor
networks, or multithreaded environment prevails
• In programming perspective the abstraction
proposed is:
• Objects, components, web Services,
• Communication paradigms: Three types
• Inter-process communication: a low-level support for communication
(message passing paradigm, socket programming, multicast
communication)
• remote invocation: a method for two-way communication between entities
resulting in calling remote operation, procedure, method
• Request reply protocol: Remote Procedure calls, Remote Method
Invocation
• In all of the above communications sender direct messages/ invocation to
receiver
• Sender and receiver knows the identity of each other and both parties exist
at the same time 12
• Communication paradigms: Three types
• indirect communication
• Communication through third entity
• Introduces strong degree of decoupling between sender and receiver
• Senders do not need to know who they are sending to (space uncoupling).
• Senders and receivers do not need to exist at the same time (time uncoupling).
• Group communication
• Publish-subscribe system
• Message queues
• Tuple spaces
• Distributed shared memory
FIGURE 2.2 COMMUNICATING ENTITIES AND
14
COMMUNICATION PARADIGMS
• Roles and Responsibilities:
• System elements object, components, or services (web
services)collectively called processes.
• Work together to perform a useful activity.
• Each process takes on a role or responsibility.
• Two architectural styles
• Client-Server
• Peer-to-Peer
• Roles and Responsibilities: Two architectural styles
• Client-Server
• Historic and most widely employed.
• Web server is client for local file server
• Web server and other internet servers are client of DNS
service (Translate Domain  network address)
• Search engine  use web crawlers running in background
• Web crawlers  other web servers (HTTP requests)
FIGURE 2.3 CLIENTS INVOKE INDIVIDUAL
SERVERS
• Roles and Responsibilities: Two architectural styles
• Peer-to-Peer
• No distinction of client & Server Process
• All processes run the same program and same set of
interfaces to each other
• Bottleneck created on a centralized resource has been
overcome
• BitTorrent.
FIGURE 2.4A PEER-
TO-PEER
ARCHITECTURE
• Placement: How entities (objects or services) are
map onto the physically distributed infrastructure.
• Placement is crucial in terms of characteristics of
the distributed system.
• Various issues must be taken into consideration
while placement of machines or processes.
• Placement can only be optimally decided if we have
a strong application knowledge.
• Placement:
• Following placement strategies can be adopted while
considering the design of the system:
• Mapping of services to multiple servers
• Caching
• Mobile code
• Mobile agents
• Placement:
• Mapping of services to multiple servers
• several server processes in separate host computers
interacting as necessary to provide services to client
processes.
• Servers may
• partition and distribute set of objects on which the
service is based among themselves. (Web)
• replicate them on several hosts. (Sun NIS)
FIGURE 2.4B A SERVICE PROVIDED BY MULTIPLE SERVERS
• Placement:
• Caching:
• A cache is a store of recently used data objects that is closer to one
client or a particular set of clients than the objects themselves.
• When a new object is received from a server it is added to the
local cache store replacing the older one.
• When an object is needed by a client.
• Cache service checks the object first in cache (if up-to-date copy available)
• If not, an up-to-date copy is fetched.

• Caches may be collocated with each client or
• May be stored in proxy server and shared by clients.
FIGURE 2.5 WEB PROXY SERVER
• Placement:
• Caching:
• Caches are extensively used.
• Web browsers maintain a cache in the local file system of client.
• Special HTTP request is sent to the server to request an up-to-
date copy.
• Proxy server may be used to store the shared cache of web
resources.
• This approach will increase the availability and performance of
service.
• Placement:
• Mobile code:
• the code is downloaded to the browser and runs there
• This approach can provide good response and does not suffer
from delays of network communication.
• Another example is providing push notification in which a
special code is stored on the client side.
FIGURE 2.6 WEB APPLETS
• Placement:
• Mobile agents:
• Is a running program that travels through computer to
computer in a network carrying out a task on someone’s
behalf.
• Collecting information and returning with results.
• This approach reduces the time and communication cost of
remote invocations with local ones.
• Because of security threats associated with mobile agents the
applicability of the Mobile agents has become limited.
ARCHITECTURAL PATTERNS
• There are different architectural patterns.
• Layering:
• Layering is a concept from abstraction
• Each upper layer making use of the services offered by the
layer below
• Implementation details of each layer is hidden from other
layer beneath any layer.
• A distributed service can be provided by one or more server
processes interacting with each other and client processes.
• Example, Network time services (NTP)
FIGURE 2.7 SOFTWARE AND HARDWARE
SERVICE LAYERS IN DISTRIBUTED SYSTEMS
ARCHITECTURAL PATTERNS
• There are different architectural patterns.
• Tiered Architecture:
• This architecture is complementary to layering.
• Layering is vertical organization of services into layers.
• Tiering is technique to organize functionality of a given layer and
place it into appropriate server or physical nodes.
• Functional decomposition is as:
• Presentation logic, application (Business) logic, data logic
• Two-Tier
• Three Tier
• N-Tier
FIGURE 2.8: TWO-TIER AND
THREE-TIER
ARCHITECTURES
33
FIGURE 2.9: AJAX EXAMPLE: SOCCER SCORE 34
UPDATES
•new Ajax.Request('scores.php?
game=Arsenal:Liverpool’,
{onSuccess: updateScore});
•function updateScore(request) {
.....
•( request contains the state of the Ajax request including the returned result.
•The result is parsed to obtain some text giving the score, which is used to
update the relevant portion of the current page.)
•.....
•}
34
FIGURE 2.10: THIN CLIENTS AND
COMPUTE SERVERS
Compute server
Network computer or PC
Thin network Application

Client Process
FIGURE 2.11: THE WEB SERVICE 36
ARCHITECTURAL PATTERN
FIGURE 2.12: CATEGORIES OF 37
MIDDLEWARE
FIGURE 2.13: REAL-TIME
ORDERING OF EVENTS
FIGURE 2.14: PROCESSES AND
CHANNELS
FIGURE 2.15: OMISSION AND
ARBITRARY FAILURES
Class of failure Affects Description
Fail-stop Process Process halts and remains halted. Other processes may
detect this state.
Crash Process Process halts and remains halted. Other processes may
not be able to detect this state.
Omission Channel A message inserted in an outgoing message buffer never
arrives at the other end’s incoming message buffer.
Send-omission Process A process completes a send, but the message is not put
in its outgoing message buffer.
Receive-omission Process A message is put in a process’s incoming message
buffer, but that process does not receive it.
Arbitrary Process or Process/channel exhibits arbitrary behaviour: it may
(Byzantine) channel send/transmit arbitrary messages at arbitrary times,
commit omissions; a process may stop or take an
incorrect step.
FIGURE 2.11: TIMING FAILURES
Class of FailureAffects Description
Clock Process Process’s local clock exceeds the bounds on its

rate of drift from real time.
Performance Process Process exceeds the bounds on the interval
between two steps.
Performance Channel A message’s transmission takes longer than the
stated bound.
FIGURE 2.17: OBJECTS AND
PRINCIPALS
FIGURE 2.18: THE ENEMY
Copy of m
The enemy
m’
Process p m Process q
Communication channel
FIGURE 2.19: SECURE CHANNELS
Principal A Principal B
Process p Secure channel Process q

Chapter 2 Architectural Models

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 2 Architectural Models

Uploaded by

Copyright:

Available Formats

Chapter 2: Architectural Models

From Coulouris, Dollimore, Kindberg and

• Exploits the internet to become truly global

• If not, an up-to-date copy is fetched.

Thin network Application

Class of FailureAffects Description

Clock Process Process’s local clock exceeds the bounds on its

Process p Secure channel Process q

You might also like