Distributed Application Architecture

Distributed Application Architecture refers to a computing model in which

different components of an application are located on multiple networked
computers that communicate and coordinate their actions to achieve a
common goal. Instead of running a complete application on a single system,
the workload is divided among several machines such as clients, application
servers, and database servers.

This architecture improves scalability, performance, reliability, and

resource sharing, making it widely used in cloud computing, enterprise
systems, banking applications, and web-based services.

In a distributed environment:

 The client sends requests for services.

 The server processes the request and returns the result.
 Communication occurs through network protocols.

Basic Distributed Architecture Diagram

+-----------+ Network +-----------+

| Client | <-----------------> | Server |
| Application| | Application|
+-----------+ +-----------+

Components of Distributed Application Architecture

1. Client

 User interface of the system.

 Sends service requests to servers.
 Examples: Web browsers, mobile applications.

2. Application Server

 Processes client requests.

 Executes business logic and application functions.
 Communicates with database servers when needed.

3. Database Server

 Stores and manages application data.

  Provides data retrieval and storage services.

Multi-Tier Distributed Architecture Diagram

Client Tier Application Tier Data Tier

------------- ------------------- ------------
| Client UI | ---> | Application Server | ---> | Database |
------------- ------------------- ------------

Types of Distributed Architectures

1. Two-Tier Architecture

 Client communicates directly with the database server.

 Used in small systems.

Client -----------------> Database Server

. Three-Tier Architecture

 Client communicates with an application server, which interacts with the

database.
 More secure and scalable.

Client ---> Application Server ---> Database Server

3. N-Tier Architecture

 Multiple intermediate layers such as web servers, service layers, and

microservices.
 Used in cloud and enterprise applications.

Characteristics of Distributed Applications

 Resource Sharing: Multiple systems share data, services, and hardware.

 Scalability: New servers can be added easily to handle more users.
 Reliability: Failure of one node does not stop the entire system.
 Transparency: Users feel as if they are working with a single system
even though multiple systems are involved.
 Concurrency: Many users can access the system simultaneously.

Advantages
  Improved performance due to load distribution
 High availability and fault tolerance
 Better scalability
 Efficient resource utilization
 Supports remote access and collaboration

Applications of Distributed Architecture

 Cloud computing platforms

 Banking and financial systems
 E-commerce websites
 Online reservation systems
 Social media platforms
 Distributed databases

Creating Stubs and Skeletons (Java RMI)

In Distributed Application Architecture, especially in Java Remote Method
Invocation (RMI), stubs and skeletons play a key role in enabling
communication between a client and a remote object located on another
machine. They hide the complexity of network communication and make
remote method calls appear like local calls.

1. Stub
A stub is a client-side proxy object that represents the remote object.

Role of Stub

 Receives method calls from the client

 Converts method parameters into a format suitable for network
transmission
 Sends the request to the remote server
 Receives the result and returns it to the client

From the client’s perspective, the stub behaves exactly like a local object.

2. Skeleton
A skeleton is a server-side helper object.

Role of Skeleton

 Receives the request from the stub

  Unpacks (unmarshals) the parameters
 Invokes the actual method on the remote object
 Packs (marshals) the result and sends it back to the stub

Note: In modern Java versions (Java 1.2 and later), skeletons are generated
automatically and are not explicitly visible to the programmer.

Working of Stubs and Skeletons

Step-by-Step Process

1. Client calls a method on the stub.

2. Stub sends the request over the network.
3. Skeleton receives the request on the server side.
4. Skeleton invokes the method on the remote object.
5. Result is sent back to the stub.
6. Stub returns the result to the client.

Stub and Skeleton Communication Diagram

Client JVM Server JVM
----------- -----------
Client Program ---> Stub ======> Skeleton ---> Remote Object
<===== Result returned over network <=====

Creation of Stubs and Skeletons

Steps Involved

1. Define a remote interface extending [Link].

2. Implement the remote interface.
3. Compile the Java files.
4. Use the RMI compiler (rmic) to generate stub and skeleton classes.
5. Start the RMI registry.
6. Bind the remote object to the registry.
7. Client looks up the remote object and invokes methods.

Advantages of Using Stubs and Skeletons

 Hides network communication details
 Makes remote method calls simple and transparent
 Supports location-independent communication
 Improves modularity of distributed applications
Defining Remote Objects (Java RMI)
In Java Remote Method Invocation (RMI), a remote object is an object
whose methods can be invoked from another JVM located on a different
machine. Defining remote objects involves creating a remote interface,
implementing the interface, and registering the object so that clients can
access it.

Steps in Defining Remote Objects

1. Create a Remote Interface

 The remote interface defines the methods that can be invoked remotely.
 It must extend [Link].
 Each method must declare throws RemoteException.

Conceptual Structure:

Remote Interface
- method1()
- method2()

2. Implement the Remote Interface

 A class implements the remote interface.

 The class usually extends UnicastRemoteObject.
 Provides implementation for all remote methods.

Conceptual Structure:

Remote Interface ---> Remote Object Implementation

3. Register the Remote Object

 The remote object is registered with the RMI Registry.

 Clients use the registry to locate the remote object using a name.

Registration Flow Diagram

Remote Object ---> RMI Registry <--- Client Lookup

Working of Remote Objects

 1. The server creates the remote object.
2. The object is registered in the RMI registry.
3. The client searches for the object using the registry.
4. The client invokes methods on the remote object as if it were local.

Remote Object Communication Diagram

Client JVM Server JVM
----------- -----------
Client Program ----> Stub ======> Remote Object Implementation

Advantages of Remote Objects

 Enables distributed computing
 Allows remote method invocation across networks
 Provides location transparency
 Simplifies client–server communication

Remote Object Activation

Remote Object Activation is an advanced concept in Java Remote Method
Invocation (RMI) that enables remote objects to be created, started, and
managed automatically on demand, instead of being permanently active on
the server. In traditional RMI, remote objects are created and remain running
even when no client is using them, which can waste system resources. Remote
Object Activation solves this problem by allowing objects to exist in a passive
state and become active only when a client requests their services.

How Remote Object Activation Works

In this model, the server does not directly create and export the remote object.
Instead, information about the remote object—such as its class name, location,
and initialization data—is registered with the RMI Activation System. When a
client invokes a method on the remote object, the call is first intercepted by the
activation system. If the object is not currently active, the activation system
starts a new JVM (if required), creates the object instance, and restores its
state. The requested method is then executed, and the result is returned to the
client transparently.

Lifecycle of an Activated Remote Object

An activated remote object goes through several stages:

 1. Registration: The remote object’s activation descriptor is registered with
the activation system.
2. Inactive State: The object is not running in memory.
3. Activation: On a client request, the object is instantiated and exported.
4. Active State: The object services client requests.
5. Deactivation: After a period of inactivity, the object may be garbage
collected or deactivated.

Benefits of Remote Object Activation

 Efficient resource utilization: Objects consume memory only when

needed.
 Scalability: Suitable for systems with many remote objects.
 Fault tolerance: Objects can be reactivated automatically after crashes.
 Transparency: Clients are unaware of whether the object was already
running or just activated.

Activation Architecture Diagram

Client
|
v
Stub
|
v
RMI Activation System
|
v
Activated Remote Object (Server JVM)
|
v
Service Result to Client

Remote Object Activation is a powerful mechanism that enhances the efficiency

and scalability of distributed applications. By activating remote objects only
when required and deactivating them when idle, it ensures optimal use of
system resources while maintaining seamless client–server interaction in Java
RMI–based distributed systems.

Object Serialization (Java RMI)

Object Serialization is the process of converting an object into a byte stream
so that it can be transmitted over a network, stored in a file, or saved in
memory, and later reconstructed (deserialized) back into the original object. In
distributed applications and Java RMI, serialization allows objects to be
passed as parameters or returned as results of remote method calls.
Concept

When a client invokes a remote method and sends an object as an argument,

that object cannot be transmitted directly across the network. Therefore, the
Java runtime converts the object’s state (its variables and data) into a byte
stream using serialization. On the receiving side, the byte stream is converted
back into the original object through deserialization.

Working Process

1. The object to be transmitted must implement the Serializable interface.

2. The Java serialization mechanism converts the object into a byte stream.
3. The byte stream is sent through the network.
4. The receiver reconstructs the object using deserialization.
5. The remote method then processes the received object.

Serialization Diagram
Sender Side Receiver Side
----------- --------------
Object ----Serialization----> Byte Stream
|
v
Deserialization
|
v
Object

Advantages

 Enables object transmission in distributed systems.

 Allows persistent storage of objects.
 Simplifies communication between client and server in RMI.
 Supports complex data structures like arrays, collections, and custom
objects.

Example Concept (Java)

import [Link];

class Student implements Serializable {

int id;
String name;
}

Any object of the Student class can now be serialized and transmitted across the
network.
Object Serialization is a fundamental mechanism in distributed computing that
enables objects to be converted into a transportable form and reconstructed at
the destination. It plays a crucial role in Java RMI communication, allowing
seamless exchange of objects between remote systems.

JavaSpaces
JavaSpaces is a distributed shared-memory technology (part of Jini
technology) that enables multiple distributed applications to communicate
and coordinate by sharing objects in a common space. Instead of directly
communicating with each other, processes read and write objects (called
entries) into a shared repository known as a space.

It follows the tuple space model, where applications interact by placing,

retrieving, or taking objects from the shared space.

Key Idea

 Programs do not communicate directly.

 They exchange information by writing objects into a shared
JavaSpace.
 Other programs can read or take those objects whenever needed.
 This supports loosely coupled distributed systems.

Basic Operations

1. Write – Stores an object (entry) into the space.

2. Read – Reads a copy of the object without removing it.
3. Take – Removes the object from the space after reading.
4. Notify – Notifies applications when a matching object is added.

Working Diagram
Client A JavaSpace Client B
------------ ---------------- -------------
Write Object -------> | |
| Shared Space | -----> Read Object
Take Object <------- | | <----- Write Object
----------------

Characteristics
  Supports distributed coordination between applications.
 Provides asynchronous communication.
 Ensures reliability because objects remain in the space until taken.
 Enables scalable distributed system design.

Example Applications

 Distributed task processing systems

 Workflow management systems
 Distributed job scheduling
 Enterprise distributed applications

JavaSpaces provides a simple and powerful mechanism for building distributed

applications where multiple processes communicate indirectly through a
shared object space, improving scalability, flexibility, and fault tolerance.