Common Object Request Broker Architecture (CORBA)

Last Edited

by

Editorial Team

in

, , ,

In the evolving landscape of distributed computing, the Common Object Request Broker Architecture (CORBA) once stood as a groundbreaking framework, pivotal in enabling interoperability across heterogeneous systems. Developed by the Object Management Group (OMG), CORBA was designed to facilitate seamless communication between diverse applications in distributed environments, irrespective of platform or programming language.

This article delves into the intricacies of CORBA, detailing its architecture, mechanisms, and the role it played in pioneering distributed object management. We’ll explore why CORBA, a titan of its era, transitioned into the realm of legacy technologies and shed light on the modern architectures that have taken its place. From understanding the technical foundations of CORBA to tracing its path to obsolescence and examining the successors that dominate today’s distributed computing scenarios, this article aims to provide a comprehensive overview of CORBA’s journey through the technological timeline.

Table of Contents:

  1. What was the CORBA Architecture?
  2. How it Worked
  3. The Transition of CORBA to a Legacy Technology and Its Modern Successors
  4. References

1. What was the CORBA Architecture?

The Common Object Request Broker Architecture (CORBA) emerged as a significant force in the world of distributed computing, laying down a framework for objects and applications to communicate over a network. It was an ambitious attempt to create a universal standard that could bridge the gap between disparate computing systems.

CORBA - Common Object Request Broker Architecture model
CORBA Model

CORBA was not supported by Microsoft, which instead has developed its own distributed object management architecture called Distributed Component Object Model, or DCOM.

Back to Index

2. How it worked

In a CORBA environment, programs request services through an object request broker (ORB), which allows components of distributed applications to find each other and communicate without knowing where applications are located on the network or what kind of interface they use.

ORBs are the middleware that enable client and server programs to establish sessions with each other, independent of their location on the network or their programming interface.

The process of a client invoking a call to an application programming interface (API) on a server object is transparent.

The client issues the call, which is intercepted by the ORB. The ORB takes the call and is responsible for locating a server object that is able to implement the request. Once it has located such an object, the ORB invokes the object’s method and passes it any parameters submitted by the client.

The results are then returned to the client. ORBs communicate among themselves using the General Inter-ORB Protocol (GIOP) or the Internet Inter-ORB Protocol (IIOP) so that any ORB can fulfill any client request on the network.

Delving into the Technicalities

  1. Core Components:
    • Object Request Broker (ORB): At the heart of CORBA was the ORB, a middleware that allowed clients to transparently make requests and receive responses from distributed objects, or servers, across a network.
    • Interface Definition Language (IDL): CORBA utilized IDL to define the interfaces that objects presented to the outside world, ensuring a standardized method for different systems to understand each other’s capabilities.
  2. Mechanism of Operation:
    • Client-Server Communication: A client in a CORBA environment would make a request through the ORB, which then located the appropriate server object capable of fulfilling the request, irrespective of its location or the programming language used.
    • Protocol Use: ORBs communicated using the General Inter-ORB Protocol (GIOP) and its most common implementation, the Internet Inter-ORB Protocol (IIOP), facilitating interoperability over the internet.
  3. Designed for Interoperability:
    • CORBA’s architecture was crafted to allow programs written in different languages and running on various platforms to work together seamlessly. This interoperability was a major selling point in an era where heterogeneous computing environments were becoming more common.
  4. Distributed Object Model:
    • Unlike traditional client-server models, CORBA adopted a distributed object model, allowing for a more modular and scalable approach to building complex systems.

As innovative as CORBA was, its complexity, combined with the advent of simpler, more flexible technologies, led to its decline. In the following chapters, we’ll explore the factors contributing to its transition to legacy technology and the emergence of new paradigms that have reshaped the landscape of distributed computing.

Back to Index

3. The Transition of CORBA to a Legacy Technology and Its Modern Successors

Reasons for CORBA’s Transition to Legacy Status

  1. Complexity and Learning Curve:
    • CORBA was known for its complexity, both in terms of understanding the architecture and implementing it. The steep learning curve limited its adoption, especially among developers who favored more straightforward solutions.
  2. Rapid Technological Advancements:
    • The pace of technological change in distributed computing was rapid. Newer architectures and technologies that were easier to implement and more adaptable to web-based applications emerged, overshadowing CORBA.
  3. Interoperability Challenges:
    • Despite its goal of interoperability, in practice, achieving seamless communication across different CORBA implementations proved challenging, often requiring additional effort and customization.
  4. Shift to Web Services and SOA:
    • The rise of web services and Service-Oriented Architecture (SOA) provided a more flexible and internet-friendly approach to distributed computing. These technologies used standard web protocols like HTTP and data formats like XML and JSON, making them more accessible and easier to integrate.

Modern Architectures That Replaced CORBA

  1. Service-Oriented Architecture (SOA):
    • SOA emerged as a more flexible approach, allowing applications to provide and consume services over a network, typically using web service standards.
  2. RESTful APIs:
    • Representational State Transfer (REST) became a popular architectural style for designing networked applications, leveraging standard web protocols and methods, making it simpler and more effective for web-based services.
  3. Microservices Architecture:
    • The microservices architecture, which structures an application as a collection of loosely coupled services, gained popularity for its scalability and flexibility, especially in cloud-based environments.
  4. gRPC and Protocol Buffers:
    • Developed by Google, gRPC is a high-performance, open-source universal RPC framework that uses Protocol Buffers as its interface description language, providing efficient, language-agnostic, and platform-neutral communication.
Back to Index

4. References

Books

  1. “Client/Server Programming with Java and CORBA” by Robert Orfali and Dan Harkey.
  2. “Advanced CORBA Programming with C++” by Michi Henning and Steve Vinoski.

RFCs

  1. RFC 2714: “Schema for Representing CORBA Object References in an LDAP Directory.”
  2. RFC 3529: “Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP).”

Online Resources

  1. Object Management Group (OMG) CORBA Page: www.omg.org/corba
  2. “Service-Oriented Architecture: Concepts, Technology, and Design” by Thomas Erl (for understanding SOA and its comparison with CORBA).
  3. Corba.org
Back to Index

Search