Distributed Systems Models

A system design perspective

Models of Distributed Systems

 The design of distributed systems can be describes by three

models:
 Physical Models:
 Consider the types of computers and devices that constitute a system and their interconnectivity, without
details of specific technologies

 Architectural Models:
 Client-server and peer-to-peer are two of the most commonly used forms of architectural model for
distributed systems.

 Fundamental Models:
 take an abstract perspective in order to describe solutions to individual issues faced by most distributed
systems.
Difficulties and threats
the designers of distributed systems face

 Widely varying modes of use: some web pages are accessed several million times a day. Some parts
of a system may be disconnected, or poorly connected some of the time – for example, when mobile
computers are included in a system.
 Some applications have special requirements for high communication bandwidth and low latency –
for example, multimedia applications.
 Wide range of system environments: A distributed system must accommodate[ adapt ]
heterogeneous hardware, operating systems and networks. The networks may differ widely in
performance – wireless networks operate at a fraction of the speed of local networks.
 Systems of widely differing scales, ranging from tens of computers to millions of computers, must
be supported.
 Internal problems: Non-synchronized clocks, conflicting data updates and many modes of hardware
and software failure involving the individual system components.
 External threats: Attacks on data integrity and secrecy, denial of service attacks.
Physical models

 A physical model is a representation of the

underlying hardware elements of a
distributed system that abstracts away from
specific details of the computer and
networking technologies employed.
Physical models
Early distributed systems

 Such systems emerged in the late 1970s and early 1980s in response to the emergence of
local area networking technology.
 These systems typically consisted of between 10 and 100 nodes interconnected by a local
area network, with limited Internet connectivity and supported a small range of services
such as shared local printers and file servers as well as email and file transfer across the
Internet.
 [ Specification ] Individual systems were largely homogeneous and openness was not a
primary concern.
 Providing quality of service was still very much in its infancy [ early stages ] and was a
focal [ central ] point for much of the research around such early systems.
Internet-scale distributed systems
 Larger-scale distributed systems started to emerge that interconnect large set of
nodes using the Internet.
 They incorporate large numbers of nodes and provide distributed system services
for global organizations and across organizational boundaries.
 Significant [ large ] level of heterogeneity.
 So open standards and associated middleware technologies such as CORBA and
more recently, web services, are needed.
 Additional services were employed to provide end-to-end quality of service
properties in such global systems.
Contemporary [ modern ] distributed
systems
 [ challenge ] New nodes other than desktop computers, which are relatively static:
remaining in one physical location,
 discrete: not embedded within other physical entities,
 and autonomous: mostly independent of other computers in terms of their physical
infrastructure.
 New trends significantly further developments in physical models:
 The emergence of mobile computing: led to physical models where nodes such as laptops or
smart phones may move from location to location in a distributed system.
 The emergence of ubiquitous [ widely ] computing: a move from discrete nodes to architectures
where computers are embedded in everyday objects and in the surrounding environment.
 The emergence of cloud computing: pools of nodes that together provide a given service.
Distributed systems of systems

 The emergence of ultra large-scale (ULS) distributed systems [www.sei.cmu.edu].

 A systems of systems: a complex system consisting of a series of subsystems that are
systems in their own.
 As an example of a system of systems, consider an environmental management system for
flood prediction:
 sensor networks deployed to monitor the state parameters relating to rivers.
 flood plains.
 coupled with systems that are responsible for predicting the likelihood of floods.
 by running (often complex) simulations on, for example, cluster computers.
Physical models

Generations of distributed systems: The overall historical development

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. This goal could be achieved by fulfilling a set of objectives.
 Major objectives are to make the system:
 reliable,
 manageable,
 adaptable and
 cost-effective.
 Architectural styles of distributed systems

 An architectural style is the way in which the components arranged

to construct the overall system, common styles are:
 client-server models,
 peer-to-peer approaches,
 distributed objects,
 distributed components, and
 distributed event based systems.

First we will look at the key elements of an architecture of a distributed system.

Architectural elements

 Architectural elements are built taking in mind answering the

following key questions:
 What are the entities that are communicating in the distributed system?
 How do they communicate, or, more specifically, what communication
paradigm [ type ] is used?
 What roles and responsibilities do they have in the overall architecture?
 How are they mapped on to the physical distributed infrastructure (what is
their placement [ position ])?
Communicating entities

 The entities that communicate in a distributed system are typically processes, coupled with
appropriate inter-process communication.
 Some systems, the communicated entities are just nodes, such as Wireless Sensor
Networks.
 In fact processes run as parallel threads, so threads are the communicating entities.
 This communication could be programmed as:
 Objects: In distributed object-based approaches, a computation consists of a number of
interacting objects, accessed via interfaces. (Ch5 and Ch8).
 Components: in addition to interfaces, they explicitly present other components/interfaces that
must be present for a component to fulfil its function. (Ch8)
 Web Services: web services are intrinsically [
fundamentally ] integrated into the World Wide Web, using web standards to represent and
discover services. They use XML to exchange messages over Internet protocols. (Ch9)
Communication paradigms

 They are methods specify how entities communicate in a distributed system.

 Three types of communication paradigm are considered:
 Inter-process communication: refers to the relatively low-level support for
communication between processes in distributed systems, including:
 message-passing primitives,
 direct access to the API offered by Internet protocols (socket programming) and
 support for multicast communication. (CH 4).

 Remote invocation;
 Indirect communication.
Communication paradigms: Remote
invocation
 Two-Way communication: a sender and a receiver aware of each other, and a same time
exchange explicitly directing messages/invocations.
 Calling of a remote operation, procedure or method, as:
 Request-reply protocols
 Remote procedure calls (RPC)
 Remote method invocation (RMI)
Communication paradigms: Indirect
communication
 Through a third entity, allowing a strong degree of decoupling between senders and receivers. In particular:
(Ch6)
 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).
 Key techniques for indirect communication include:
 Group communication:
 one-to-many communication
 An entity need to receive messages join a group, each group has an identifier
 A sender sends to a group so not aware of receivers
 Message queues:
 Provides a point-to-point indirect communication
 A sender pokes a message into the queue
 A receiver (then) peeks the message from the queue.
Communication paradigms: Indirect
… communication
 Tuple spaces:
 processes share a distributed repository of specified data structures,
 a process sends a tuple, other processes can access relevant tuples of interest, or remove tuples,
 tuples are persistent, so no need for sender and receiver to exist at the same time.

 Distributed shared memory:

 provide an abstraction for sharing data between processes that do not share physical memory.
 Programmers can abstract reading or writing (shared) data structures as if they were in their own local
address spaces.
 presenting a high level of distribution transparency.
 The underlying infrastructure must ensure a copy is provided in a timely manner and also deal with issues
relating to synchronization and consistency of data.
Roles and responsibilities

 Two architectural styles: client-server and peer-to-peer

 Client Server model
 A server process provides services to requested client processes, using HTTP for example, a
server could be a client for another server.
… Roles and responsibilities

 Peer-to-Peer style: all of the processes involved in a task or activity play similar roles,
interacting cooperatively as peers without any distinction between client and server
processes

The development of peer-to-peer

applications and middleware to support
them is described in depth in Ch10.
Placement

 how entities such as objects or services map on to the underlying physical distributed
infrastructure which will consist of a large number of machines interconnected by a
network.
 Possible placement strategies:
 Mapping of services to multiple servers:
 Services may be implemented as several server processes in separate host computers interacting as
necessary to provide a service to client processes.
 The servers may partition the set of objects on which the service is based and distribute those objects
between themselves, such as web servers.
 or they may maintain replicated copies of them on several hosts, for example Network Information
Service (NIS), it replicates the file of users’ authentication on 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.
 Examples:
 Web browsers maintain a cache of recently visited web pages.
 Domain Name Servers maintain a cache of visited domain names and their IP addresses.
 Mobile code:
 Applets are a well-known and widely used example of mobile code.
 If a user clicks a link of an Applet, the code is downloaded from the server to the client, and run on the
client machine by a browser.
 Mobile agents:
 A mobile agent is a running program (including both code and data) that travels from one computer to
another in a network carrying out a task on someone’s behalf.
Architectural patterns

 Layering
 Tiered architecture
 The role of AJAX:
 Thin clients
 Other commonly occurring patterns (can be found in
sec 2.3.2 Page 57)
 Layered Architecture
• A platform: consists of the lowest-level hardware and software (OS), which are implemented
independently in each computer, bringing the system’s programming interface up to a level that
facilitates communication and coordination between processes. Intel x86/Windows, Intel x86/Solaris,
Intel x86/Mac OS X, Intel x86/Linux and ARM/Symbian (mobile OS) are major examples.

• Middleware:
• a layer of software whose purpose is to mask heterogeneity
and to provide a convenient programming model to
application programmers.
• Middleware is represented by processes or objects in a set of computers that
interact with each other to implement communication and resource-sharing
support for distributed applications.
• It supports abstractions such as remote method invocation; communication
between a group of processes; notification of events; the partitioning,
placement and retrieval of shared data objects amongst cooperating computers;
the replication of shared data objects; and the transmission of multimedia data
in real time.
Tiered architecture

 A technique to organize functionality of a given layer such that a service is divided onto
number of parties; three tasks that could be located:
 User interaction (interface)
 the detailed application-specific processing associated with the application
 persistent storage of the application, typically in a database management system
 for example, these three issues could be distributed on the:
 Two tier: the three aspects mentioned above must be partitioned into two processes, the client and
the server.
 Three tier: there is a one-to-one mapping from logical elements to physical servers and hence, for
example, the application logic is held in one place, which in turn can enhance maintainability of
the software.
The role of Asynchronous Javascript And
XML AJAX
 An extension to the standard client-server style of interaction (JavaScript) used in the
World Wide Web
 AJAX presents fine-grained communication between a Javascript front-end program
running in a web browser and a server-based back-end program.
 Traditionally, web pages retrieved from a web server cannot be directly updated when the
information is updated on the server, it must be re-loaded.
 AJAX enables Javascript front-end programs to request new data directly from server
programs.
 AJAX Example
<!DOCTYPE html> xhttp.open("GET", "ajax_info.txt", true);
xhttp.send();
<html> }
<body> </script>
</body>
<div id="demo"> </html>

<h1>The XMLHttpRequest Object</h1>

<button type="button" onclick="loadDoc()">Change Content</button>

This AJAX code updates the content of
</div> a page by loading and presenting a file:
<script> “ajax_info.txt”, when a button “Change
function loadDoc() { Content” is pressed
var xhttp = new XMLHttpRequest();

xhttp.onreadystatechange = function() {

if (this.readyState == 4 && this.status == 200) {

Other examples could be found in:
document.getElementById("demo").innerHTML =
W3schools.com/xml/
this.responseText;

};
Thin clients

 Thin client refers to a software layer that supports a window-based user interface
that is local to the user while executing application programs accessing services on
a remote computer
 The trend in distributed computing is towards moving complexity away from the
end-user device towards services in the Internet.
 This is most apparent in the move towards cloud computing.
 This trend enables access to sophisticated networked services, provided for example
by a cloud solution, with a low resourced client device.
 Virtual network computing (VNC) was proposed for example (RealVNC
[www.realvnc.com]), to transmit keyboard, video and mouse events over IP (KVM-
over-IP).
Associated middleware solutions

 Categories of middleware

 Limitations of middleware
Categories of middleware

 Earliest instances of middleware:

 Remote procedure calling packages such as Sun RPC (Chapter 5) and
 Group communication systems such as ISIS (Chapters 6 and 18).
 Hybrid solutions: many distributed object platforms offer distributed event services to
complement the more traditional support for remote method invocation.
 component-based platforms (and indeed other categories of platform) also support web
service interfaces and standards, for reasons of interoperability.
Limitations of middleware

 Many distributed applications rely entirely on the services provided by middleware to

support their needs for communication and data sharing.
 For example, an application that is suited to the client-server model such as a database of names
and addresses, can rely on middleware that provides only remote method invocation.
 Much has been achieved in simplifying the programming of distributed systems through
the development of middleware support, but some aspects of the dependability of systems
require support at the application level. (Large electronic mail example)
 Some communication-related functions can be completely and reliably implemented by the
end points of the communication system. Therefore, providing that function as a feature of
the communication system itself is not always sensible.