Lesson 1

In this lesson you will explore the basic building blocks of CORBA (Common Object Request Broker Architecture) and how they fit together to support distributed, object-oriented applications. CORBA is a standard from the Object Management Group (OMG) that was widely used to connect software components written in different languages and running on different platforms. Today, CORBA is mostly a legacy technology, but its design still provides useful background when you compare it with modern approaches such as HTTP/JSON APIs or gRPC.

Lesson objective

After working through this lesson, you should be able to:

• Explain why distributed applications are hard to build and maintain.
• Identify the core CORBA building blocks: ORB, IDL, stubs, skeletons, and object references.
• Describe the Object Management Architecture (OMA) and where these pieces fit.
• Relate CORBA interfaces to object modeling in C++ and other languages.
• Contrast CORBA-style distributed objects with modern service-based designs.

Why distributed applications are challenging

A distributed application is one in which components run on different computers yet must collaborate as if they were part of a single program. Even simple business systems become difficult when you distribute them, because you must handle:

1. Distributed data — the data you need lives in more than one place.
2. Distributed computation — different machines perform different parts of the work.
3. Distributed users — people connect from multiple locations and devices.

Without a framework, every application would need to reinvent solutions for naming remote objects, marshalling parameters, handling failures, and securing communication. CORBA’s goal was to standardize these concerns so that you could focus on the application’s object model instead of low-level networking details.

Background: what came before CORBA?

CORBA did not appear in isolation. It built on a few important ideas:

• Remote Procedure Call (RPC) — treat a call to a function on another machine as if it were a local call, hiding the network behind a stub.
• Distributed Computing Environment (DCE) — combined RPC, naming, and security into a framework for distributed systems.
• Object-oriented programming — languages such as C++ encouraged thinking in terms of objects with well-defined interfaces and encapsulated state.

CORBA took the RPC concept and extended it into an object-oriented model: instead of calling a remote procedure, you invoke methods on remote objects defined by language-neutral interfaces.

Core CORBA building blocks

1. Object Request Broker (ORB)

The Object Request Broker (ORB) is the heart of CORBA. It acts as a message bus for remote object invocations. From a client’s point of view, you make a method call on an object reference; the ORB locates the object implementation, sends the request across the network, waits for the reply, and returns the result.

Every CORBA application links against an ORB implementation. In C++, you typically initialize the ORB in main(), obtain object references, invoke remote operations, and then shut the ORB down in a controlled way, following RAII-style ownership rules for ORB resources.

Corba Fundamentals

2. Interface Definition Language (IDL)

CORBA uses an Interface Definition Language (IDL) to describe the operations offered by distributed objects. IDL is language-neutral: it does not belong to C++, Java, or any specific implementation language. Instead, tools generate language-specific bindings from the IDL.

// Example of a simple CORBA IDL interface
module banking {
  interface Account {
    double get_balance();
    void deposit(in double amount);
    void withdraw(in double amount);
  };
};

For C++ developers, the IDL becomes a contract that tools transform into C++ header files and source files. Those generated files contain C++ classes and types that match the interface you modeled. In an object-oriented design, you treat the IDL interface much like a pure abstract base class that defines the public behavior of your service.

3. Stubs and skeletons

Once you have an IDL file, the CORBA IDL compiler generates two kinds of artifacts:

• Client stubs — classes that the client code calls. They look like ordinary C++ methods, but under the hood they package the parameters, send the request to the ORB, and unpack the reply.
• Server skeletons — base classes on the server side that receive requests from the ORB and delegate them to your concrete implementation classes.

From an object modeling perspective, you typically:

1. Define the interface in IDL.
2. Generate stubs and skeletons.
3. Implement the server by subclassing the skeleton in C++ and providing the method bodies.
4. Use the stubs in client-side code as if they were local objects.

4. Object references and naming

A CORBA object reference is a handle that identifies a remote object. Clients do not know where the object lives or how it is implemented; they only hold a reference and call methods through it.

To make these references discoverable, CORBA defines services such as the Naming Service and the Trader Service. These services allow you to bind object references to names (for example, "bank/primaryAccount") and later look them up, similar to a directory.

5. Transport and IIOP

To move requests across the network, CORBA specifies the Internet Inter-ORB Protocol (IIOP). IIOP defines how ORBs encode requests and replies over TCP/IP. In practice, the ORB hides IIOP from you, but it is the reason two different vendors’ ORBs can interoperate.

6. Object Management Architecture (OMA)

The Object Management Architecture (OMA) provides the big-picture structure for CORBA-based systems. It distinguishes between:

• Application objects — the domain-specific objects you define using IDL and implement in C++ or another language.
• Object services — standardized infrastructure services such as naming, security, transactions, and events.
• Common facilities — higher-level capabilities, such as user interface or information management facilities, intended to be reused across many applications.

Understanding OMA helps you separate your domain model from infrastructure concerns: your C++ classes express business behavior, while CORBA services handle cross-cutting tasks such as identity, security, and persistence.

Putting it all together: a request lifecycle

When a client calls a method on a CORBA object, the pieces interact as follows:

1. You model the interface in IDL and generate stubs and skeletons.
2. The server implements the skeleton in C++ and registers the object with the ORB and naming service.
3. The client initializes its ORB, looks up an object reference, and calls a method on the stub.
4. The stub passes the request to the ORB, which uses IIOP to contact the server ORB.
5. The server ORB dispatches the request to the skeleton, which invokes the C++ implementation.
6. The result flows back through the skeleton, ORBs, and stub to the client.

To the client code, the call looks like a normal method invocation on a C++ object. CORBA’s building blocks collaborate behind the scenes to make the distributed call behave as much like a local call as possible.

CORBA today and modern best practices

New applications rarely start with CORBA today. Instead, architects choose options such as RESTful HTTP APIs, gRPC, or message queues. However, many organizations still run systems that rely on CORBA. In that context, modern best practices include:

• Isolating CORBA behind a boundary or façade instead of spreading CORBA types across your codebase.
• Using clear IDL contracts and mapping them to well-designed C++ interfaces.
• Applying RAII and smart pointers on the C++ side to manage resources safely.
• Introducing adapters that translate between CORBA objects and newer protocols when you modernize.

Even if you never write new CORBA code, understanding these building blocks will help you recognize the same recurring ideas in modern distributed systems: interface contracts, generated client code, naming and discovery, and infrastructure services that sit underneath your object model.