Three of the more popular distributed object paradigms are Microsoft's Distributed Component Object

Model (DCOM), OMG's Common Object Request Broker Architecture (CORBA), and Sun’s
Java/Remote Method Invocation (Java/RMI). In this article, you learn about the CORBA architecture and the
mechanics of developing CORBA clients and servers.

The CORBA Distributed Computing Model

CORBA is a structural architecture designed to support heterogeneous object systems.

CORBA defines a model that specifies interoperability between distributed objects on a network in a way that is
transparent to the programmer.

CORBA automatically handles a lot of network programming tasks, such as object registration, object location,
object activation, request demultiplexing, frame and error-handling, marshaling, and operation dispatching.

CORBA objects are accessed through the use of an interface. OMG's Interface Definition Language (IDL, for
short) is used to define interfaces, their attributes, methods, and parameters to those methods within the
interface.

CORBA relies on a protocol called the Internet Inter-ORB Protocol (IIOP) for remoting objects. Everything
in the CORBA architecture depends on an Object Request Broker (ORB).

Some of the benefits of CORBA include, but are not limited to, the following:

1. CORBA forces a separation of an object’s interface and its implementation.

2. CORBA’s support for reuse is inherent to the technology.

3. CORBA is scalable.

4. CORBA enforces transparency of platforms and languages.

5. CORBA provides interoperability.

6. CORBA abstracts network communication from the developer.

The Object Management Architecture

OMG, the industry consortium that created the CORBA standard, defines two basic models on which CORBA
and all its standard interfaces are based. They are

• The Core Object Model and

• The Reference Model

Compiled by T V Sathyanarayana
The Core Object Model defines concepts that facilitate distributed application development using the Object
Request Broker (ORB). It defines a framework for refining the CORBA model to a concrete form. The Core
Object Model is an abstract specification that does not attempt to detail the syntax of object interfaces or any
other part of the ORB This model provides the basis for CORBA, but is more relevant to ORB designers and
implementers than it is to application developers.

The Figure 1 shows the OMA Reference Model.

Figure 1: The Object Management architecture

The Reference Model defines a development model for CORBA and its standard interfaces through which
developers can create and use frameworks, components, and objects. This model places the ORB at the center
of a grouping of objects with standardized interfaces that provide support for application developers. In addition
to the ORB, the Reference model identifies four groupings:

• Object Services, which provide the infrastructure.

• Domain Interfaces, which provide support for applications from specific industry domains.
• Common Facilities, which provide application-level services across domains.
• Application Interfaces, which is the set of objects developed for a specific application.

The CORBA 2.0 architecture

Compiled by T V Sathyanarayana
Figure 2 shows the CORBA 2.0 architecture. In CORBA, the IDL compiler generates type information for each
method in an interface and stores it in the Interface Repository (IR). A client can thus query the IR to get run-
time information about a particular interface and then use that information to create and invoke a method on the
remote CORBA Server Object dynamically through the Dynamic Invocation Interface (DII). Similarly, on the
server side, the Dynamic Skeleton Interface (DSI) enables a client to invoke an operation of a remote CORBA
Server Object that has no compile time knowledge of the type of object it is implementing.

Figure 2: CORBA 2.0 architecture

The Object Request Broker (ORB)

The central component of CORBA is the Object Request Broker (ORB). This component provides all the
communication infrastructure needed to identify and locate objects, handle connection management, and deliver
data and request communication.

One CORBA object never talks directly with another. Instead, the object requests for an interface to the ORB
running on the local machine. The local ORB then passes the request to an ORB on the other machine. The
remote ORB then locates the appropriate object and passes back an object reference to the requester.

The functions of the ORB are as follows:

• Lookup and instantiate objects on remote machines

• Marshal parameters from one application object to the other
• Handle security issues across machine boundaries
• Retrieve and publish data on objects on the local machine for another ORB to use

Compiled by T V Sathyanarayana
 • Invoke methods on a remote object using static method invocation
• Invoke methods on a remote object using dynamic method invocation
• Automatically instantiate objects not currently running
• Route callback methods to the appropriate local object being managed
• Communicate with other ORBs using the Internet Inter-ORB Protocol (IIOP)

Object Adapters
An Object Adapter is a server-side facility that provides a mechanism for the CORBA object implementations
to communicate with the ORB and vice versa. An Object Adapter also extends the functionality of the ORB. An
Object Adapter is layered on top of the ORB Core to provide an interface between the ORB and the object
implementation. Object Adapters can also be used to provide specialized services optimized for a particular
environment, platform, or object implementation.

Some of the services provided by an Object Adapter are

• Registration of server object implementations with the Implementation Repository

• Activation and deactivation of object implementations
• Instantiation of objects at runtime
• Generation and management of object references
• Mapping of object references to their implementations
• Dispatching of client requests to server objects through a skeleton or the Dynamic Skeleton Interface
(DSI)

While many object adapter implementations may exist for unique situations, the CORBA specification only
requires implementations to provide a Basic Object Adapter (BOA) or a Portable Object Adapter (POA) which
is a portable version of the BOA.

Basic Object Adapter (BOA)

The BOA is a pseudo-object and is created by the ORB, but it is invoked like any other object. The BOA
provides operations the CORBA Server Object implementations can access. It interfaces with the ORB Core
and with the skeletons of your object server implementation classes.

A BOA may be required to perform two types of activations on behalf of a client’s request: implementation
activation and object activation.

Implementation Activation: This occurs when the implementation for the target object is unavailable to handle
the request. This requires the use of a daemon that can launch a Java VM with the server’s byte code. The
information necessary to associate an object implementation with a Java class is stored in the Implementation
Repository.

Object Activation: This occurs when the target object is unavailable to handle the request.

Compiled by T V Sathyanarayana
The BOA is mandated by CORBA 2.0, but was recently deprecated in favor of a Portable Object Adapter
(POA). Even though vendors, to support existing implementations, may support the BOA, OMG will no longer
update the BOA specifications.

Portable Object Adapter (POA)

The POA addresses many problems found in applying the BOA. It mandates additional functionality and is
tightly specified to increase portability. With the POA API, the interfaces between the ORB and the object’s
implementation have been standardized. Thus, CORBA services stand a fighting chance of being ORB-
independent as well as interoperable.

The Implementation Repository

The Implementation Repository is an online database that contains information about the classes a server
supports, the objects instantiated, and their IDs. Additional information about a specific ORB implementation
may also sometimes be stored here.

The Dynamic Skeleton Interface (DSI)

For CORBA components that do not have an IDL-based compiled skeleton, the Dynamic Skeleton Interface
(DSI) provides a runtime binding mechanism. The DSI determines the target object for which a message is
meant by looking at the parameter values in an incoming message, so it can receive either static or dynamic
client invocations. The DSI thus allows servers to dispatch client operation requests to objects that were not
statically defined at compile time.

Interface Repository
The Interface Repository (IR) is an online database of metainformation about ORB object types.
Metainformation stored for objects includes information about modules, interfaces, operations, attributes and
exceptions.

The Dynamic Invocation Interface (DII)

During run time, the DII allows methods to be discovered dynamically so they can be invoked. Client programs
can obtain information about an object's interface from the Interface Repository and dynamically construct
requests to act on the object.

Compiled by T V Sathyanarayana
The Interface Definition Language (IDL)
Whenever a client needs some service from a remote distributed object, it invokes a method implemented by the
remote object. The service the remote distributed object (server) provides is encapsulated as an object and the
remote object's interface is described in an Interface Definition Language (IDL). The interfaces specified in the
IDL file serve as a contract between a remote object server and its clients. Clients can thus interact with these
remote object servers by invoking methods defined in the IDL. CORBA supports multiple inheritance at the
IDL level and allows exceptions to be specified in the IDL definitions.

A typical CORBA IDL definition looks like

module SimpleStocks {
interface StockMarket {
float get_price( in string symbol );
};
};

IDL to Java Mapping

The highlights of the IDL to Java mapping are as follows:

• An IDL module maps to a Java package of the same name.

• An IDL interface maps to a public Java interface with the same name.
• Inheritance of IDL interfaces is achieved through inheritance of Java interfaces.
• Nested IDL type definitions are mapped to Java classes using a scoped package name.
• IDL attributes are mapped to a pair of overloaded Java accessor and mutator methods.
• All IDL out and inout parameters require the use of a Holder class.

Generated classes
In addition to the Java class that maps directly from an IDL construct, helper and holder classes may be
generated to aid the developer in the use of the class.

Holder classes
The holder classes provide a level of indirection and are passed instead of the actual type. The client
instantiates a holder object and passes it in the operation invocation. The server may then set or modify the
value member of the holder object. Because the encapsulated actual object is modified without affecting the
holder object reference itself, the semantics of out and inout parameters are supported. Holder classes are
available for all the basic IDL datatypes in the org.omg.CORBA package and are generated for all named user-
defined types, except those defined by nonconstructed type typedefs.

Compiled by T V Sathyanarayana
Helper classes
A helper class contains convenience and utility methods for operating on the associated object. The purpose of
the helper class is to prevent bloating of the mapped classes with methods that may not be needed. The class
provides methods for reading and writing the object to a stream, obtaining the object’s repopsitory identifier,
and casting the object to/from a CORBA Any. The helper classes for mapped IDL interfaces also have the
narrow() method defined, which is used to cast the object reference of org.omg.CORBA.Object to the
base type of the helper.

Compiled by T V Sathyanarayana
 Java IDL Development Lifecycle

You are usually required to follow these steps:

1. Write a specification for each object using the IDL.

2. Use the IDL compiler to generate the client stub code and server skeleton code.

3. Write the client application code.

4. Write the server object code.

5. Compile the client and server code.

6. Start the server.

7. Run the client application.

Before developing CORBA servers and clients, make sure you have Java 1.2 and the idltojava compiler
installed on your machine. The JDK provides the API and ORB needed to enable CORBA-based distributed
object interaction. The idltojava compiler uses the IDL-to-Java mapping to convert IDL interface definitions to
corresponding Java interfaces, classes, and methods, which you can then use to implement your client and
server code.

Compiled by T V Sathyanarayana