CORBA (Common Object Request Broker

Architecture)
The Common Object Request Broker Architecture (CORBA) is a standard
defined by the Object Management Group (OMG) designed to facilitate the
communication of systems that are deployed on diverse platforms. CORBA
enables collaboration between systems on different operating systems,
programming languages, and computing hardware. CORBA uses an objectoriented model although the systems that use CORBA do not have to be objectoriented. CORBA is an example of the distributed object paradigm.
CORBA

Tweet

Short for Common Object Request Broker Architecture, an architecture that

enables pieces of programs, called objects, to communicate with one another
regardless of what programming language they were written in or what operating
system they're running on. CORBA was developed by an industry consortium
known as the Object Management Group (OMG).

There are several implementations of CORBA, the most widely used being IBM's SOM and
DSOM architectures. CORBA has also been embraced by Netscape as part of its Netscape
ONE (Open Network Environment) platform. Two competing models are Microsoft's
COM and DCOM and Sun Microsystems' RMI.

Common Object Request Broker Architecture (CORBA) is an architecture and specification

for creating, distributing, and managing distributed program objects in a network. It 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 Object Management Group (OMG), which currently includes over 500 member
companies. Both International Organization for Standardization (ISO) and X/Open have
sanctioned CORBA as the standard architecture for distributed objects (which are also known
as components). CORBA 3 is the latest level.

Download this free guide

Download Our Exclusive Big Data Analytics Guide

An unbiased look at real-life analytics success stories, including a Time Warner Cable case
study, and tips on how to evaluate big data tools. This guide will benefit BI and analytics
pros, data scientists, business execs and project managers.
The essential concept in CORBA is the Object Request Broker (ORB). ORB support in a
network of clients and servers on different computers means that a client program (which
may itself be an object) can request services from a server program or object without having
to understand where the server is in a distributed network or what the interface to the server
program looks like. To make requests or return replies between the ORBs, programs use the
General Inter-ORB Protocol (GIOP) and, for the Internet, its Internet Inter-ORB Protocol
(IIOP). IIOP maps GIOP requests and replies to the Internet's Transmission Control Protocol
(TCP) layer in each computer.
A notable hold-out from CORBA is Microsoft, which has its own distributed object
architecture, the Distributed Component Object Model (DCOM). However, CORBA and
Microsoft have agreed on a gateway approach so that a client object developed with the
Component Object Model will be able to communicate with a CORBA server (and vice
versa).

What is CORBA?
See also: What is Real-time CORBA?
The Common Object Request Broker Architecture (CORBA) is a standard developed by the
Object Management Group (OMG) to provide interoperability among distributed objects.
CORBA is the world's leading middleware solution enabling the exchange of information,
independent of hardware platforms, programming languages, and operating systems. CORBA
is essentially a design specification for an Object Request Broker (ORB), where an ORB
provides the mechanism required for distributed objects to communicate with one another,
whether locally or on remote devices, written in different languages, or at different locations
on a network.
The CORBA Interface Definition Language, or IDL, allows the development of language and
location-independent interfaces to distributed objects. Using CORBA, application
components can communicate with one another no matter where they are located, or who has
designed them. CORBA provides the location transparency to be able to execute these
applications.
CORBA is often described as a "software bus" because it is a software-based communications
interface through which objects are located and accessed. The illustration below identifies the
primary components seen within a CORBA implementation.

Data communication from client to server is accomplished through a well-defined objectoriented interface. The Object Request Broker (ORB) determines the location of the target
object, sends a request to that object, and returns any response back to the caller. Through this
object-oriented technology, developers can take advantage of features such as inheritance,
encapsulation, polymorphism, and runtime dynamic binding. These features allow
applications to be changed, modified and re-used with minimal changes to the parent
interface. The illustration below identifies how a client sends a request to a server through the
ORB:

Interface Definition Language (IDL)

A cornerstone of the CORBA standards is the Interface Definition Language. IDL is the

OMG standard for defining language-neutral APIs and provides the platform-independent
delineation of the interfaces of distributed objects. The ability of the CORBA environments to
provide consistency between clients and servers in heterogeneous environments begins with a
standardized definition of the data and operations constituting the client/server interface. This
standardization mechanism is the IDL, and is used by CORBA to describe the interfaces of
objects.
IDL defines the modules, interfaces and operations for the applications and is not considered
a programming language. The various programming languages, such as Ada, C++, or Java,
supply the implementation of the interface via standardized IDL mappings.
Application Development Using ORBexpress
The basic steps for CORBA development can be seen in the illustration below. This
illustration provides an overview of how the IDL is translated to the corresponding language
(in this example, C++), mapped to the source code, compiled, and then linked with the ORB
library, resulting in the client and server implementation.

The basic steps for CORBA development include:

Create the IDL to Define the Application Interfaces
The IDL provides the operating system and programming language independent interfaces to
all services and components that are linked to the ORB. The IDL specifies a description of
any services a server component exposes to the client. The term "IDL Compiler" is often
used, but the IDL is actually translated into a programming language.
Translate the IDL
An IDL translator typically generates two cooperative parts for the client and server
implementation, stub code and skeleton code. The stub code generated for the interface
classes is associated with a client application and provides the user with a well-defined
Application Programming Interface (API). In this example, the IDL is translated into C++.

Compile the Interface Files

Once the IDL is translated into the appropriate language, C++ in this example, these interface
files are compiled and prepared for the object implementation.
Complete the Implementation
If the implementation classes are incomplete, the spec and header files and complete bodies
and definitions need to be modified before passing through to be compiled. The output is a
complete client/server implementation.
Compile the Implementation
Once the implementation class is complete, the client interfaces are ready to be used in the
client application and can be immediately incorporated into the client process. This client
process is responsible for obtaining an object reference to a specific object, allowing the
client to make requests to that object in the form of a method call on its generated API.
Link the Application
Once all the object code from steps three and five have been compiled, the object
implementation classes need to be linked to the C++ linker. Once linked to the ORB library,
in this example, ORBexpress, two executable operations are created, one for the client and
one for the server.
Run the Client and Server
The development process is now complete and the client will now communicate with the
server. The server uses the object implementation classes allowing it to communicate with the
objects created by the client requests.
In its simplest form, the server must perform the following:

Create the required objects.

Notify the CORBA environment that it is ready to receive client requests.

Process client requests by dispatching the appropriate servant.

CORBA Programming Definitions

Within a CORBA development process, there are a number of unique terms specific to a
CORBA implementation. Developers may find our Glossary of Terms helpful in
understanding a full CORBA implementation.
Interoperability
The first version of CORBA provided the IDL and standard mappings to just a few
languages, and as the CORBA standard has matured, CORBA 2.0 added more language
bindings (particularly C++ and Java) as well as General Inter-ORB Protocol (GIOP). When a
client calls a CORBA operation, the client ORB sends a GIOP message to the server. The
server ORB converts this request into a call on the server object and then returns the results in
a GIOP reply. This standard transfer syntax, specified by the Object Management Group,
allows the interoperability of ORB-to-ORB interaction and is designed to work over any
transport protocol meeting a minimal set of assumptions.

When GIOP is sent over TCP/IP, it is called Internet Inter ORB Protocol (IIOP). IIOP is
designed to allow different ORB vendors to interoperate with one another. An example of this
interoperability occurs when there is communication between an enterprise designed ORB,
and a smaller real-time application, utilizing a real-time ORB.
Object Management Group (OMG)
The OMG is a non-profit consortium created in 1989 to promote the theory and practice of
object technology for the development for distributed operating systems. The goal is to
provide a common architectural framework for object-oriented applications based on widely
available interface specifications. With a membership of over 800 members, representing
large and small companies within the computer industry, OMG leads the specification
development efforts of CORBA, OMG IDL, IIOP, OMA, UML, MOF, and CWM
specifications.
The OMG does not produce software or implementation guidelines, only the specifications to
which OMG members respond to in Request For Information (RFI) and Requests for
Proposals (RFP). By managing these specifications, the OMG supports the adoption process
for the member companies interested in advancing the uses and applications of distributed
object-oriented computing.
CORBA Technology and the Java Platform Standard Edition

The Java Platform Standard Edition, v1.4, provides an Object Request Broker (ORB) and two
CORBA programming models that can utilize the Java CORBA ORB and Internet InterORB
Protocol (IIOP). This topic discusses these options for creating and distributing CORBA
technology.
CORBA technology is an integral part of the Java platform. It consists of an Object Request
Broker (ORB), APIs for the RMI programming model, and APIs for the IDL programming
model.
For more information on which specifications are implemented in this release of the Java
platform, see the compliance document.
How does Java SE leverage CORBA

Common Object Request Broker Architecture (CORBA) technology is the open standard for
heterogeneous computing. CORBA complements the Java platform by providing a
distributed object framework, services to support that framework, and interoperability with
other languages. The Java platform complements CORBA by providing a portable, highly
productive implementation environment, and a very robust platform. By combining the Java
platform with CORBA and other key enterprise technologies, the Java Platform is the
ultimate platform for distributed technology solutions.
CORBA standards provide the proven, interoperable infrastructure to the Java platform. IIOP
(Internet Inter-ORB Protocol) manages the communication between the object components
that power the system. The Java platform provides a portable object infrastructure that works
on every major operating system. CORBA provides the network transparency, Java provides
the implementation transparency.

The Object Request Broker

An Object Request Broker (ORB) is part of the Java Platform Standard Edition, since version
1.3. The ORB is a runtime component that can be used for distributed computing using IIOP
communication.
NOTE: Although it is true that ORBs written in different languages should be able to
talk to each other, we haven't tested the interoperability of the Java ORB with other
vendor's ORBs.
The Object Management Group (OMG) is an industry consortium that creates and publishes
specifications for CORBA. Vendors implement the specifications to produce products known
as Object Request Brokers (ORB). The good news for developers is that the Java Platform
Standard Edition, v1.2 and higher includes an ORB that is available in every deployment of
the Java Platform Standard Edition. For more information, see the ORB class.
The Java CORBA ORB supports both the RMI and IDL programming models, both of which
can use the underlying IIOP wire-level protocol for communication.
Comparison of IDL and RMI programming models
There are several scenarios that will define how you will want to create distributed CORBA
applications. Here are some of them:

If you have been developing CORBA applications using IDL for some time,
you will probably want to stay in this environment. Create the interfaces
using IDL, and define the client and server applications using the Java
programming language to take advantage of its portabile, highly
productive implementation environment, and its very robust platform.

If all of your applications are written in the Java programming language,

you will probably want to use Java RMI to enable communication between
Java objects on different virtual machines and different physical machines.
Using Java RMI without its IIOP option leverages its strengths of code
portability, security, and garbage collection.

If you are writing most of your new applications using the Java
programming language, but need to maintain legacy applications written
in other programming languages as well, you will probably want to use
Java RMI with its IIOP compiler option.

What about CORBA and J2EE?

In addition to Java IDL and RMI over IIOP, J2EE includes Enterprise JavaBeans
technology (EJB).
Enterprise JavaBeans is part of the Java Platform, Enterprise Edition. The EJB server-side
component model simplifies development of middleware components that are transactional,
scalable, and portable. EJB servers reduce the complexity of developing middleware by
providing automatic support for middleware services such as transactions, security, database
connectivity, and more.

EJBs use RMI over IIOP for their distributed object model, and use the Java Transaction
Service (JTS) for their distributed transaction model. When Enterprise JavaBeans are
implemented using the RMI over IIOP protocol for EJB interoperability in heterogeneous
server environments, the standard mapping of the EJB architecture to CORBA enables the
following interoperability:

A Java client using an ORB from one vendor can access enterprise beans
residing on an EJB server provided by another vendor.

Enterprise beans in one EJB server can access enterprise beans in another
EJB server.

A non-Java platform CORBA client can access any enterprise bean object.