Experiment No.

10

Aim: To prepare a case study on CORBA.

Theory:

What is CORBA?

The Common Object Request Broker Architecture (CORBA) serves as a specification

for a standardized middleware design, facilitating client-server software development.
In this model, clients can seamlessly invoke methods on server objects, whether they
reside on the same machine or across a network. The middleware handles the
intricacies of locating the appropriate object, passing parameters, invoking methods,
and returning results to the client. Importantly, clients are shielded from concerns such
as object location, programming language, or operating system, focusing solely on the
object's interface.

The CORBA reference model, known as the Object Management Architecture

(OMA), encompasses a set of specifications defining various services crucial for
building distributed client-server applications. These services, like naming,
transactions, and asynchronous event management, are formalized within the OMA,
providing a foundation for CORBA implementations.

Communication within CORBA systems is facilitated by the Object Request Broker

(ORB), also referred to as the object bus. As an example, consider a distributed
document management system. Within its interface, domain-specific services may
exist, tailored to different domains such as manufacturing.
The object interface encompasses domain-independent services, including:

Naming Service: Often likened to a white page service, the naming service allows
clients to search for server names and obtain their locations or addresses.

Trading Service: Analogous to a yellow page service, the trading service enables
clients to discover specific services. This is akin to searching for a service, like an
auto repair shop, in a directory.

The Broker pattern plays a pivotal role in adhering to core design principles within
CORBA:
1. Divide and Conquer: Remote objects can be designed independently,
promoting modular development.

2. Increase Reusability: Remote objects can be designed for general use,

allowing other systems to leverage them.

3. Design for Flexibility: Broker objects can be updated or redirected as needed,

offering adaptability to changing requirements.

4. Design for Portability: Clients can be developed for diverse platforms while
maintaining interoperability with brokers and remote objects on other
platforms.

5. Design Defensively: Remote objects can incorporate robust assertion checking,

enhancing reliability and security.
The components of object management architecture are:
Application Interface: The application interface in CORBA represents the
boundary through which clients interact with the distributed system. It
encapsulates the functionalities and services offered by the system, providing a
high-level abstraction for clients to access and utilise.

○ Responsibilities:
i. Defining high-level operations and functionalities accessible to
clients.
ii. Shielding clients from the underlying complexities of distributed
computing.
iii. Facilitating seamless interaction between clients and the
distributed system.
○ Characteristics:
 i. Provides a clear and intuitive interface for clients to interact with
the system.
ii. Abstracts away technical details such as object location,
communication protocols, and implementation specifics.
iii. Defines operations and behaviors tailored to meet the
requirements of the application domain.

Common Facilities: Common facilities within CORBA encompass a set of

services and functionalities that are fundamental to building distributed
systems. These facilities provide essential capabilities required for
communication, coordination, and management within the distributed
environment.

○ Examples of Common Facilities:

i. Naming Service: Allows clients to locate objects by name,
abstracting away the complexities of object location and
addressing.
ii. Transaction Service: Facilitates coordination and management of
distributed transactions, ensuring consistency and reliability
across multiple operations.
iii. Event Service: Enables asynchronous communication and event
notification between distributed components, supporting reactive
and event-driven architectures.
○ Role and Importance:
i. Provides foundational services required for building distributed
applications.
ii. Promotes standardization and interoperability across different
CORBA implementations.
iii. Facilitates seamless integration of distributed components,
enhancing scalability and flexibility.

Domain Interface: The domain interface in CORBA represents a specialized

set of services and functionalities tailored to a specific application domain. It
encapsulates domain-specific logic and functionalities, providing a cohesive
interface for clients within the domain.

○ Role and Scope:

i. Defines domain-specific operations and behaviors tailored to
meet the unique requirements of a particular application domain.
ii. Encapsulates domain-specific logic and business rules within the
distributed system.
 iii.Facilitates abstraction and encapsulation of domain complexities,
promoting modularity and maintainability.
○ Examples of Domain Interfaces:
i. Manufacturing Domain: Includes functionalities related to
production, inventory management, and supply chain
optimization.
ii. Healthcare Domain: Encompasses services for patient
management, electronic health records, and medical imaging.

Object Interface: The object interface in CORBA represents the contract

exposed by remote objects within the distributed system. It defines the set of
operations and attributes supported by an object, as well as the communication
protocols and data types used for interaction.

○ Components of Object Interface:

i. Operations: Define the actions or behaviors that clients can
invoke on the remote object.
ii. Attributes: Represent the state or properties of the object that can
be queried or modified by clients.
iii. Interfaces: Define the contracts and protocols for communication
between clients and the object.
○ Characteristics:
i. Encapsulates the functionalities and behaviors of remote objects
within the distributed system.
ii. Defines a standardized contract for interaction between clients
and objects, promoting interoperability and reusability.
iii. Facilitates loose coupling between clients and objects, allowing
for independent evolution and maintenance.
○ Example:
i. A remote object representing a bank account may expose
operations such as deposit, withdraw, and getBalance, along with
attributes such as account number and account balance.
Advantages of CORBA:

1. Interoperability: CORBA enables communication between heterogeneous

systems, allowing objects written in different programming languages and
running on different platforms to interact seamlessly.
2. Reusability: CORBA promotes the development of reusable components, as
objects can be designed to encapsulate generic functionalities that can be
leveraged across multiple applications.
3. Scalability: CORBA supports distributed computing, allowing systems to scale
horizontally by distributing components across multiple nodes, enhancing
performance and scalability.
4. Flexibility: CORBA architectures are highly adaptable, allowing for dynamic
reconfiguration and evolution of distributed systems without disrupting client
applications.
5. Standardization: CORBA provides a standardized framework for building
distributed systems, promoting consistency, interoperability, and ease of
integration across different platforms and environments.

Disadvantages of CORBA:

1. Complexity: Implementing and deploying CORBA-based systems can be

complex, requiring expertise in distributed computing concepts, middleware
configuration, and object-oriented programming.
2. Performance Overhead: The overhead associated with marshaling and
unmarshaling data, as well as the communication between client and server
objects, can impact performance, particularly in high-throughput applications.
3. Dependency on Middleware: CORBA implementations rely on middleware
infrastructure, which adds another layer of complexity and potential points of
failure to the system.
4. Learning Curve: Developing CORBA-based applications requires familiarity
with CORBA concepts, APIs, and development tools, which may pose a steep
learning curve for developers new to distributed computing.
5. Vendor Lock-in: Depending on the chosen CORBA implementation, there
may be vendor-specific extensions or dependencies, leading to vendor lock-in
and limiting portability and interoperability.
Applications of CORBA:

1. Telecommunications: CORBA is widely used in telecommunications for

building network management systems, service provisioning platforms, and
billing systems, enabling seamless communication between network elements
and management applications.
2. Finance: In the finance industry, CORBA is employed for building trading
systems, risk management platforms, and transaction processing systems,
facilitating real-time communication between trading desks, exchanges, and
clearinghouses.
3. Enterprise Integration: CORBA is utilized in enterprise integration scenarios
for integrating disparate systems and applications, enabling seamless data
exchange and business process automation across organizational boundaries.
4. Healthcare: In healthcare, CORBA is employed for building electronic
medical record systems, healthcare information exchanges, and medical
imaging solutions, facilitating interoperability and data sharing between
healthcare providers and systems.
5. Manufacturing: In manufacturing, CORBA is used for building supervisory
control and data acquisition (SCADA) systems, manufacturing execution
systems (MES), and supply chain management platforms, enabling real-time
monitoring and control of industrial processes.

Conclusion: We have successfully prepared the case study on CORBA.