Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
0% found this document useful (0 votes)
122 views

Chapter Three Distributed Systems Models

Definitions Software Process Software Process Model (Humphrey 1990) the set of activities, methods, and practices that are used in the production and evolution of software Software Process Model one specific embodiment of a software process architecture (Humphrey 1990) Software project management
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
122 views

Chapter Three Distributed Systems Models

Definitions Software Process Software Process Model (Humphrey 1990) the set of activities, methods, and practices that are used in the production and evolution of software Software Process Model one specific embodiment of a software process architecture (Humphrey 1990) Software project management
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 50

CHAPTER THREE:DISTRIBUTED

SYSTEM MODELS

Reference: Chapter Two:


Coulouris, G., Dollimore, J., Kindberg, T., Blair,
G., Distributed Systems: Concepts and Design,
5th Edition, Addison Wesley, 2011
Outline
• The three basic ways to describe Distributed systems? –
1. Physical models
 consider DS in terms of hardware – computers and devices that
constitute a system and their interconnectivity, without details of
specific technologies
2. Architectural models
 describe a system in terms of the computational and communication
tasks performed by its computational elements.
 Client-server and
 peer-to-peer most commonly used
3. Fundamental models
 take an abstract perspective in order to describe solutions to individual
issues faced by most distributed systems
 interaction models
 failure models
 security models

Distributed systems by Patrick ndungu 2


Outline
 Difficulties and threats for distributed systems:
 Widely varying modes of use
 Wide range of system environments
 Internal problems
 External threats
1.Baseline Physical models
• minimal physical model of a distributed system as an extensible set of
computer nodes interconnected by a computer network for the required
passing of messages.
 Three generations of distributed systems
a) Early distributed systems
 10 and 100 nodes interconnected by a local area network
 limited Internet connectivity
 supported a small range of services e.g.
 shared local printers
 file servers
 email
Distributed systems by Patrick ndungu 3
3.1) Physical models cont…
 Three generations of distributed systems Cont…..
b) Internet-scale distributed systems
 extensible set of nodes interconnected by a network of
networks (the Internet)
c) Contemporary DS with hundreds of thousands nodes
+ emergence of:
i. mobile computing
 laptops or smart phones may move from location to location – need
for added capabilities (service discovery; support for spontaneous
interoperation)
ii. ubiquitous computing
 computers are embedded everywhere…IoTs
iii. cloud computing
 pools of nodes that together provide a given service

Distributed systems by Patrick ndungu 4


3.1) Physical models cont…
 Three generations of distributed systems Cont…..
d) Distributed systems of systems (ultra-large-scale
(ULS) distributed systems)
significant challenges associated with contemporary DS
Generations of distributed systems

Distributed systems by Patrick ndungu 5


3.2. Architectural Models
3.2: Architectural Models

 Major concerns:
 make the system reliable, manageable, adaptable and cost effective
3.2.1 Architectural elements
• What are the entities that are communicating in the distributed
system?
• How do they communicate, or, more specifically, what
communication paradigm is used?
• What (potentially changing) roles and responsibilities
– do they have in the overall architecture?
• How are they mapped on to the physical distributed infrastructure
– what is their placement?

Distributed systems by Patrick ndungu 6


3.2 Architectural Models Cont…
Communicating entities
1. From system perspective: processes
in some cases we can say that:
1) nodes (sensors)
2) threads (endpoints of communication)
2. From programming perspective

a) Objects
 computation consists of a number of interacting objects representing natural units of decomposition
for the given problem domain
Objects are accessed via interfaces,
 with an associated interface definition language (IDL)

Distributed systems by Patrick ndungu 7


3.2 Architectural Models Cont…
Communicating entities
b) components – emerged due to some weaknesses with distributed objects
 offer problem-oriented abstractions for building distributed systems
 accessed through interfaces
 assumptions to components/interfaces that must be present (i.e.
making all dependencies explicit and providing a more complete
contract for system construction.)

c) web services
 closely related to objects and components
 intrinsically integrated into the World Wide Web
 using web standards to represent and discover services

Distributed systems by Patrick ndungu 8


3.2 Architectural Models Cont…
Communicating entities
c) web services
 The World Wide Web consortium (W3C):
Web service is a software application identified by a URI, whose
interfaces and bindings are capable of being defined, described
and discovered as XML artefacts. A Web service supports direct
interactions with other software agents using XML-based
message exchanges via Internet-based protocols.
 objects and components are often used within an
organization to develop tightly coupled applications
 web services are generally viewed as complete services in
their own right

Distributed systems by Patrick ndungu 9


3.2 Architectural Models Cont…
Communicating paradigms
What is:
a) Interprocess communication?
b) Remote invocation?
c) Indirect communication?
a) Interprocess communication
 low-level support for communication between processes in distributed
systems, including:
i. message-passing primitives,
ii. direct access to the API offered by Internet protocols (socket
programming) and
iii. support for multicast communication
 Remote invocation – calling of a remote operation, procedure or method
 Request-reply protocols – a pattern with message-passing service to
support client-server computing

Distributed systems by Patrick ndungu 10


3.2 Architectural Models Cont…
Communicating paradigms
a) Remote procedure call (RPC)
• procedures in processes on remote computers can be called as
if they are procedures in the local address space
• supports client-server computing with servers offering a set
of operations through a service interface and clients calling
these operations directly as if they were available locally
 What type of transparency do RPC systems offer?
 RPC systems offer (at a minimum) access and location transparency
b) Remote method invocation (RMI)
• strongly resemble RPC but in a world of distributed objects
• tighter integration into object-orientation framework
 In RPC and RMI –
 senders-receivers of messages
– coexist at the same time
– are aware of each other’s identities
Distributed systems by Patrick ndungu 11
3.2 Architectural Models Cont…
Communicating paradigms
c) Indirect communication
• 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 in indirect communication:
i. Group communication
ii. Publish-subscribe systems
 (sometimes also called distributed event-based systems)
 publishers distribute information items of interest (events) to a
similarly large number of consumers (or subscribers)
iii. Message queues:
• (publish-subscribe systems offer a one-to-many style of
communication), message queues offer a point-to-point service
 producer processes can send messages to a specified queue
 consumer processes can
 receive messages from the queue or
 be notified
Distributed systems by Patrick ndungu 12
3.2 Architectural Models Cont…
Communicating paradigms
c) Indirect communication cont….
iv) Tuple spaces (also known as generative communication):
• processes can place arbitrary items of structured data, called
tuples, in a persistent tuple space
 other processes can either read or remove such tuples from
the tuple space by specifying patterns of interest
 readers and writers do not need to exist at the same time
(Since the tuple space is persistent)
v) Distributed shared memory (DSM):
• abstraction for sharing data between processes that do not share
physical memory

Distributed systems by Patrick ndungu 13


3.2 Architectural Models Cont…
Communication entities and communication paradigms

Distributed systems by Patrick ndungu 14


3.2 Architectural Models Cont…
3.2.1 Roles and responsibilities
a) Client-server

Clients invoke individual servers

Distributed systems by Patrick ndungu 15


3.2 Architectural Models Cont…
Roles and responibilities
b) Peer-to-peer :- same set of interfaces to each other

i) Peer-to-peer architecture

Distributed systems by Patrick ndungu 16


3.2 Architectural Models Cont…
Placement
• crucial in terms of determining the DS properties:
 performance
 Reliability
 security
• Possible placement strategies:
 mapping of services to multiple servers
 mapping distributed objects between servers, or
 replicating copies on several hosts
 more closely coupled multiple-servers – cluster

b A service provided by multiple servers

i) Peer-to-peer architecture

17
Distributed systems by Patrick ndungu
3.2 Architectural Models Cont…
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

b A service provided by multiple servers

Web proxy server

i) Peer-to-peer architecture

18
Distributed systems by Patrick ndungu
3.2 Architectural Models Cont…
• mobile agents
- 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 (e.g.
collecting information), and eventually returning with the results.
- could be used for
software maintenance--- Software Updates…etc
collecting information from different vendors’ databases of prices--fishing codes in many sites
– Possible security threats with mobile code and mobile agents...

b A service provided by multiple servers

Web Applets

– yet another possibility – push model: server initiates interaction (e.g. on information updates on it)

i) Peer-to-peer architecture

19
Distributed systems by Patrick ndungu
3.2 Architectural Models Cont…
mobile code Cont…
– Applets are an example of mobile code

b A service provided by multiple servers

Web Applets

– yet another possibility – push model: server initiates interaction (e.g. on information updates on it)

i) Peer-to-peer architecture

20
Distributed systems by Patrick ndungu
3.2 Architectural Models Cont…
3.2.2 Architectural patterns
- Layering…..partition complex system….eg. Back-end, front end

 Layered approach – complex system partitioned into a number of layers:


vertical organization of services
given layer making use of the services offered by the layer below
software abstraction
higher layers unaware of implementation details, or any other layers beneath them

b A service provided by multiple servers

Web Applets

– yet another possibility – push model: server initiates interaction (e.g. on information updates on it)

i) Peer-to-peer architecture

21
Distributed systems by Patrick ndungu
3.2 Architectural Models Cont…
Platform and Middleware
Software and hardware service layers in distributed systems

Fig . Software and hardware service layers in distributed systems


- Middleware – a layer of software whose purpose is to mask heterogeneity and to provide a convenient programming model to application programmers.
- A platform for distributed systems and applications consists of the lowest-level hardware and software layers.

i) Peer-to-peer architecture

22
Distributed systems by Patrick ndungu
3.2 Architectural Models Cont…
Tiered architecture
- Tiering is a technique to organize functionality of a given layer and place this functionality into appropriate servers and, as a
secondary consideration, on to physical nodes

Example: two-tier and three-tier architecture


- functional decomposition of a given application, as follows:
 presentation logic
 application logic
 data logic

Fig . Software and hardware service layers in distributed systems


A platform for distributed systems and applications consists of the lowest-level hardware and software layers.

i) Peer-to-peer architecture

23
Distributed systems by Patrick ndungu
3.2 Architectural Models Cont…
Tiered architecture
Two-tier and three-tier architectures

i) Peer-to-peer architecture

24
Distributed systems by Patrick ndungu
3.2 Architectural Models Cont…
Tiered architecture
a) Two-tier and
 three aspects partitioned into two
processes
 (+) low latency
 (-) splitting application logic

b) three-tier architectures
 (+) one-to-one mapping from logical elements to physical servers
 (-) added complexity, network traffic and latency

i) Peer-to-peer architecture

25
Distributed systems by Patrick ndungu
3.2 Architectural Models Cont…
AJAX (Asynchronous Javascript And XML) – a way to create interactive, partially/selectively-updatable webpages
 extension to the standard client-server style of interaction in WWW
 Javascript forntend and server-based backend

new Ajax . Request ( ’ Grades. php?Year=Sem: one ’ ,


{ onSuccess : updateGrades }) ;
function updateGrades ( request ) {
.....
( request contains thes tate of the Ajax r equest 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 . )
.....
}
AJAX example: grade score updates
(two-tier architecture) two-tier or three-tier a

i) Peer-to-peer architecture

26
Distributed systems by Patrick ndungu
3.2 Architectural Models Cont…
Thin clients
 enabling access to sophisticated networked services (e.g. cloud services) with few assumptions to client device
 software layer that supports a window-based user interface (local) for executing remote application programs or accessing
services on remote computer

Thin clients and computer servers


 Concept led to Virtual Network Computing (VNC) – VNC clients accessing VNC servers using VNC protocol

i) Peer-to-peer architecture

27
Distributed systems by Patrick ndungu
3.2 Architectural Models Cont…
Other commonly occurring patterns
• proxy pattern
designed to support location transparency in RPC or RMI
proxy created in local address space, with same interface as the remote object

• brokerage in web services


supporting interoperability in potentially complex distributed infrastructure
service provider, service requestor and service broker
brokerage reflected e.g. in registry in Java RMI and naming service in CORBA

Thin clients and computer servers


 Concept led to Virtual Network Computing (VNC) – VNC clients accessing VNC servers using VNC protocol

i) Peer-to-peer architecture

28
Distributed systems by Patrick ndungu
3.2 Architectural Models Cont…
The web service architectural pattern

• Reflection pattern
 a means of supporting both:
 introspection (the dynamic discovery of properties of the system) :->dynamically discover interface offered by a given object
 intercession (the ability to dynamically modify structure or behaviour):--discover and adapt the underlying architecture of the system
 used e.g. in Java RMI for generic dispatching
 ability to intercept incoming messages or invocations

Thin clients and computer servers


 Concept led to Virtual Network Computing (VNC) – VNC clients accessing VNC servers using VNC protocol

i) Peer-to-peer architecture

29
Distributed systems by Patrick ndungu
3.2 Architectural Models Cont…

3.2.3 Associated middleware solutions


The task of middleware is to provide a higher-level
programming abstraction:
 what is the task of middleware?
 development of distributed systems and, through layering,
to abstract over heterogeneity in the underlying
infrastructure to promote interoperability and portability

Categories of middleware

30
Distributed systems by Patrick ndungu
3.2 Architectural Models Cont…
Categories of middleware

31
Distributed systems by Patrick ndungu
3.2 Architectural Models Cont…
Limitations of middleware
- Some communication-related functions can be completely and
reliably implemented only with the knowledge and help of the application
standing at the end points of the communication system.

Example:
- e-mail transfer need another layer of fault- tolerance
that even TCP cannot offer

32
Distributed systems by Patrick ndungu
3.3 Fundamental models
3.3 Fundamental models
What is:
 Interaction model?
 Failure model?
 Security model?

2.4.1 Interaction model


 processes interact by passing messages –
communication (information flow) and
coordination (synchronization and ordering of activities) between processes

33
Distributed systems by Patrick ndungu
3.3 Fundamental models
3.3.1 Interaction model cont…
 communication takes place with delays of considerable duration thus;-
 accuracy with which independent processes can be coordinated is limited by these delays
 and by difficulty of maintaining the same notion of time across all the computers in a
distributed system

 Behaviour and state of DS can be described by a distributed algorithm:


 steps to be taken by each interacting process
 transmission of messages between them
State belonging to each process is completely private

34
Distributed systems by Patrick ndungu
3.3 Fundamental models
Performance of communication channels
 latency –
 how to define latency? delay between the start of message’s transmission from one process and the
beginning of receipt by another
 bandwidth – how to define bandwidth? of a computer network – the total amount of information that
can be transmitted over it in a given time
 Jitter -
 What is jitter? – the variation in the time taken to deliver a series of messages
Computer clocks and timing events
 clock drift rate
 what is clock drift rate?
 rate at which a computer clock deviates from a perfect reference clock

35
Distributed systems by Patrick ndungu
3.3 Fundamental models
Two variants of the interaction model
a) Synchronous distributed systems:
 The time to execute each step of a process has known lower and upper bounds
 Each message transmitted over a channel is received within a known bounded time
 Each process has a local clock whose drift rate from real time has
a known bound

b) Asynchronous distributed systems:


 No bounds on:
 Process execution speeds
 Message transmission delays
 Clock drift rates

36
Distributed systems by Patrick ndungu
3.3 Fundamental models
Event ordering
Figure : Real-time ordering of events

a) Asynchronous distributed systems:


 No bounds on:

Logical time – based on event ordering

37
Distributed systems by Patrick ndungu
3.3 Fundamental models
3.3.2 Failure model
 faults occur in:
 any of the computers (including software faults)
 or in the network
 Failure model defines and classifies the faults

Omission failures
 process or communication channel fails to perform actions it is supposed to do
 Process omission failures
 chief omission failure of a process is to crash
 crash is called fail-stop if other processes can detect certainly that the process has crashed

38
Distributed systems by Patrick ndungu
3.3 Fundamental models
3.3.2 Failure model cont…
 Communication omission failures
 communication channel does not transport a message from p’ss outgoing message buffer to q’s incoming message buffer
– known as dropping messages
i. send-omission failures
ii. receive-omission failures
iii. channel-omission failures

Figure Processes and channels

All failures so far: benigh failures

39
Distributed systems by Patrick ndungu
3.3 Fundamental models
3.3.2 Failure model cont…
Arbitrary failures
- arbitrary or Byzantine failure is used to describe the worst possible failure semantics, in which any type of error
may occur

Figure Omission and arbitrary failures

40
Distributed systems by Patrick ndungu
3.3 Fundamental models
3.3.2 Failure model cont…
Timing failures
• applicable in synchronous distributed systems

Figure: Timing failures

Masking failures
 knowledge of the failure can enable a new service to be designed to mask the failure of the components on which it depends

41
Distributed systems by Patrick ndungu
3.3 Fundamental models
Reliability of one-to-one communication
 reliable communication:
i) Validity:
What is validity?
Any message in the outgoing message buffer is eventually delivered to the incoming message buffer

ii) Integrity:
 What is integrity?
The message received is identical to one sent, and no messages are delivered twice

42
Distributed systems by Patrick ndungu
3.3 Fundamental models
3.3.3 Security model
 modular nature of distributed systems and their openness exposes them to attack by
both external and internal agents
 Security model defines and classifies attack forms,
 providing a basis for the analysis of threats
basis for design of systems that are able to resist them

 the security of a distributed system can be achieved by :-


i. securing the processes and the channels used for their interactions and
ii.by protecting the objects that they encapsulate against unauthorized access.

43
Distributed systems by Patrick ndungu
3.3 Fundamental models
Protecting objects
 Users with access rights
 association of each invocation and each result with the authority on which it is issued
 such an authority is called a principal
 principal may be a user or a process

Figure Objects and principals

44
Distributed systems by Patrick ndungu
3.3 Fundamental models
Securing processes and their interactions
 securing communications over open channels
 open service interfaces

The enemy or also: adversary

Figure :The enemy

45
Distributed systems by Patrick ndungu
3.3 Fundamental models
a)Threats to processes
 lack of knowledge of true source of a message
 problem both to server and client side
 example: spoofing a mail server
b)Threats to communication channels
 threat to the privacy and integrity of messages
 can be defeated using
Defeating security threats
a) Cryptography and shared secrets
Cryptography is the science of keeping messages secure
Encryption is the process of scrambling a message in such a way as to hide its contents
b) Authentication
 based on shared secrets authentication of messages – proving the identities supplied by their senders

Figure :The enemy

46
Distributed systems by Patrick ndungu
3.3 Fundamental models
Secure channels

Figure : Secure channels

Properties of a secure channel:


i. Each of the processes knows reliably the identity of the principal on whose behalf the other process is executing
ii. A secure channel ensures the privacy and integrity (protection against tampering) of the data transmitted across it
iii.Each message includes a physical or logical timestamp to prevent messages from being replayed or reordered

47
Distributed systems by Patrick ndungu
3.3 Fundamental models
Other possible threats from an enemy
c) Denial of service:
 the enemy interferes with the activities of authorized users by making excessive and pointless invocations on services or message
transmissions in a network, resulting in overloading of physical resources (network bandwidth, server processing capacity)
d) Mobile code:
 execution of program code from elsewhere, such as the email attachment etc

48
Distributed systems by Patrick ndungu
3.3 Fundamental models
The uses of security models
-> security analysis involves :-> the construction of a threat model:
 listing all the forms of attack to which the system is exposed
 an evaluation of the risks and consequences of each

49
Distributed systems by Patrick ndungu
The END

Q&A

THANKS

Distributed systems by Patrick 50


ndungu

You might also like