CORBA Introduction

CORBA , which stands for Common Object Request Broker Architecture, was created by the Object
Management Group (OMG) in 1991. It was designed to make it easier for different software programs to
communicate with each other, even if they were written in different programming languages or running on
different platforms. This was a big deal because, before CORBA, it was challenging for programs to work
together across different systems. CORBA achieved this by using Interface Definition Language (IDL) to define
how programs should interact and Object Request Brokers (ORBs) to manage the communication between
them.

While CORBA was revolutionary in enabling interoperability in heterogeneous computing environments, it has
since been mostly replaced by newer, simpler technologies. Modern approaches to distributed computing, such
as web services, provide easier ways for programs to communicate over a network. Nevertheless, CORBA
played a crucial role in advancing the field of distributed computing by providing a standardized framework that
abstracted away the complexities of different languages and platforms.

CORBA Features

Language and Platform Independence: Allows components written in different programming languages and
running on various operating systems to communicate seamlessly.

Object-Oriented Model: Uses an object-oriented approach to define and interact with software components,
making it easier to manage complex systems.

Interoperability: Ensures different systems can work together by providing standardized interfaces and
communication protocols.

Scalability: Designed to support large-scale distributed systems, enabling components to be distributed across
multiple networked computers.

Transparency: Hides the complexities of network communication, making it simpler for developers to build
distributed applications without worrying about the underlying details.

Robustness and Fault Tolerance: Provides mechanisms for error handling and redundancy, ensuring system
reliability and continuous operation.

Security: Includes features like authentication, encryption, and access control to ensure secure communication
and data protection.

Extensibility: Allows for future enhancements and adaptations through a modular architecture and support for
standard extensions.
CORBA Architecture and Components

Object Request Broker (ORB)

The ORB is like the middleman in CORBA's system. It connects clients (programs asking for services) with
servers (programs providing services). Clients don't need to know where the server is or how it works; they just
ask the ORB, which takes care of finding the server, sending the request, and bringing back the result.

Interface Definition Language (IDL)

CORBA uses IDL to define how clients and servers talk to each other. IDL makes sure that programs written in
different languages (like Java, C++, or Python) can understand each other. So, a client in one language can call a
server written in another language without any trouble.

Stubs and Skeletons

 Stub (Client-Side): This is a small program created from the IDL that acts like a stand-in for the server
on the client's side. The client thinks it's talking directly to the server, but it's actually talking to the
stub.
 Skeleton (Server-Side): This is another small program created from the IDL that acts as a bridge on
the server's side. It receives the client's request from the ORB and passes it to the right method on the
server.

General Inter-ORB Protocol (GIOP) and Internet Inter-ORB Protocol (IIOP)

ORBs from different vendors can talk to each other using GIOP. When this communication happens over the
internet, it's called IIOP. These protocols make sure that ORBs from different companies can work together
smoothly.

Portable Object Adapter (POA)

The POA manages the server-side objects and their lifecycles. It makes sure the right server object is available
to handle client requests and manages things like object creation and destruction.
How CORBA Works

1. Client Request:
o A client makes a request to call a method on a remote object. This request is made through the
stub, which translates the call into a format the ORB can understand.
o
2. ORB Processing:
o The client’s ORB locates the appropriate server ORB and sends the request.
o
3. Skeleton Handling:
o The server’s ORB forwards the request to the skeleton, which invokes the correct method on
the server object.
o
4. Response Back to Client:
o The result is sent back from the server through the skeleton and ORB, then returned to the
client via the stub.

CORBA Applications

Telecommunications:

Usage: CORBA is used in call and data transfer management. It enables different systems in the network to
communicate and coordinate, such as call setup and monitoring.

Financial Services:

Usage: In banking and finance, CORBA is used to process safe transactions. It provides real-time trading
systems that ensure fast, efficient exchange of financial data and transactions.

Healthcare:

Usage: CORBA is used to integrate different healthcare systems. For instance, it allows the sharing and access
of patient records across different departments in a hospital, ensuring that doctors and nurses are updated.

Manufacturing:

Usage: In manufacturing, CORBA supervises automated production lines. It coordinates machines and systems
to ensure they work together efficiently, improving productivity and reducing errors.

Advantages of CORBA

Easy Communication: CORBA enables seamless communication between different programs written in various
languages, simplifying system integration.

Language and Platform Independence: Flexibility: It accommodates multiple programming languages and
operating systems, allowing developers to choose their preferred tools.
 Scalability: Handles Growth: CORBA is capable of managing large systems distributed across various
locations, ensuring efficient operation as the system grows.

Transparency: Simplified Development: Developers can focus on their applications without worrying about the
complexities of network communication, as CORBA manages that aspect.

Reusability: Cost Savings: Components can be reused across different applications, which helps save on
development time and resources.

Disadvantages of CORBA

Complexity: Difficult Setup: Setting up and managing CORBA can be challenging, often requiring specialized
knowledge.

Performance : Slower Performance: The additional layers of communication may lead to slower system
performance.

Cost: Expensive: Implementing CORBA can incur significant costs due to licensing fees and necessary
resources.

Security: Challenging to Implement: Ensuring adequate security can be complex and requires careful
configuration.