Distributed Programming

Prepared by:
Dr. Peter Maina Mwangi
 What is Distributed Object Systems
• Distributed Object Systems are frameworks that allow objects, which
are instances of classes in programming, to interact with one another over
a network.
• Distributed object-based systems enable objects to interact over a network,
facilitating communication between different components of a distributed
application.
• These systems extend the principles of object-oriented programming (OOP) to
distributed environments, enabling flexibility, scalability, and reusability.
• These systems are designed to function in a distributed environment,
where components can be spread across different servers or geographical
locations.
• The primary goal is to create a unified interface for interacting with
objects, regardless of their physical location.

2
 Key Characteristics of Distributed Object-Based Systems

• Distributed object-based systems extend object-oriented principles across

a distributed network, enabling remote interaction between objects.
• Below are the key characteristics that define these systems:
1. Location Transparency
• Objects communicate as if they are in the same address space, even though they
may be distributed across different machines.
• Users and developers do not need to be concerned with the physical location of
objects.
2. Remote Method Invocation (RMI)
• Objects invoke methods on remote objects as if they were local.
• Middleware handles communication, serialization, and invocation transparency.
• Examples: Java RMI, CORBA, gRPC.

3
 Cont.
3. Encapsulation & Modularity
• Distributed objects encapsulate state and behavior, ensuring modularity.
• Objects interact through well-defined interfaces, promoting reusability.
4. Middleware Support
• Middleware acts as an intermediary to manage communication, security, and
resource allocation.
• Common middleware solutions include CORBA, Java RMI, DCOM, and Web Services.
5. Scalability
• Systems can scale horizontally by distributing objects across multiple nodes.
• Load balancing mechanisms help optimize resource utilization.
6. Interoperability
• Objects implemented in different programming languages can communicate through
middleware.
• Protocols like SOAP, REST, and gRPC enable cross-platform communication.
4
 Cont.
7. Fault Tolerance & Reliability
• Mechanisms such as replication, checkpointing, and failover handling ensure system resilience.
• Distributed objects can recover from failures by restarting or migrating to other nodes.
8. Security & Access Control
• Authentication, authorization, and encryption protect communication between objects.
• Middleware enforces security policies using firewalls, SSL/TLS, or access tokens.
9. Concurrency & Synchronization
• Multiple clients may access the same distributed object simultaneously.
• Synchronization mechanisms (e.g., locks, semaphores, transactions) prevent race conditions.
10. Persistence & Object Lifespan Management
• Objects may be transient (existing only during execution) or persistent (stored in a database).
• Object request brokers (ORBs) manage object creation, deletion, and state persistence.

5
 Architecture of Distributed Object Systems

• The architecture of Distributed Object Systems typically involves several key

layers:
• Client Layer: This is where the user interacts with the system. Clients can be anything from
web browsers to desktop applications that initiate requests to access distributed objects.
• Middleware Layer: Middleware serves as an intermediary that facilitates communication
between clients and distributed objects. It handles object location, message routing, and
data serialization.
• Object Layer: This layer consists of the actual distributed objects that contain the business
logic. These objects are often implemented as remote objects, which are instantiated on
different servers.
• Database Layer: Many distributed object systems rely on a back-end database to store
persistent data. This layer manages data integrity and transactions across distributed nodes.
• Network Layer: The network layer provides the necessary communication infrastructure,
including protocols and services for reliable data transmission.

6
 Components of the Architecture:
1.Client: Requests services from remote objects.
2.Server: Hosts and provides services through distributed objects.
3.Stub/Skeleton: Proxy objects that facilitate communication between
local and remote objects.
4.Middleware: Manages object communication, discovery, and
transactions (e.g., CORBA, Java RMI).
5.Registry/Directory Service: Maintains a list of distributed objects and
their locations.

7
Cont.

8
 Common Architectures:

• Client-Server Model: Clients make requests to remote

objects residing on a server.
• Peer-to-Peer (P2P) Model: Objects interact without a
central server, improving scalability.
• Service-Oriented Architecture (SOA): Objects expose
services as reusable components.

9
 How Distributed Object-Based Systems Work

• A Distributed Object-Based System allows objects to communicate

across different machines in a network as if they were in the same
memory space.
• It enables distributed computing by using Remote Method Invocation
(RMI) and middleware components such as object request brokers
(ORBs).

10
Working of Distributed Object-Based Systems
1. Client Request: The client application calls a
method on a remote object.
2. Stub (Proxy): The stub acts as a local
representative of the remote object. It
serializes the request and forwards it to the
server.
3. Middleware (Object Request Broker - ORB):
The ORB routes the request to the correct
server hosting the object.
4. Skeleton (Server-Side Proxy): The skeleton
receives the request, deserializes it, and
invokes the method on the actual object.
5. Response: The result is sent back through the
skeleton, ORB, stub, and finally to the client.

11
 Communication in Distributed Object Systems
• Communication between distributed objects is fundamental to system
operation. It involves message passing, synchronization, and data transfer
over a network.
Types of Communication:
1.Synchronous Communication:
1. The client waits for the server to process the request and return a response.
2. Example: Remote Method Invocation (RMI), RPC.
2.Asynchronous Communication:
1. The client sends a request but does not wait for a response.
2. Example: Message queues, event-driven architectures.
3.Message-Oriented Communication:
1. Objects communicate through messaging systems such as JMS (Java Message Service) or
AMQP.
4.Middleware-Based Communication:
1. Middleware handles communication between distributed objects.
2. Example: CORBA (Common Object Request Broker Architecture), DCOM (Distributed
Component Object Model).

12
Distributed Objects
• A Distributed Object is an object that
exists in a distributed system and can
interact with other objects over a
network as if they were local.
• A distributed object is a software module
that works with other modules across a
network or within a computer.
• They are used in distributed computing
systems, where components are spread
across multiple servers or locations.
• These objects are used in distributed
object-based systems to enable
communication between software
components across different machines.

13
 How Distributed Objects Work
1. Client Makes a Method Call:
1. The client invokes a method on a remote object, just as it would with a local object.
2. Stub (Client Proxy) Handles the Request:
1. A stub (proxy object) on the client side intercepts the method call.
2. It serializes (marshals) the method name, parameters, and metadata.
3. Middleware (Object Request Broker - ORB) Forwards the Request:
1. The ORB transmits the request over the network to the remote server where the actual object resides.
2. ORB protocols such as Java RMI, CORBA, DCOM, or gRPC are used.
4. Skeleton (Server Proxy) Receives the Request:
1. A skeleton (proxy object) on the server side deserializes (unmarshals) the request.
2. It locates the actual remote object and invokes the method.
5. Method Execution & Response Generation:
1. The remote object executes the method and returns the result to the skeleton.
6. Response Sent Back to the Client:
1. The skeleton serializes the response and sends it back to the client.
2. The ORB forwards the response over the network.
3. The stub receives and deserializes the response, presenting it to the client as if it were a local call.

14
 Types of Distributed Objects

• Distributed objects can be categorized based on their characteristics,

communication mechanisms, and lifecycle management.
• Below are the main types of distributed objects:

15
 1. Persistent vs. Transient Distributed Objects
(a) Persistent Objects
• These objects retain their state even after the application terminates.
• They are stored in databases, files, or distributed storage systems.
• Example: A customer profile object stored in a database that retains user
preferences.
(b) Transient Objects
• These objects exist only during program execution and are lost when the
application stops.
• Used for temporary computations and in-memory processing.
• Example: A session object in an e-commerce application that tracks a user’s
cart until checkout.

16
 2. Synchronous vs. Asynchronous Distributed Objects

(a) Synchronous Distributed Objects

• The client waits for a response after invoking a method.
• Remote Method Invocation (RMI) and RPC (Remote Procedure Call) follow
this model.
• Example: A banking transaction system, where a user waits for a
confirmation.
(b) Asynchronous Distributed Objects
• The client does not wait for a response; the method call executes in the
background.
• Messaging systems like JMS (Java Message Service) and AMQP (Advanced
Message Queuing Protocol) use this approach.
• Example: An email notification system that queues emails for later delivery.

17
 3. Active vs. Passive Distributed Objects
(a) Active Objects
• Objects have their own thread of execution and can run independently.
• They can autonomously perform tasks and notify clients of updates.
• Example: IoT devices that constantly send sensor data.
(b) Passive Objects
• These objects do not execute independently and require external invocation
to perform actions.
• Example: A remote database object that only responds when queried.

18
 4. Replicated vs. Non-Replicated Objects
(a) Replicated Objects
• Copies of the object exist on multiple servers for fault tolerance
and load balancing.
• Changes made to one copy are synchronized across all replicas.
• Example: Cloud-based distributed databases (e.g., Amazon
DynamoDB, Google Spanner).
(b) Non-Replicated Objects
• Exist only in one location, meaning a single point of failure.
• Example: A local server hosting a user authentication service.

19
 5. Mobile vs. Stationary Objects

(a) Mobile Objects

• Can move between different machines in a distributed system to improve
performance.
• Example: Mobile agents in network management, which move across servers
to gather data.
(b) Stationary Objects
• Remain in one location and are accessed remotely by clients.
• Example: A cloud-hosted machine learning model that processes remote API
requests.

20
 Evolution of Distributed Objects

• The concept of distributed objects has evolved over the years as

computing systems transitioned from centralized architectures to
distributed and cloud-based environments.
• Below is a timeline of the key phases in the evolution of distributed
object systems.

21
 1. Early Distributed Computing (1970s - 1980s)

• Key Features:
• Systems were based on Remote Procedure Calls (RPC) and message-passing
models.
• Primitive distributed systems used Sockets and IPC (Inter-Process
Communication).
• Focus was on client-server computing, where clients requested services from
centralized servers.
• Example Technologies:
• Berkeley Sockets API (1983) – Used for network communication.
• SunRPC (1988) – One of the first implementations of RPC.
22
 2. Introduction of Object-Oriented Distributed Systems (1980s
- 1990s)
• Key Features:
• The rise of object-oriented programming (OOP) led to distributed objects.
• Middleware solutions like CORBA and DCOM emerged.
• Objects could be accessed remotely via interfaces, promoting reusability.
• Example Technologies:
• CORBA (Common Object Request Broker Architecture) – 1991
• Developed by the Object Management Group (OMG) for platform-independent object
communication.
• DCOM (Distributed Component Object Model) – 1996
• Microsoft’s solution for Windows-based distributed object communication.
• Java RMI (Remote Method Invocation) – 1997
• Java’s distributed object mechanism for executing remote methods.

23
 3. Web-Based Distributed Systems (Late 1990s -
Early 2000s)
• Key Features:
• Transition from heavyweight middleware (CORBA, DCOM) to lightweight
web services.
• Rise of Service-Oriented Architecture (SOA) and XML-based communication.
• Platform independence became a major focus.
• Example Technologies:
• SOAP (Simple Object Access Protocol) – 1999
• Enabled distributed objects over HTTP with XML-based messaging.
• Enterprise JavaBeans (EJB) – 1998
• Java-based distributed component model for enterprise applications.
• Microsoft .NET Remoting – 2002
• Successor to DCOM, facilitating distributed object communication in .NET.

24
 4. The Rise of Microservices & Cloud Computing
(2010s - Present)

• Key Features:
• Shift from monolithic distributed objects to microservices.
• Use of RESTful APIs, JSON, and gRPC instead of heavyweight RPC
mechanisms.
• Cloud-based platforms support globally distributed applications.
• Example Technologies:
• RESTful Web Services (Representational State Transfer) – 2000s
• Simple, stateless, and lightweight alternative to SOAP.
• gRPC (Google Remote Procedure Call) – 2015
• High-performance RPC framework using Protocol Buffers.
• Serverless Computing (AWS Lambda, Google Cloud Functions) – 2010s
• Cloud functions that act like distributed objects but scale dynamically.

25
 5. Future Trends in Distributed Objects

• Key Features:
• AI-driven distributed systems with intelligent agents.
• Blockchain-based distributed objects for secure transactions.
• Edge Computing where distributed objects exist on IoT devices and interact in
real-time.
• Example Technologies:
• WebAssembly (WASM) – Future of cross-platform object execution.
• Blockchain-based smart contracts – Enabling decentralized distributed
objects.
• Edge AI – Enabling distributed AI models to interact in real time.

26
 Distributed Object Technologies

• Distributed Object Technologies allow objects in a distributed system

to communicate as if they were local.
• These technologies provide remote method invocation (RMI), object
request brokers (ORBs), and messaging mechanisms to facilitate
communication between distributed objects.

27
 1. Java RMI (Remote Method Invocation)
• Overview:
• Java RMI is a Java-based distributed object system that allows Java objects to
communicate remotely.
• Key Features:
• Uses Java Virtual Machine (JVM) for execution.
• Supports remote method calls between Java objects.
• Uses stubs and skeletons for communication.
• Architecture:
• Stub (Client Proxy): Sends method invocation requests.
• RMI Registry: A directory that stores remote object references.
• Skeleton (Server Proxy): Receives and executes requests.
• Use Case:
• Enterprise Java applications where remote Java objects need to communicate.

28
 2. CORBA (Common Object Request Broker
Architecture)
• Overview:
• CORBA is a platform-independent middleware standard for distributed object
communication.
• Key Features:
• Uses an Object Request Broker (ORB) for managing object communication.
• Supports multiple programming languages (Java, C++, Python, etc.).
• Uses IDL (Interface Definition Language) for defining object interfaces.
• Architecture:
• ORB (Object Request Broker): Manages communication between objects.
• IDL Compiler: Converts IDL into stubs and skeletons.
• Use Case:
• Large-scale distributed systems, such as banking and telecom.

29
 3. DCOM (Distributed Component Object Model)

• Overview:
• DCOM is Microsoft’s distributed object technology, an extension of COM
(Component Object Model).
• Key Features:
• Uses Windows RPC for remote communication.
• Supports object activation and security mechanisms.
• Integrates with Microsoft .NET technologies.
• Architecture:
• DCOM Runtime: Manages distributed object calls.
• Security Layer: Controls access to objects.
• Use Case:
• Windows-based enterprise applications, such as Microsoft Office and Windows
services.

30
 4. .NET Remoting

• Overview:
• NET Remoting is Microsoft’s replacement for DCOM, used for communication
between .NET applications.
• Key Features:
• Supports different transport protocols (HTTP, TCP, IPC).
• Uses serialization (SOAP, Binary) for object communication.
• Allows cross-machine and cross-app communication.
• Use Case:
• Enterprise Windows applications that require object-oriented
communication.

31
 5. SOAP (Simple Object Access Protocol)
• Overview:
• SOAP is a protocol for exchanging structured information using XML over
HTTP.
• Key Features:
• Uses XML-based messaging.
• Platform and language-independent.
• Supports WS-Security for authentication and encryption.
• Use Case:
• Web services and enterprise application integration.

32
 6. REST (Representational State Transfer)

• Overview:
• REST is an architectural style that uses HTTP methods to enable
communication between distributed systems.
• Key Features:
• Uses HTTP methods (GET, POST, PUT, DELETE).
• Stateless and lightweight compared to SOAP.
• Uses JSON or XML for data exchange.
• Use Case:
• Web and mobile applications, microservices architecture.

33
 7. gRPC (Google Remote Procedure Call)
• Overview:
• gRPC is a high-performance RPC framework developed by Google, using
Protocol Buffers (protobufs).
• Key Features:
• Uses HTTP/2 for fast communication.
• Supports multiple programming languages.
• Provides bidirectional streaming.
• Use Case:
• Microservices, cloud-based systems, and real-time applications.

34
 Comparison of Distributed Object Technologies

Technology Language Support Transport Protocol Use Case

Java-based distributed
Java RMI Java TCP RMI
applications
Large-scale enterprise
CORBA Multi-language TCP/IP IIOP
systems
Windows distributed
DCOM Windows-based Windows RPC DCOM
apps
Windows enterprise
.NET Remoting .NET HTTP/TCP .NET Remoting
apps
Web services,
SOAP Multi-language HTTP XML
enterprise integration
Web APIs, cloud
REST Multi-language HTTP JSON/XML
applications
Microservices, cloud
gRPC Multi-language HTTP/2 Protobuf
computing
35
 Advantages of Distributed Object-Based Systems
1. Location Transparency
• Clients interact with remote objects as if they were local, simplifying development.
Example: A Java RMI client can call a method on a remote server object without knowing its physical location.
2. Reusability and Modularity
• Objects can be reused across different applications, improving maintainability.
Example: CORBA allows objects to be written in different languages and reused in multiple systems.
3. Platform and Language Independence
• Some systems like CORBA and gRPC support multi-language communication.
Example: A Python client can communicate with a C++ server using CORBA or gRPC.
4. Scalability
• Distributed objects allow applications to scale horizontally by running across multiple servers.
Example: gRPC enables microservices to communicate efficiently in cloud applications like Kubernetes.
5. Better Resource Utilization
• Computing tasks can be distributed among multiple machines, improving performance.
Example: DCOM allows Windows applications to offload processing to a more powerful server.
6. Fault Tolerance
• Distributed objects can run on multiple machines, reducing the risk of failure.
Example: Cloud-based distributed systems use redundant objects to ensure high availability.

36
 Challenges of Distributed Object-Based Systems
1. Increased Complexity
• Managing distributed objects requires additional infrastructure and error handling.
Example: Setting up Java RMI requires an RMI registry, stub, and skeleton, adding complexity.
2. Network Latency and Performance Issues
• Remote calls are slower than local method calls due to network overhead.
Example: A Java RMI call over the internet may experience delays compared to local execution.
3. Security Risks
• Exposing objects over a network introduces security vulnerabilities.
Example: DCOM objects on a network must be secured against unauthorized access to prevent cyberattacks.
4. Difficulty in Debugging and Testing
• Debugging distributed systems is harder due to network-related failures.
Example: A CORBA object may fail due to an issue in the Object Request Broker (ORB), making troubleshooting difficult.
5. Compatibility and Versioning Issues
• Different versions of distributed objects may not be compatible with each other.
Example: A gRPC client using an old version of Protocol Buffers may not work with a newer server implementation.
6. Setup and Maintenance Overhead
• Deploying and maintaining distributed object-based systems requires additional tools and infrastructure.
Example: Managing a CORBA-based system requires an IDL compiler, ORB, and network configuration.

37
 Distributed File Systems (DFS)

• A Distributed File System (DFS) is a system that enables users to

access, store, and manage files across multiple networked computers
as if they were stored on a single machine.
• It ensures scalability, fault tolerance, and remote access by
distributing data across multiple nodes.

38
 Key Characteristics of Distributed File
Systems
1.Transparency:
1. Users perceive the system as a single logical file system, regardless of underlying
network complexities.
2.Fault Tolerance:
1. Files are replicated across multiple nodes to prevent data loss.
3.Scalability:
1. Supports a growing number of users and storage requirements.
4.Concurrency Control:
1. Multiple users can access and modify files simultaneously.
5.Security:
1. Implements authentication, encryption, and access control mechanism

39
 Types of Distributed File Systems

Type Description Examples

A central server manages files,
Client-Server DFS and clients request access over NFS (Network File System)
the network.

Each node acts as both a client

Peer-to-Peer DFS IPFS (InterPlanetary File System)
and a server, sharing files directly.

Files are stored and managed in a

Cloud-Based DFS Google Drive, Amazon S3
cloud environment.
Files are distributed across a
Cluster-Based DFS cluster of machines for high Hadoop HDFS, Ceph
performance and fault tolerance.

40
 Advantages of Distributed File Systems

• High Availability: Files remain accessible even if some

servers fail.
• Improved Performance: Load is balanced across multiple
storage nodes.
• Scalability: Can handle increasing amounts of data and
users.
• Data Redundancy: File replication prevents data loss.
• Multi-User Collaboration: Enables concurrent file access.
41
 Challenges of Distributed File Systems

• Network Latency: Remote file access may be slower than local

access.
• Data Consistency Issues: Ensuring file updates are reflected across all
replicas.
• Security Risks: Requires strong authentication and encryption.
• Complexity: Requires additional management tools for configuration
and monitoring.

42
 Use Cases of Distributed File Systems

• Cloud Storage: Google Drive, Dropbox, OneDrive.

• Big Data Processing: Hadoop HDFS for large-scale data analytics.
• Enterprise File Sharing: Microsoft DFS in corporate environments.
• High-Performance Computing (HPC): Ceph for scalable storage
solutions.
• Media Streaming: Netflix and YouTube use DFS to store and distribute
video content.

43