ARCHITECTURE

MODELS
PHYSICAL MODELS
• A physical model represents the hardware components that make up a
distributed system, abstracting away the specific implementation details of
the computing and networking technologies.

• Baseline Physical Model:

• A distributed system can be viewed as a set of interconnected computer nodes.

• Each node can be extended or added — making the system extensible.

• Communication and coordination between nodes occur solely through message

passing
1. Early Distributed Systems

• Emerged with the development of Local Area Networks (LANs) —

particularly Ethernet.

• Typically composed of 10 to 100 nodes connected via a LAN.

• Had limited Internet connectivity.

• Services Provided:
➢ Shared local printers
➢ File servers for storage
➢ Basic Internet services such as email and file transfer (FTP)
2. Internet-Scale Distributed Systems

• Emerged in the 1990s, driven by the rapid growth of the Internet.

• Based on an extensible network of nodes connected via the Internet

• Systems became truly global, spanning countries and organizations.

• Rise of open standards to ensure interoperability.

• Enhanced mechanisms for end-to-end QoS, ensuring reliability and

performance in global operations.
3. Contemporary Distributed Systems
Earlier Systems
Nodes were mainly desktop computers that were:
• Static – fixed in one location.
• Discrete – standalone, not embedded in other objects.
• Autonomous – operated independently from other systems.
Key Developments
1. Mobile Computing
Nodes (e.g., laptops, smartphones) became mobile, moving between locations.
New Requirements:
Service discovery, Spontaneous interoperation
2. Ubiquitous Computing
Transition from discrete computers to embedded systems within everyday
objects.
Example: Smart devices in homes, appliances, or wearable tech
3. Cloud & Cluster Computing
Shift from autonomous nodes to pools of coordinated nodes.
Example: Cluster-based services such as Google Search.
Resulting Physical Architecture
Highly Heterogeneous, Massive Scale, Diverse Networking Technologies
4. Distributed Systems of Systems
• Ultra-Large-Scale (ULS) Distributed Systems represent the next stage in
distributed system evolution.

• They are “systems of systems” — large, interconnected collections of

subsystems, each functioning as a complete system on its own.

• These subsystems collaborate to accomplish broader, integrated objectives.

• Often heterogeneous, involving different technologies and architectures.

• Dynamic and evolving, with continuous updates and scaling.

Generations of Distributed Systems
ARCHITECTURAL MODELS
1. ARCHITECTURAL ELEMENTS
 1.1 Communicating Entities
a) Objects
• Objects are introduced to promote object-oriented approaches in
distributed systems.

• These approaches support both object-oriented design and object-

oriented programming languages.

• A distributed computation is composed of multiple interacting

objects.
• Each object represents a natural unit of decomposition for the problem

domain.

• Objects communicate and cooperate to perform tasks across distributed

nodes.

• Objects are accessed through interfaces. Each interface defines a set of

methods (operations) available for invocation. The Interface Definition

Language (IDL) specifies these methods formally.

b) Components

• Distributed objects had limitations such as hidden dependencies and

incomplete contracts between interacting parts.
• Component technology emerged to overcome these weaknesses.
• Components are similar to objects — provide abstractions and accessed
via interfaces.
• However, Components explicitly define dependencies on other
components.
• Objects specify only their provided interfaces.
• Components specify both:
• Provided interfaces (services they offer).
• Required interfaces (services they depend on).
• This forms a complete contract for integration.
Advantages:
• Promotes clearer system design and easier composition.
• Encourages third-party component development.
• Reduces hidden dependencies → improves reusability and maintainability.
• Supports server-side programming and automated deployment through
middleware.
c) Web Services
• Web services form the third major paradigm for developing distributed
systems.
• Similar to objects and components:
➢ Encapsulation of behaviour.
➢ Access through interfaces.
• Difference: Web services are natively integrated with the World Wide
Web, using web standards for representation, communication, and
discovery.
Characteristics:
• Use standard web technologies (XML, HTTP, WSDL, UDDI,
SOAP/REST).
• Platform and language independent.
• Discoverable and interoperable across networks.

Aspect Objects & Components Web Services

Scope Used within organizations Cross-organizational (B2B)
Coupling Tightly coupled Loosely coupled
Technology Often proprietary Web-based standards
Reuse Internal Global, across systems
 1.2 Communication Paradigms
a) Interprocess Communication
• It refers to the low-level mechanisms that enable processes to exchange data and
coordinate actions in a distributed system.

• Allows processes running on different machines (or the same machine) to

communicate, synchronize, and share information.

• Key Mechanisms
• Message Passing Primitives (Basic send and receive operations)
• Socket Programming (Connection-oriented, Connectionless)
• Multicast Communication
b) Remote Invocation
• It is the most common communication paradigm in distributed
systems.
• It involves a two-way exchange between entities (client and server) to
invoke an operation, procedure, or method located on a remote
system.
• Remote Procedure Call (RPC):
Enables calling a remote function in another process/machine using
procedural interfaces.
• Remote Method Invocation (RMI):

Object-oriented form of RPC used in languages like Java, allowing

method calls on remote objects.
• Web Services Invocation:
Uses XML/HTTP (SOAP or REST) to call operations on remote services
over the web.

JAXR - Java API for XML Registries

c) Indirect Communication
➢ Group Communication

• Concerned with delivering messages to a set of recipients (one-to-many

communication).

• Communication is based on a group identifier rather than individual

recipients.

• Recipients join a group to receive messages. Senders send messages to the

group ID
➢ Publish-Subscribe Systems

• An information-dissemination system connecting publishers and

subscribers via an intermediary.

• Publishers produce events/messages.

• Subscribers register interests.

• The system routes events to interested subscribers.

➢ Message Queues

• A point-to-point communication service using queues as

intermediaries.

• Provides asynchronous communication between producers and

consumers.

• Producers send messages to a queue.

• Consumers receive or are notified of new messages.

➢ Tuple Spaces
• A shared associative memory model where processes exchange
data items called tuples.

• Writers place tuples in the space.

• Readers retrieve or remove tuples by pattern matching.

➢ Distributed Shared Memory (DSM)
• Provides an illusion of shared memory across physically separate
systems.
• Processes read/write shared data as if local, despite distribution.
• System ensures timely propagation of data.
• Manages consistency and synchronization issues.
Communicating Entities and Communication Paradigms
 Roles and Responsibilities
1. Client-Server
• The client–server model is the most common and historically important
architecture for distributed systems.
• It involves clients and servers communicating over a network to access shared
resources.
• Client processes: Request services or resources.
• Server processes: Provide and manage those services or resources.
• Clients and servers typically run on separate host computers.
• A server may also act as a client to another server.
Clients invoke individual Servers
2. Peer-to-Peer

• All processes (nodes) play similar roles and interact cooperatively as equals
(peers).
• There is no fixed distinction between clients and servers.
• Each node runs the same program and offers the same interfaces to other peers.
Advantages:
• Scalable: Each new peer adds capacity.
• Fault-tolerant: No single point of failure.
• Efficient resource sharing: Utilizes distributed storage and bandwidth.
• Self-organizing: Peers can join or leave dynamically.
Examples
1. Napster (Early Example):
• Pioneered file sharing of digital music files.
• Not a pure P2P (had a centralized index server).
• Proved feasibility of large-scale resource sharing.
2. BitTorrent (Modern Example):
• Fully distributed file-sharing system.
• Splits files into chunks shared among many peers.
• Demonstrates true scalability and efficiency of P2P systems.
Peer-to-Peer Architecture
 Placement
1. Mapping of Services to Multiple Servers
• A service can be implemented using several server processes on separate host
computers.
• These servers interact and cooperate to provide a unified service to client processes.
• This improves performance, scalability, and availability compared to using a single
server.

a) Partitioned Data
• Each server is responsible for a subset of the total data or objects. The overall dataset is
divided (partitioned) across multiple servers.
 A service provided by multiple servers

b) Replicated Data
• Each server maintains a copy
(replica) of the same data.
• All replicas are kept consistent
through synchronization
mechanisms.
2. Caching
• A cache is a temporary store of recently used data objects that is closer to the client
(or a group of clients) than the original data source (server).
• It helps reduce access time, server load, and network traffic.
• When a client requests an object:
➢ The system first checks the cache.
➢ If a valid (up-to-date) copy exists → it is returned immediately (cache hit).
➢ If not → a fresh copy is fetched from the server (cache miss) and stored in the
cache.
• When new objects are added:
➢ Older or less frequently used objects may be replaced
Cache Placement:
• Client-Side Cache:
Each client maintains its own local cache.
Example: Web browsers store recently visited pages locally.
• Proxy (Server-Side) Cache:
Shared by multiple clients through a proxy server.
Reduces redundant requests to the same external web servers.
Common in corporate networks and ISPs.
Web Proxy Server
3. Mobile Code
• It refers to program code that can move across a network and execute on a remote
host rather than just the computer where it originated.
• It enables dynamic functionality and enhanced interactivity without continuous
client–server communication.
• Applets are a classic and widely used form of mobile code.
• The user selects a link in a web browser → the applet code (stored on a web server)
is downloaded and runs locally in the browser.
• Advantages:
➢ Better interactivity and performance, Reduced server load
Security Concerns
• Mobile code poses potential security threats to local system resources.
• Browsers restrict applet access to local files and system resources using a
sandbox security model.
• This ensures that downloaded code cannot harm or misuse the client’s
system.
Web Applets
4. Mobile Agents
• A mobile agent is a running program (including both its code and data) that can
move autonomously from one computer to another over a network.
• It performs tasks on behalf of a user or process, often collecting or processing
information, and may return with the results.
How It Works:
• The agent migrates from its origin computer to other networked computers.
• At each site, it executes locally, using local resources (e.g., databases, files).
• It may visit multiple hosts, perform operations, and finally return to the origin
with the processed data.
Advantages:
• Reduced communication cost and time
• Efficient data processing
• Autonomous operation
Limitations:
• Security and trust issues (both for hosts and agents).
• Limited applicability
• Complex to implement safely.
2. ARCHITECTURAL PATTERNS
Platform for Distributed Systems

• It consists of the lowest-level hardware and software layers, including:

➢ Hardware architecture (e.g., Intel x86, ARM)
➢ Operating systems (Windows, Linux, Solaris, Mac OS, Symbian)
• It provides basic services to higher software layers
• Runs independently on each computer
• It offers programming interfaces that support:
➢ communication between processes
➢ coordination across distributed machines
Software and Hardware Service Layers in Distributed Systems
Middleware

• It is a software layer above the platform whose main purpose is to:

➢ mask heterogeneity in distributed systems
➢ provide a convenient programming model for application
developers
• It provides communication support between distributed processes
• Resource sharing across multiple computers
• Building blocks for distributed software components
 Two-Tier Architecture
• In a two-tier architecture, the system is divided into: Client, Server
• The three main aspects of an application (presentation, application logic, and data
management) must be partitioned between these two processes.
• The application logic is split between client and server
➢ Some logic runs on the client side, remaining logic runs on the server side
Advantages
• Low latency - Only one message exchange is needed to invoke an operation
➢ Faster interaction between client and server
• Efficient for small-scale applications
Disadvantages
• Application logic is divided across process boundaries
• Harder to manage and maintain
• Restrictions on which parts of the logic can be directly invoked
• A client cannot directly call logic that resides on the server without
communication
• Tighter coupling between client and server
 Three-Tier Architecture
• In a three-tier architecture, the system is divided into:
➢ Presentation tier (Client/User Interface)
➢ Application logic tier (Application Server)
➢ Data tier (Database Server)
• One-to-one mapping between logical elements and physical servers
➢ Each tier runs on a separate server
• Application logic is centralized
Advantages
• Enhanced maintainability
• Clear separation of roles - Each tier has a well-defined function
• Supports thin clients - Client handles minimal processing
Disadvantages
• Increased complexity
• More network communication
➢ Higher network traffic, Increased latency
 Thin Clients and Compute Servers

Compute server
Network computer or PC

Thin Network Application

Client Process
• Thin Client: A software layer enabling access to remote services with
minimal demands on the client device.
• Advantages:
Allows resource-constrained devices to access sophisticated networked
services.
• Drawbacks:
Performance issues in highly interactive graphical applications due to
latency.
The Web Service Architectural Pattern
• Brokerage Pattern:
An architectural pattern supporting interoperability in complex
distributed infrastructures.
• Components:
Service provider, service requester, and service broker.
• Examples:
Registry in Java RMI and naming service in CORBA.
FUNDAMENTAL MODELS
Real-Time Ordering of Events
Event Ordering : Determining the relative order of events (e.g., message

sending/receiving) across different processes.

Logical Clocks: Used to order events in distributed systems despite the lack

of synchronized physical clocks.

Message Delivery Order: Independent delays in message delivery can lead

to messages being received out of order.

Logical Time Concept:
A model of time proposed by Lamport to order events in a distributed
system without relying on synchronized clocks.
Application to Email Ordering:
Logical time can be used to determine the order of emails by assigning
a logical timestamp to each email based on the order in which they are
processed.
Processes and Channels
 Security Model

• Object Protection Mechanism: A server manages objects and enforces

access rights to control who can perform operations on them.

• Principal and Authority: Each invocation and result is associated with a

principal (user or process) to determine access rights.

• Server’s Role: The server verifies the principal’s identity and access rights

for each invocation and ensures the result comes from the correct server.
Objects and Principals
The Enemy

Copy of m

The enemy
m’
Process p m Process q

Communication channel
 Secure Channels

Principal B
Principal A

Process p Secure channel Process q