CORBA is a standard for an object request broker architecture that was developed by the Object Management Group in the 1990s. It was hoped that this would be widely adopted and that implementations of the standard would be available from competing vendors. The OMG standards are available from their website.

The OMG’s vision of a distributed application is shown in Figure 1, which I have adapted from Siegel’s diagram of the Object Management Architecture (Siegal, 1998). This proposes that a distributed application should be made up of a number of components:

  • Application objects that are designed and implemented for this application.
  • Standard objects that are defined by the OMG for a specific domain. These domain object standards cover finance/insurance, electronic commerce, healthcare, and a number of other areas.
  • Fundamental CORBA services that provide basic distributed computing services such as directories, security management, etc.
  • Horizontal CORBA facilities such as user interface facilities, system management facilities, etc. The term horizontal facilities suggests that these facilities are common to many application domains and the facilities are therefore used in many different applications.
Figure 1. The structure of a CORBA-based distributed application

The CORBA standards cover all aspects of this vision. There are four major elements to these standards:

  • An object model for application objects where a CORBA object is an encapsulation of state with a well-defined, language-neutral interface described in an IDL (Interface Definition Language).
  • An object request broker (ORB) that manages requests for object services. The ORB locates the object providing the service, prepares it for the request, sends the service request and returns the results to the requester.
  • A set of object services that are general services likely to be required by many distributed applications. Examples of services are directory services, transaction services and persistence services.
  • A set of common components built on top of these basic services that may be required by applications. These may be vertical domain-specific components or horizontal, general-purpose components that are used by many applications.

The CORBA object model considers an object to be an encapsulation of attributes and services, as is normal for objects. However, CORBA objects must have a separate interface definition that defines the public attributes and operations of the object. CORBA object interfaces are defined using a standard, language-independent interface definition language (IDL). If an object wishes to use services provided by another object then it accesses these services through the IDL interface. CORBA objects have a unique identifier called an Interoperable Object Reference (IOR). This IOR is used when one object requests services from another. These requests are processed by the object request broker.