Dr.

Muhammad Ali Ismail

1
Architectural Models
 Styles
 Layering
 Object-orientation

 System Architectures
 Client-Server
 Multiple Servers
 Multitier Architectures
 Proxy Servers
 Mobile Code
 Mobile Agents
 Thin Clients
 Mobile Devices
 P2P

2
DS Models
 What will be modeled?
 Computation
 Where and how? Processes and events.
 Interaction
 Processes communicate through messages, which results
in:
 Communication: (information flow)
 Coordination: (synchronization and ordering of activities)
 Failure
 Types of failures that can occur

3
DS Models
 What will be modeled? (continued - - -)
 Time
 Can we make any assumption on time bounds on
communication and computation speeds?
 Security
 Security is linked to failures.
 Malicious behavior is a kind of failure.
 Modeling the possible behavior of attackers, providing a
basis for the analysis of threats

4
Process & Events
 A program in execution is called a process.
 server process
 client process
 peer process
 Every process has an associated state
 The state of a process changes as a result of some action:
 computation
 communication (send, receive)
 The occurrence of an action is called an event.

5
DS Models
 Architectural Models

 Fundamental Models

6
Architectural Models
 Addresses:
 placement of components in the system
 abstracts the functions of the individual components
 defines patterns for distribution of data and workload
 the interaction between components
 defines patterns of communication among the components.

7
Architectural Models
 Example: Client-Server Model
 Definition of:
 server process
 client process
 Protocols for communication among processes

8
Architectural Models
 Two ways to look at organization of distributed
systems

 Software Architecture
 logical organization of software components – how the various
software components are organized and how they should interact

 System Architecture
 their physical realization – the instantiation of software
components on real machines

9
Architecture - Styles
 Basic idea to break up the
complexity of systems by
designing them through layers
and services
 Layer: group of closely related
and highly coherent
functionalities
 Service: functionality provided
to a superior layer
 Examples
 OS (kernel, other services)
 Computer Network Protocol
Architectures

Layered Architecture

10
 Architecture - Styles
 Platform
 The lowest-level hardware and software
layers
Applic ations, services
 e.g.
 Intel x86/Windows
 Sun Sparc/SunOS Middlew are

 POWER PC/MacOS
 Intel x86/Linux
Operating sy stem
 The design and implementation of the
Platform
platform is independent of the design
and implementation of the upper layers Computer and netw ork hardw are

 the ‘glue’ or interface between the

11
System Architectures
 Major System Architectures

 Client-Server
 Variants of client-server model

 P2P

12
Client-Server Model
Clients

Server
Invocation

Results

Invocation
…
Results

13
Client-Server Model - Variants
 Multiple Servers
 Multitier Architectures
 Proxy Servers
 Mobile Code
 Mobile Agents
 Thin Clients
 Mobile Devices and Spontaneous Networking

14
Multiple Servers
 Services may be implemented as Clients
several server processes in separate Service
host computers interacting as invocation
necessary to provide a service to client
processes
 The servers may:
Results
 partition the set of objects on which the
service is based and distribute them between
themselves
 maintain replicated copies of them on several
hosts.
…invocation
 Motivation
 Performance Results
 Reliability

15
Multitier Architectures
 Multiple tiers increase the scalability of the
server

Database

1. UI-tier 2. Application logic - 3. Data storage -tier

16
Multitier Architectures

The simplified organization of an Internet search engine into three different layers.

17
Proxy Servers

Frequently used in search-engines

18
Mobile Code Model
 Code migration/mobility allows DS objects to be moved to
a client (or server) for execution/processing in response to
a client request
 e.g. # 1
 migration of an applet to a local browser –avoiding delays and
communication overhead
 remote invocations are replaced by local ones.

19
Mobile Code Model
Step 1: load applet

Step 2: interact with applet

20
Mobile Code Model
 e.g. # 2
 dynamic/periodic auto-migration of server-resident code/data to a client

 Push Model
 one in which the server initiates the interaction by sending update data to

clients e.g. to:

 perform buy/sell condition-checks on clients side

 automatically notify the server to buy/sell –all done while the user-application is off or onto

other things.

 Client needs application that listens for server pushes

21
Mobile Code Model
 Caution
 security threat due to potential ‘Trojan Horse’ problem
in migrated code.

22
Mobile Agents Model
 A program that can migrate from a starting host to many other hosts in
a network of heterogeneous computer systems and fulfill a task
specified by its owner
 During the self-initiated migration, the agent carries all its code and
data, and in some systems also some kind of execution state
 Both code and associated data are migrated to a number of computers
to carry out specified tasks, and eventually returning results.
 It tends to minimize delays due to communication (vis-à-vis static
clients making multiple requests to servers).

23
Mobile Agents Model
 E.g.
 a software installation-agent installing applications on different
computers for given hardware-configurations
 a price compare-agent checking variations in prices for a
commodity
 a worm agent that looks for idle CPU cycles in cluster-computing.

24
Java Applets vs. Mobile Agents
 MAs initiate the migration process; migration of Java
applets is initiated from other software components (e.g.
Web browser)
 Java applets migrate only from a server to a client, do not
leave the client to another client or back to the server
 Applet’s lifetime bound to that of the Web page, dies when
browser terminates or another Web page requested; MA
usually migrate more than once

25
Existing Mobile Agent Toolkits
 ADK
 Aglets
 Ajanta
 Concordia
 D’Agents
 Grasshoppers
 Mole
 Semoa
 Tacoma
 Tracy
 Voyager

26
Mobile Agents Model
 Caution
 security threat due to potential ‘Trojan Horse’ problem
in migrated code, incomplete execution or ‘hanging’ of
agents.
 The mobile agents may not be able to complete their
tasks if they are refused access to the information they
need.

27
Thin Client Model
 Each client computer supports a layer of software
which invokes a remote compute server for
computational services.
 The compute server will typically be a multiprocessor or
cluster computer.
 If the application is interactive and results are due back
to client-user, delays and communication can eclipse
any advantages.

28
Thin Client Model
Compute server
Network computer or PC

Thin network Application

29
Thin Client – Example
 Windows Terminal Services
 Terminal Services is Microsoft's implementation of thin-client
terminal server computing .
 Only the user interface of an application is presented at the client .
 Any input to the application like mouse or keyboard events, is
redirected over the network to the server, where all application
processing takes place .
 The client uses the Remote Desktop Protocol to communicate with
the terminal server.

30
Mobile Devices
 Mobile devices are hardware, computing components that
move (together with their software) between physical
locations.
 This is opposed to software agents, which are software components
that migrate.
 Both clients and servers can be mobile (clients more frequently).
 E.g.
 small portable devices: laptops, PDA, mobile phones, digital
cameras, wearable computers – smart watches
 non-mobile embedded microcomputers: washing machines, set-top
boxes, home appliances, automobiles, controllers, sensors

31
Mobile Devices

32
Peer-to-Peer Model
 All of the processes involved in a task or activity play similar roles,
without any distinction between servers and clients interacting
cooperatively as peers
 All processes interact and cooperate in servicing requests
 Processes are able to maintain consistency and needed synchronization
of actions; and pattern of communication depends on the application.
 E.g., consider a ‘whiteboard’ application where multiple peer processes
interact to modify a shared picture file – interactions and synch done
via middleware layer for notification/group communication

33
Peer-to-Peer Model

34
Peer-to-Peer Model
 Motivation
 Client-Server offers poor scalability
 the centralization of service provision and management implied by
placing a service at a single address doesn’t scale well beyond the
capacity of the computers that hosts the service and the bandwidth of its
network connections
 The aim of the peer-to-peer architecture is to exploit the resources
(both hardware and data) in a large number of participating
computers for the fulfillment of a given task or activity

35
Peer-to-Peer Model
 Applications are composed of large number of peer processes running
on different computers
 An individual computer holds only a small part of the application
database and the storage, processing and communication loads for
access to objects are distributed across many computers and networks
links
 Each object is replicated in several computers to further distribute the
load and to provide resilience in the event of disconnection of
individual computers
 The need to place individual objects and retrieve them and to maintain
replicas amongst many computers renders this architecture
substantially more complex than the client server architecture.

36