Remote Method Invocation (RMI)

Definition:

Remote Method Invocation (RMI) is a Java API that allows objects to communicate and invoke
methods on objects located in a different Java Virtual Machine (JVM). RMI provides a
framework for building distributed systems in Java, making it easier for different parts of an
application running on different machines to interact as if they were all part of a single system.

RMI is designed to abstract the complexities of network communication and allow Java objects
to interact with each other as if they were local, providing an easy-to-use and powerful tool for
distributed computing in Java applications.

Key Features of RMI:

1. Remote Communication:
o RMI enables Java applications to invoke methods remotely over a network. The
communication happens between a client (which calls the method) and a server
(which implements the method).
o The client and server can be on different machines or in different JVMs.
2. Object Serialization:
o Objects in Java are serialized (converted into a byte stream) to be transmitted over
a network.
o RMI automatically serializes the arguments passed to remote methods, ensuring
that objects are safely transferred between different JVMs.
3. Stub and Skeleton:
o RMI uses stubs and skeletons to facilitate communication between the client and
server. These components are automatically generated from the interface
definition, enabling seamless interaction between remote objects.
4. Location Transparency:
o With RMI, the client does not need to know the physical location of the remote
object. The system automatically handles the communication, abstracting the
network details from the client.
5. Automatic Garbage Collection:
o RMI supports automatic garbage collection of remote objects. Once the object is
no longer in use, RMI can remove the object from the memory, ensuring efficient
resource management.
6. Distributed Objects:
o RMI allows the use of distributed objects, meaning objects can exist across
different machines in a network, making it easier to build scalable distributed
applications.

2. RMI Architecture Components (In-Depth)

1. Client:

 The client is a Java application that invokes methods on remote objects. It acts as the
consumer of the service provided by the remote object.
 The client does not interact directly with the remote object but instead communicates
with the stub, which is a proxy representing the remote object.

Key Characteristics:

 The client calls the remote methods using the stub object, which behaves as if the method
was local.
 The client is unaware of the physical location of the server or the remote object, enabling
location transparency.

Example:

java

Calculator calc = (Calculator)

Naming.lookup("rmi://localhost/CalculatorService");
System.out.println("Addition Result: " + calc.add(5, 10));

2. Server:

 The server is a Java application that provides remote services. It implements the methods
defined in the remote interface, which clients can invoke.
 The server must make the remote object available to clients through the RMI Registry.

Key Characteristics:

 The server contains the actual logic for the remote methods (e.g., the implementation of
business logic).
 The server registers its remote objects with the RMI Registry, making them discoverable
by clients.

Example:

java

public class CalculatorImpl extends UnicastRemoteObject implements Calculator

{
public int add(int a, int b) {
return a + b;
}
}

3. Stub:
  The stub is a client-side proxy that acts as the intermediary between the client and the
server.
 When the client makes a method call on the stub, it forwards the call to the actual remote
object on the server through the network.
 The stub provides a local interface to the remote object, making remote method
invocations look like local calls to the client.

Key Characteristics:

 The stub is automatically generated when the remote object interface is compiled, and it
handles the complexities of network communication.
 The stub is responsible for marshaling (serializing) the method arguments and sending
them over the network.

Example of Stub Generation:

bash

rmic CalculatorImpl

4. Skeleton:

 The skeleton is a server-side proxy that receives remote method calls from the client’s
stub and forwards them to the actual remote object for execution.
 In earlier versions of RMI, the skeleton was needed to dispatch method calls. However,
in newer versions of Java, the skeleton has been deprecated, and its functionality is
embedded within the server’s RMI infrastructure.

Key Characteristics:

 The skeleton's role is to unmarshal (deserialize) the parameters sent by the client, invoke
the method on the real object, and then return the result.
 The skeleton is no longer needed in modern implementations since the server
automatically handles the method dispatch and unmarshalling.

Example (Deprecated):

java

CalculatorImpl obj = new CalculatorImpl();

Calculator skeleton = (Calculator) UnicastRemoteObject.exportObject(obj, 0);

5. RMI Registry:
  The RMI Registry is a centralized service that allows clients to look up remote objects
by name. It acts as a directory that registers remote objects and provides a means for
clients to discover them.
 When the server starts, it registers its remote objects in the registry with a unique name.
The client can then search for these objects by their name.

Key Characteristics:

 The RMI Registry typically runs on port 1099 by default.

 Clients can use the Naming.lookup() method to find remote objects registered in the
RMI registry.
 The registry can be used both for local and remote object lookups.

Example of RMI Registry:

java

Naming.rebind("rmi://localhost/CalculatorService", new CalculatorImpl());

3. RMI Communication Flow (Detailed)

Step-by-Step Communication Process:

1. Client Request:
o The client makes a method call on a stub, as if invoking a local method.
o The stub marshals the method arguments into a byte stream.
2. Network Communication:
o The marshaled request is sent over the network to the RMI Registry.
o The registry locates the remote object on the server and forwards the request to
the server-side skeleton (if using legacy RMI architecture).
3. Server-side Processing:
o The skeleton (or the server's RMI infrastructure in newer versions) receives the
marshaled data, unmarshals the arguments, and forwards the request to the actual
remote object.
o The remote object processes the request, executes the method, and sends the result
back to the skeleton.
4. Response Handling:
o The skeleton marshals the result, sends it back through the network to the client’s
stub.
o The stub unmarshals the response and returns the result to the client as if the
method was executed locally.

Diagram: RMI Communication Workflow

Client Stub Network Skeleton
Server
| Method | | Method
|
|--------------->| (Marshal) Network |---------------> |
| <------------- | <--------------- (Unmarshal) | <-------------
|
| | |
|

4. Advantages of RMI:
 Simplified Distributed Communication: Abstracts the complexity of network
programming, providing an easy way for Java applications to interact.
 Language Integration: Fully integrated with the Java language, making it seamless for
Java developers to build distributed applications.
 Built-in Security: Supports Java’s security manager and allows encrypted
communications with SSL/TLS.
 Automatic Garbage Collection: RMI provides automatic garbage collection for remote
objects, freeing developers from manual memory management tasks.

5. Limitations of RMI:
 Java Dependency: RMI is Java-specific and does not work across different languages or
platforms. This can limit its use in heterogeneous systems.
 Complexity in Large-Scale Systems: RMI may not scale well in very large distributed
systems, particularly if there are numerous distributed objects or complicated data
structures.
 Performance Overhead: Due to the serialization and deserialization of objects, RMI can
introduce performance overhead, especially for large objects.

Steps to Create an RMI Application (Detailed)

Remote Method Invocation (RMI) allows Java applications to invoke methods on remote objects
located in different JVMs (Java Virtual Machines). The process of creating an RMI application
involves several key steps. Below is a more detailed breakdown of the steps, including code
samples, explanations, and an in-depth understanding of the architecture.

Step 1: Define the Remote Interface

The first step in creating an RMI application is to define a remote interface. This interface
specifies the methods that are available for remote invocation. The methods in the remote
interface must throw RemoteException to handle any network-related issues that might occur
during the communication.

Code Example:

java

import java.rmi.*;

public interface Calculator extends Remote {

// Method signature to add two numbers remotely
public int add(int a, int b) throws RemoteException;
}

Explanation:

 Remote is a marker interface in RMI that indicates the interface is used for remote
communication.
 Each method in the remote interface must declare throws RemoteException because
network issues or other communication errors can occur during method invocation.

Step 2: Implement the Remote Interface

Next, you need to implement the remote interface. This implementation will define the actual
business logic behind the remote methods. You will need to extend UnicastRemoteObject,
which provides the functionality to export the object for remote access.

Code Example:

java

import java.rmi.*;
import java.rmi.server.*;

public class CalculatorImpl extends UnicastRemoteObject implements Calculator

{
 // Constructor that throws RemoteException
public CalculatorImpl() throws RemoteException {}

// Implementation of the add method

public int add(int a, int b) {
return a + b;
}
}

Explanation:

 The CalculatorImpl class extends UnicastRemoteObject, which allows the object to

be exported and made accessible to remote clients.
 The constructor calls super() to properly initialize the UnicastRemoteObject with the
necessary RMI infrastructure.
 The add method implements the logic of adding two integers and returns the result.

Step 3: Create the Server

The server is responsible for registering the remote object with the RMI Registry so that clients
can discover and access it. You need to create the server class, which registers the remote object
and makes it available for remote invocation.

Code Example:

java

import java.rmi.*;
import java.rmi.registry.*;

public class CalculatorServer {

public static void main(String[] args) {
try {
// Create a new instance of the remote object
Calculator calc = new CalculatorImpl();

// Create the RMI registry on port 1099 (default)

LocateRegistry.createRegistry(1099);

// Register the remote object with the RMI registry

Naming.rebind("CalculatorService", calc);

// Print message indicating that the service is running

System.out.println("Calculator Service is running...");

} catch (Exception e) {
e.printStackTrace();
}
}
}

Explanation:

 LocateRegistry.createRegistry(1099) creates and binds the RMI registry to the

specified port (1099 by default). This is where remote objects will be registered.
 Naming.rebind("CalculatorService", calc) registers the CalculatorImpl object
with the name "CalculatorService" in the registry. Clients will use this name to look
up the service.
 The server continually runs, allowing clients to access the remote methods.

Step 4: Create the Client

The client accesses the remote service by looking up the remote object in the RMI Registry.
Once the object is found, the client can invoke the remote methods just like local method calls.

Code Example:

java

import java.rmi.*;

public class CalculatorClient {

public static void main(String[] args) {
try {
// Look up the remote object in the RMI registry
Calculator calc = (Calculator)
Naming.lookup("rmi://localhost/CalculatorService");

// Call the remote method and print the result

System.out.println("Addition Result: " + calc.add(5, 10));
} catch (Exception e) {
e.printStackTrace();
}
}
}

Explanation:

 Naming.lookup("rmi://localhost/CalculatorService") looks up the remote object

"CalculatorService" in the RMI registry. The client uses this name to find the remote
service.
 Once the remote object is obtained, the client invokes the add method on it, passing the
arguments as if the object were local. RMI handles the network communication
automatically.
 The result from the remote method is printed to the console.
Advantages of RMI (Detailed)

1. Simplifies Distributed Computing in Java:

o RMI abstracts the complexities of remote communication, allowing Java
applications to interact with each other as if they were running locally.
o It provides a high-level API for remote method invocation, which is easier to
implement compared to lower-level communication protocols like sockets.
2. Built-in Security Mechanisms:
o RMI includes built-in security features such as Java Security Manager, which
controls access to resources and verifies that remote invocations are properly
authorized.
o It can be configured to use SSL/TLS for encrypted communication, ensuring
secure data transmission between the client and server.
3. Automatic Garbage Collection of Remote Objects:
o RMI automatically manages the lifecycle of remote objects. Once an object is no
longer in use, it is automatically removed from memory, preventing memory
leaks.
o The RMI runtime handles object references and cleans up resources when the
objects are no longer reachable.

Limitations of RMI (Detailed)

1. Works Only with Java-based Systems:

o RMI is a Java-specific technology and does not work natively with other
programming languages or systems.
o This makes it unsuitable for applications where components are implemented in
different languages (e.g., Java and Python or Java and C++).
2. Dependent on the Java RMI Registry:
o RMI relies on a centralized RMI registry for clients to discover and look up
remote objects. The registry must be running on a specific port (typically 1099),
which could lead to potential conflicts in distributed systems or network issues.
o The need for a registry adds an additional layer of complexity in setting up RMI
applications.
3. Performance Overhead:
o RMI introduces performance overhead because it involves object serialization,
method marshaling/unmarshaling, and network communication, which can slow
down the execution of remote method calls compared to local method
invocations.
o For large-scale systems or highly performance-sensitive applications, RMI might
not be the best choice.
RMI Communication Workflow (Detailed)

Below is a more detailed explanation of the RMI communication process:

1. Client Side:
o The client calls a method on the stub object, which acts as a proxy for the remote
object.
o The stub marshals the method parameters into a byte stream, which is then
transmitted over the network.
2. Network Communication:
o The marshaled data is sent across the network to the RMI registry on the server-
side.
o The registry looks up the location of the actual remote object.
3. Server Side:
o The skeleton (in older versions) or the server infrastructure receives the
marshaled data, unmarshals the arguments, and calls the actual method on the
remote object.
o The method executes, and the result is marshaled back into a byte stream and sent
over the network.
4. Client Receives Response:
o The client’s stub receives the marshaled response, unmarshals the result, and
returns it to the client.

Diagram: RMI Communication Workflow

+-----------+ +-----------+ +------------+ +--------

---+
| Client | | Stub | | Network | |
Skeleton |
+-----------+ +-----------+ +------------+ +--------
---+
| | | |
Method Call | | |
-------> | | |
| | | |
| Marshals Arguments Sends Request |
| | | |
| v v v
| RMI Registry <---------> Server Logic <-------->
Remote Object
| ^ | |
| Returns Response | |
| | | |
v | | |
Receives Result Unmarshals Response Method Executes
Result Sent Back
2. Java Database Connectivity (JDBC)
Definition: Java Database Connectivity (JDBC) is an API (Application Programming Interface)
in Java that enables Java applications to interact with relational databases by executing SQL
queries. It serves as a bridge between Java applications and database systems, making it easier to
retrieve, update, and manage data stored in a relational database.

Key Components of JDBC

JDBC consists of several key components that allow you to interact with databases. These
components work together to perform operations such as connecting to a database, executing
SQL queries, and processing query results.

1. DriverManager:
o Role: DriverManager manages a list of database drivers. It is responsible for
establishing a database connection by selecting an appropriate driver.
o Details: When a connection request is made, DriverManager selects the first
available driver that can handle the requested database URL.

java

DriverManager.getConnection("jdbc:mysql://localhost:3306/testdb",
"username", "password");

2. Connection:
o Role: The Connection object represents a session between the Java application
and the database.
o Details: It provides methods to create Statement and PreparedStatement
objects and to manage transactions. It is responsible for establishing, managing,
and closing the database connection.

java

Connection conn = DriverManager.getConnection(

"jdbc:mysql://localhost:3306/testdb", "username", "password");

3. Statement:
o Role: The Statement object is used to execute SQL queries.
o Details: It can be used to execute static SQL queries (like SELECT, INSERT,
UPDATE, and DELETE) that are compiled once and can be executed multiple times.
There are also PreparedStatement and CallableStatement subclasses for
executing parameterized SQL queries and stored procedures.

java
 Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("SELECT * FROM students");

4. ResultSet:
o Role: The ResultSet object stores the data retrieved from the database after
executing a SELECT query.
o Details: It provides methods to retrieve data from the result set, such as
getString(), getInt(), etc. It can be navigated to retrieve each row of data.

java

while (rs.next()) {
System.out.println("Name: " + rs.getString("name"));
}

Steps to Use JDBC (Detailed)

1. Step 1: Import JDBC Packages

o The first step in using JDBC is to import the necessary classes and interfaces from
the java.sql package.

java

import java.sql.*;

2. Step 2: Register the Driver

o Driver registration: JDBC requires a database-specific driver to communicate
with the database. Before establishing a connection, you need to load the driver
class.

java

Class.forName("com.mysql.cj.jdbc.Driver");

o Explanation: The Class.forName() method dynamically loads the driver class

into memory. For MySQL databases, this is the appropriate driver class. Other
databases (e.g., Oracle, PostgreSQL) would have different driver classes.
3. Step 3: Establish Connection
o Connection Setup: Use DriverManager to establish a connection to the database
by providing the URL, username, and password.

java

Connection conn = DriverManager.getConnection(

"jdbc:mysql://localhost:3306/testdb", "username", "password");

o Explanation: The URL specifies the database type (jdbc:mysql), the host
(localhost), the port (3306), and the database name (testdb).
 o Once connected, you can use the Connection object to manage interactions with
the database.
4. Step 4: Create Statement
o Statement Object: After establishing the connection, create a Statement object
to execute SQL queries.

java

Statement stmt = conn.createStatement();

o Explanation: The Statement object is used to execute SQL queries. For static
queries, the Statement object is appropriate, but for queries with user input, you
should use a PreparedStatement to prevent SQL injection.
5. Step 5: Execute Queries
o Execute SQL Commands: You can execute different types of SQL commands
using the Statement or PreparedStatement objects:
 executeQuery(): Used for SELECT queries.
 executeUpdate(): Used for INSERT, UPDATE, and DELETE queries.
 execute(): Used for any SQL command, such as calling stored
procedures.

java

ResultSet rs = stmt.executeQuery("SELECT * FROM students");

o Explanation: The ResultSet object stores the result of the SELECT query. You
can iterate through it using the next() method and retrieve the data using
methods like getString(), getInt(), etc.
6. Step 6: Close Connection
o Closing Resources: It is important to close the database connection and other
JDBC resources (Statement, ResultSet) to free up resources after use.

java

conn.close();
stmt.close();
rs.close();

o Explanation: Closing the connection helps to avoid resource leaks, which could
cause performance issues over time.

JDBC Types

There are four types of JDBC drivers, each with its advantages and use cases:

1. Type 1: JDBC-ODBC Bridge Driver

 o Description: This driver uses ODBC (Open Database Connectivity) to connect to
the database. It converts JDBC calls into ODBC calls and relies on ODBC drivers
to communicate with the database.
o Limitations: It is slower and provides limited platform support.
o Use Case: Legacy systems that already use ODBC.
2. Type 2: Native-API Driver
o Description: This driver converts JDBC calls into database-specific native calls
using a database's API. It requires a local database library.
o Limitations: Requires installation of database-specific libraries and is not as
portable as Type 4.
o Use Case: When direct communication with the database's native API is required.
3. Type 3: Network Protocol Driver
o Description: This driver translates JDBC calls into a network protocol and
communicates with a middleware server that then forwards the requests to the
database. The client uses a common protocol like HTTP or TCP.
o Advantages: Suitable for enterprise systems with multiple database types.
o Limitations: Performance overhead due to the middle layer.
o Use Case: In distributed systems with many databases.
4. Type 4: Thin Driver
o Description: The Type 4 driver communicates directly with the database using
the database's native protocol. It is implemented entirely in Java, making it
platform-independent.
o Advantages: High performance, easy to deploy (pure Java).
o Use Case: The most commonly used JDBC driver in modern applications.

JDBC Workflow Diagram

+-------------------------+
| Java Application |
+-------------------------+
|
| (JDBC API)
|
+-------------------------+
| JDBC Driver |
+-------------------------+
|
| (Network Protocol)
|
+-------------------------+
| Database |
+-------------------------+

Advantages of JDBC (Detailed)

 1. Platform-Independent:
o JDBC is a Java-based API, meaning it can run on any platform that supports Java.
It provides database connectivity in a platform-independent way, making it ideal
for cross-platform applications.
2. Supports Multiple Databases:
o JDBC provides support for multiple database types, such as MySQL, Oracle,
PostgreSQL, Microsoft SQL Server, and more, using different JDBC drivers. This
allows applications to easily switch between databases without changing much of
the code.
3. Allows Static and Dynamic Queries:
o JDBC allows both static SQL queries (hard-coded SQL) and dynamic queries
(where the SQL is constructed at runtime). This makes it flexible and powerful for
various types of database interactions.

Limitations of JDBC (Detailed)

1. Requires SQL Knowledge:

o JDBC developers need a solid understanding of SQL to write the queries needed
for database interaction. This can increase the complexity of development,
especially for developers who are not familiar with SQL.
2. Slower Than Direct Database Connectivity:
o JDBC involves an additional layer of abstraction (the JDBC driver), which
introduces some performance overhead compared to using direct database
connectivity methods (e.g., using native APIs).
3. Manual Resource Management:
o JDBC requires the developer to manually manage resources like database
connections, statements, and result sets. Failure to close these resources properly
can lead to resource leaks and performance degradation.

3. Common Object Request Broker Architecture (CORBA)

Definition: CORBA (Common Object Request Broker Architecture) is a standard developed by
the Object Management Group (OMG) to enable communication between distributed objects
across different platforms and programming languages. It allows software components running
on different computers, potentially with different operating systems, to communicate seamlessly
over a network.

CORBA provides a middleware solution that abstracts the complexities of distributed

communication, enabling objects to interact with one another as if they were local, even if they
are distributed across different machines or networks. It provides mechanisms for calling
methods on remote objects (Object Requests), as well as managing their lifecycle.

Key Components of CORBA

1. ORB (Object Request Broker):

o Definition: The ORB acts as the intermediary between the client and server
objects. It facilitates communication by receiving requests from the client,
forwarding them to the appropriate server, and returning results back to the client.
o Responsibilities: The ORB provides services such as:
 Routing method invocations from clients to server objects.
 Handling object location and activation.
 Converting between the client’s and server’s communication protocols and
formats.
o Communication: It abstracts the underlying transport layer and network
communication details, making it easier for the developer to focus on object
interactions rather than low-level networking.

text

Client --> ORB --> Server

2. IDL (Interface Definition Language):

o Definition: IDL is a language-neutral specification language used to define the
interfaces of CORBA objects. It defines the data types, method signatures, and
interfaces of objects in a way that is independent of any programming language or
platform.
o Purpose: IDL allows objects written in different languages (e.g., Java, C++,
Python) to interact. It acts as a contract between the client and server by defining
the interface, making it possible to implement these interfaces in any supported
language.

Example IDL for a Calculator Interface:

idl

interface Calculator {
 int add(in int a, in int b);
int subtract(in int a, in int b);
};

In this IDL snippet, an interface Calculator is defined with two methods: add and
subtract.

3. Stub and Skeleton:

o Stub (Client-side proxy):
 Definition: The stub acts as a proxy for the remote object at the client-
side. When the client invokes a method on the stub, the stub sends the
request to the ORB, which then forwards it to the server object.
 Purpose: The stub hides the details of remote communication and acts
like the local object for the client, so the client can interact with remote
objects as if they were local.

Example: A client calls stub.add(5, 3), which gets translated into a request to
the ORB to invoke the actual add method on the server object.

o Skeleton (Server-side proxy):

 Definition: The skeleton is the server-side counterpart to the stub. It
receives requests from the ORB, unmarshals the data (converts data from a
transmitted form back to its original structure), and forwards the request to
the actual implementation of the object.
 Purpose: The skeleton handles the incoming requests and ensures they are
routed to the correct method implementation on the server.

Interaction Between Stub and Skeleton: The client communicates with the stub, while
the server communicates with the skeleton, which in turn invokes the actual methods on
the server object.

CORBA Workflow (Detailed)

1. Step 1: Define IDL (Interface Definition Language)

o Purpose: The first step is to define the interfaces that the objects will expose to
clients. The IDL file defines the methods, arguments, and return types of the
object, in a language-neutral way.
o Example: Consider a Calculator interface with an add method. The client will
use this interface to request calculations, and the server will implement this
interface to perform the actual operations.

idl
 interface Calculator {
int add(in int a, in int b);
};

2. Step 2: Generate Code

o Purpose: Once the IDL file is written, an IDL compiler is used to generate code.
The compiler generates client-side stubs and server-side skeletons from the IDL
definition. The generated code provides the necessary mechanisms for remote
communication.
o Client-side Stubs: These are generated in the client’s programming language
(e.g., C++, Java). They allow the client to invoke remote methods without
knowing the details of the server-side implementation.
o Server-side Skeletons: These are generated in the server’s programming
language (e.g., C++, Java). They handle incoming method calls and forward them
to the appropriate server-side object.
3. Step 3: Implement Server Logic
o Purpose: After generating the skeletons, you implement the actual server-side
logic. This involves creating an object that implements the methods defined in the
IDL interface.
o Example: In the CalculatorImpl class, you would implement the add method to
return the sum of two numbers.

cpp

class CalculatorImpl : public POA_Calculator {

public:
int add(int a, int b) {
return a + b;
}
};

o Explanation: The CalculatorImpl class implements the Calculator interface,

and it provides the actual logic for the add method.

4. Step 4: Start the ORB (Object Request Broker)

o Purpose: The ORB must be started to enable communication between clients and
server objects. You register the server object with the ORB, which allows it to
receive incoming method requests from clients.
o Example: The server object needs to be activated with the ORB and registered for
incoming remote method invocations.

cpp

CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);

CalculatorImpl calculatorImpl;
// Register the object with ORB
 5. Step 5: Client Interaction
o Purpose: The client interacts with the stub generated from the IDL. The stub
hides the complexity of network communication and allows the client to call
methods on the remote object as if it were local.
o Example: The client calls the add method on the stub, and the stub forwards the
request to the ORB, which routes it to the server-side skeleton, which then
invokes the method on the actual implementation.

CORBA::Object_var obj = orb-

>string_to_object("corbaloc::localhost/Calculator");
Calculator_var calculator = Calculator::_narrow(obj);
int result = calculator->add(5, 3); // Client invoking remote method

CORBA Architecture Diagram

+-------------------+ +-------------------+
Client -->| Stub |--->ORB-->| Skeleton |---> Server
+-------------------+ +-------------------+
|
(Remote Method Call)
|
(Server-side Object)

Advantages of CORBA

1. Language and Platform Independence:

o CORBA enables communication between objects written in different
programming languages (such as C++, Java, Python, etc.) and running on
different platforms (Windows, Linux, etc.).
o CORBA achieves this by using IDL, which allows the interface to be defined in a
platform-neutral way, and the ORB abstracts away platform-specific details.
2. Robust Fault Tolerance:
o CORBA provides built-in support for fault tolerance, allowing for the transparent
recovery of remote objects in case of failures. CORBA’s exception handling
mechanisms allow applications to handle network or object failures gracefully.
3. Scalability:
o CORBA is designed for large-scale distributed systems, making it a good fit for
enterprise applications that require communication between thousands of objects
across different systems.
4. Transparent Communication:
 o CORBA abstracts the details of network communication, allowing clients and
servers to interact without needing to know each other's location, network
topology, or communication protocols.

Limitations of CORBA

1. Steeper Learning Curve:

o CORBA involves understanding several components, including ORB, IDL, stubs,
skeletons, and other middleware services. For developers unfamiliar with
distributed systems, CORBA can be difficult to learn.
2. Performance Overhead:
o The abstraction provided by CORBA, particularly in the form of the ORB,
introduces performance overhead. Communication is often slower compared to
lower-level methods like direct socket communication.
3. Complexity in Configuration:
o Configuring a CORBA system with multiple objects, servers, and clients can be
complex. Setting up proper object references and ensuring that the correct version
of the ORB is used can be error-prone.
4. Interoperability Issues:
o Although CORBA is platform-independent, interoperability between different
ORB implementations is not always seamless. Some vendors might implement
additional features that could lead to compatibility issues.

Comparative Summary:

Feature RMI JDBC CORBA

Purpose Remote object Database Distributed object
communication connectivity communication
Language Java-specific SQL + Java Language-neutral
Protocol Java RMI Protocol Database-specific IIOP (Internet Inter-ORB
Protocol)
Use Case Distributed Java apps Database access Cross-language systems