All About CORBA

Imagine a middleman who bro- kers
objects from all over the world. If a retailer sends this middleman a request for a
particular object, the middleman can quickly locate the manufacturer who can fulfill this
request. This middleman can communicate to the manufacturer the exact specifications of
the object as requested by the retailer. In addition, the middleman can advertise objects
on behalf of the manufacturer. The middleman can also quickly and effectively transport
requested objects from the manufacturer to the retailer.

Just like this hypothetical
middleman Common Object Request Broker Architecture or CORBA, helps applications that
might not otherwise be able to communicate with one another. CORBA is middleware-through
which an application can request pieces of information from another application. Like the
hypothetical middleman CORBA enables one application, called the client, to request pieces
of information from another application called the object implementation.

The modus operandi
How does CORBA intermediate between two applications, regardless of the application’
language differences? Programmers can use a variety of CORBA interfaces to enable clients
to access information from object implementations. For example, a programmer can use CORBA
Interface Definition Language (IDL) stubs and IDL skeletons to enable inter-application
communication. IDL skeletons are interfaces through which CORBA communicates with object
implementations. IDL skeletons map IDL to the object implementation’s language.

Programmers create IDL stubs and
skeletons by writing an IDL specification for each type of object a client can request
from an object implementation. For example, if a programmer wants to enable a Java
application or the client to access information from a C++ application, the object
implementation, the programmer writes an IDL specification for each type of C++ object,
the Java application must access. These C++ objects could include information such as
product pricing.

These IDL specifications will also
include the types of operations that can be performed on the objects. After writing the
necessary IDL specifications, the programmer runs these specifications through a CORBA IDL
compiler. The compiler then produces IDL stubs written in the Java language for the
client, and IDL skeletons written in C++ for the object implementation. Finally, the
programmer adds the IDL stubs to the client and the IDL skeletons to the object
implementation.

Another way progammers can enable
CORBA to intermediate between applications is through a Dynamic Invocation Interface (DII)
and Dynamic Skeleton Interface (DSI). A DII enables CORBA to accept client requests for
services and a DSI enables CORBA to access object implementations.

Through a DII, a programmer can
enable a client to specify the following:

The type of object the
client needs

The operation the client wants CORBA
to perform on that object

Any special parameters that must be
applied to the object.

The code that allows a client to
request CORBA services through a DII resides in CORBA’s interface repository. The
interface repository is a database in which language-specific mappings to CORBA objects
and operations reside. Through a DSI, a programmer can enable an object implementation to
respond to client requests for objects. The code that allows an object implementation to
supply CORBA services to a requesting client also resides in CORBA’s interface repository.

The realm
CORBA also provides services through Object Adapters and the Object Request Broker (ORB)
Interface. Object Adapters are software components that interface directly with the ORB
core. These components allow object implementations to access the core services CORBA
provides, such as mapping object references from the object implementation’s language to
IDL.

The ORB core comprises the
infrastructure upon which all other CORBA components are built. In addition, the ORB core
provides CORBA with the basic communication services necessary to transfer requests from
clients to object implementations. The ORB interface provides both clients and object
implementations with direct access to these basic services.

The CORBA trader service also
enables clients to access the services offered through these new object implementation
servers, without further ado. In fact, CORBA is to the computing world of clients and
object implementations what the hypothetical middleman is to his or her world of retailers
and manufacturers. The one notable exception in this comparison is that: CORBA isn’t
hypothetical.

Courtesy: Novell

Leave a Reply

Your email address will not be published. Required fields are marked *