OOPortal OOPortal


Corba Fundamentals   «Prev  Next»
Lesson 2 Where CORBA fits
ObjectiveBasic conceptual understanding of CORBA

CORBA Distributed Software

Role of Corba
Gain a basic conceptual understanding of what CORBA provides.
CORBA exists as a standardized way to create distributed software systems. CORBA allows the components of an application to exist across a network of computers, while still allowing the components to interact as a whole.
The general concept, as depicted below, is often called distributed computing.
  1. Basic idea centers around software component that provides some service: data retrieval
  2. There are also other software components that want to make use of the provider's services
  3. Distributed computing allows the two components, provider and user to communicate across a network
Basic idea centers around software component that provides some service: data retrieval

Distributed Computing Architectures
You are probably familiar with applications that perform work using other distributed computing models, but that do not make use of CORBA. In fact, the entire World Wide Web is a perfect example.
Common Object Request Broker Architecture (CORBA) is an architecture and specification for creating, distributing, and managing distributed program objects in a network. The architecture allows programs at different locations and developed by different vendors to communicate in a network through an "interface broker." CORBA was developed by a consortium of vendors through the (OMG) Object Management Group, which currently includes over 500 member companies.
Both International Organization for Standardization (ISO) and X/Open have authorized CORBA as the standard architecture for distributed objects (which are also known as components). CORBA 3 is the latest level.

(OMG) Object Management Group

When the Object Management Group (OMG) issued a Request For Proposals (RFP) for a standard mapping of CORBA to C++, these developers and other groups submitted their mappings to the standardization process. As is common for OMG RFP submissions, the submitting groups joined forces to try to reach consensus and arrive at a single C++ mapping specification that would draw from the strengths of all the submitted mappings. The process of producing a single standard C++ mapping for CORBA took approximately 18 months, lasting from the spring of 1993 until the fall of 1994. For technical reasons, such as the richness of C++ and its support for diverse programming styles, the consensus-building process was not an easy one. At one point, because of the competitive spirit and political nature of some of the parties involved (both characteristics are inevitable in any industry standards group), the C++ mapping standardization effort fell apart completely. However, the need for a standard C++ mapping eventually overcame all obstacles, and the standardization was completed in the fall of 1994.
The C++ mapping was first published with CORBA 2.0. Since its adoption, the mapping has been revised several times to fix flaws and to introduce minor new functionality. Despite this, the mapping has remained surprisingly stable and portable even while the C++ language was undergoing its own standardization process. The standard C++ mapping removed a major obstacle to broad acceptance of CORBA because it created source code portability, at least for the client side. The server side still suffered from portability problems until CORBA 2.2.