CORBA Architecture Overview

CORBA stands for Common Object Request Broker Architecture. CORBA 2.0 is a specification for creating and using distributed objects. CORBA objects differ from typical programming language objects in these ways:

CORBA objects can be located anywhere on a network.
CORBA objects (like Java objects) can run on any platform.
CORBA objects can be written in any of several languages.

Location, platform, and language are invisible to a client of a CORBA object. Given a reference (a handle) to a CORBA object, a client can invoke the object's operations (methods) without regard for whether the object is far or near, runs on a Unix or Wintel machine, is written in C or Java. The reverse is also true: CORBA object developers need know nothing of where their clients will be, what hardware or OS they will run on, or what language they will be written in. In short, CORBA objects approach universal accessibility. This universality is no accident; the CORBA specification has been written by the Object Management Group, a consortium of over 500 software vendor and user organizations.

The JavaIDL product is an implementation of the CORBA 2.0 specification that gives Java programmers the ability to use CORBA objects and to create transient CORBA objects. The CORBA 2.0 specification includes the network protocol known as IIOP (Internet Inter-ORB Protocol), which is key to achieving interoperation among CORBA implementations. The JavaIDL reference implementation uses IIOP, but can also accommodate other network protocols. The following description is oriented toward CORBA implementations that use IIOP to communicate.

Note: This section summarizes the generic CORBA 2.0 information . For additional information, see the OMG specs.

Invocation Model

FIG. 1 An Object Invocation from a JavaIDL Client

FIG. 1 shows a request being sent by a JavaIDL client to a CORBA2.0 compliant object implementation. The Client is the Java program that wishes to perform an operation on the object and the Object Implementation is the code and data that actually implements the object. The JavaIDL runtime is referred to as an Object Request Broker (or an ORB). The ORB is responsible for all of the mechanisms required to find the object implementation for the request, to prepare the object implementation to receive the request, and to communicate the data making up the request. The Java interface the client sees is completely independent of where the object is located, what programming language it is implemented in, or any other aspect which is not reflected in the object's interface.

FIG. 2 The Structure of Object Request Broker Interfaces

FIG. 2 shows the structure of an individual Object Request Broker (ORB). The interfaces to the ORB are shown by striped boxes, and the arrows indicate whether the ORB is called or performs an up-call across the interface.

To make a request, the JavaIDL Client uses an OMG IDL stub available in Java (the specific stub depending on the interface of the target object). The Client can also directly interact with the ORB for some functions.

The Object Implementation receives a request as an up-call through the OMG IDL generated skeleton. The Object Implementation may call the ORB interfaces while processing a request or at other times.

In JavaIDL, interfaces are defined statically in an interface definition language, called the OMG Interface Definition Language (OMG IDL). This language defines the types of objects according to the operations that may be performed on them and the parameters to those operations.

FIG. 3 A Client using the Stub Interface

The client performs a request by having access to an Object Reference for an object and knowing the type of the object and the desired operation to be performed. The client initiates the request by calling stub routines that are specific to the object (see FIG. 3).

FIG. 4 An Object Implementation Receiving a Request

The server-side ORB locates the appropriate implementation code, transmits parameters and transfers control to the Object Implementation through an IDL skeleton (see FIG. 4). Skeletons are specific to the interface. In performing the request, the object implementation may obtain some services from the ORB. When the request is complete, control and output values are returned to the client.

FIG. 6 Interface and Implementation Repositories

FIG. 6 shows how interface and implementation information is made available to clients and object implementations. The interface is defined in OMG IDL; the definition is used to generate the client Stubs and the object implementation Skeletons. In addition, the interface is stored in an Interface Repository which provides services that are used by clients to access objects in a typed way.

JavaIDL does not provide an implementation of an Interface Repository. JavaIDL clients do not typically need or use an Interface Repository since all of the needed type information is available in the stubs or is resolved by an object's server. However, JavaIDL supports access to Interface Repository information made available by other CORBA object implementations. This information can be helpful for invoking objects using the Dynamic Invocation Interfaces in JavaIDL, or for writing CORBA object development tools.

Clients

A client of an object has access to an object reference for the object, and invokes operations on the object. A client knows only the logical structure of the object according to its interface and experiences the behavior of the object through invocations. Although we will generally consider a client to be a program or process initiating requests on an object, it is important to recognize that something is a client relative to a particular object. For example, the implementation of one object may be a client of other objects.

JavaIDL clients see objects and ORB interfaces through the perspective of the Java language mapping, bringing the ORB right up to the programmer's level. Clients are maximally portable and should be able to work without source changes on any CORBA2.0 compliant ORB that supports the Java language mapping with any object instance that implements the desired interface. Client code has no knowledge of the implementation of the object or which ORB is used to access the implementation.

Object Implementations

An object implementation provides the semantics of the object, usually by defining data for the object instance and code for the object's methods. Often the implementation will use other objects or additional software to implement the behavior of the object. In some cases, the primary function of the object is to have side-effects on other things that are not objects.

Object References

An Object Reference is the information needed to specify an object within an ORB. Both clients and object implementations have an opaque notion of object references according to the Java language mapping, and thus are insulated from the actual representation of them.

The representation of an object reference handed to a client is only valid for the lifetime of that client.

The language mapping also provides additional ways to access object references in a typed way for the convenience of the programmer (see Typesafe Narrowing).

There is a distinguished object reference, the null reference, guaranteed to be different from all object references, that denotes no object. In Java, this is a Java null.

OMG Interface Definition Language

The OMG Interface Definition Language (OMG IDL) defines the types of objects by specifying their interfaces. An interface consists of a set of named operations and the parameters to those operations. Note that although IDL provides the conceptual framework for describing the objects manipulated by the ORB, it is not necessary for there to be IDL source code available for the ORB to work. As long as the equivalent information is available in the form of stub routines the ORB is able to function correctly.

IDL is the means by which a particular object implementation tells its potential clients what operations are available and how they should be invoked. From the IDL definitions, the CORBA objects are mapped into the Java programming language by JavaIDL. The mapping includes definition of Java-specific data types and method interfaces to access objects through the ORB. It includes the client stubs, the implementation skeleton and the direct ORB interface. The language mapping also defines the interaction between object invocations and the threads of control in the client or implementation. The mapping provides synchronous calls, in that the method returns when the object operation completes.

Client Stubs

There is a Java interface to the stubs for each interface type. The stubs present access to the OMG IDL-defined operations on an object in a way that is easy for programmers to predict once they are familiar with OMG IDL and the language mapping. The stubs make calls on the rest of the ORB using interfaces that are private to JavaIDL.

CORBA Interface Repository

The Interface Repository is a service that provides persistent objects that represent the IDL information in a form available at runtime.

The JavaIDL runtime does not include an implementation of an InterfaceRepository and one is not generally required by clients at runtime. JavaIDL depends on a separate ORB, generally the one managing the services that the JavaIDL client is trying to access, to provide one if needed.

CORBA Implementation Repository

The Implementation Repository contains information that allows the ORB to locate and activate implementations of objects. Although most of the information in the Implementation Repository is specific to an ORB or operating environment, the Implementation Repository is the conventional CORBA place for recording such information. Ordinarily, installation of implementations and control of policies related to the activation and execution of object implementations is done through operations on the Implementation Repository.

In addition to its role in the functioning of the ORB, the Implementation Repository is a common place to store additional information associated with implementations of ORB objects. For example, debugging information, administrative control, resource allocation, security, etc., might be associated with the Implementation Repository.

The Implementation Repository supports the implementation of object servers. It is not needed by clients in order to access servers. In addition, simple servers can be written without the need of an Implementation Repository. JavaIDL does not provide one.

Structure of a Client

A client of an object has an object reference that refers to that object. An object reference is a token that may be invoked or passed as a parameter to an invocation on a different object. Invocation of an object involves specifying the object to be invoked, the operation to be performed, and parameters to be given to the operation or returned from it.

The ORB manages the control transfer and data transfer to the object implementation and back to the client. In the event that the ORB cannot complete the invocation, an exception response is provided. Ordinarily, a client calls a routine in its program that performs the invocation and returns when the operation is complete.

Clients access object-type-specific stubs as library routines in their program (see FIG. 7). The client program thus sees routines callable in the normal way in its programming language. All implementations will provide a language-specific data type to use to refer to objects, often an opaque pointer. The client then passes that object reference to the stub routines to initiate an invocation. The stubs have access to the object reference representation and interact with the ORB to perform the invocation.

FIG. 7 The Structure of a Typical Client

Clients most commonly obtain object references by receiving them as output parameters from invocations on other objects for which they have references. When a client is also an implementation, it receives object references as input parameters on invocations to objects it implements. An object reference can also be converted to a string that can be stored in files or preserved or communicated by different means and subsequently turned back into an object reference by the ORB that produced the string.

Structure of an Object Implementation

An object implementation provides the actual state and behavior of an object. The object implementation can be structured in a variety of ways. Besides defining the methods for the operations themselves, an implementation will usually define procedures for activating and deactivating objects and will use other objects or non-object facilities to make the object state persistent, to control access to the object, as well as to implement the methods.

The object implementation (see FIG. 8) interacts with the ORB in a variety of ways to establish its identity, to create new objects, and to obtain ORB-dependent services.

FIG. 8 The Structure of a Typical Object Implementation

Because of the range of possible object implementations, it is difficult to be definitive about how in general an object implementation is structured.

When an invocation occurs, the ORB and the skeleton arrange that a call is made to the appropriate method of the implementation. A parameter to that method specifies the object being invoked, which the method can use to locate the data for the object. Additional parameters are supplied according to the skeleton definition. When the method is complete, it returns, causing output parameters or exception results to be transmitted back to the client.

When a new object is created, the ORB is notified so that it knows where to find the implementation for that object. Usually, the implementation also registers itself as implementing objects of a particular interface, and specifies how to start up the implementation if it is not already running.

Typesafe Narrowing

Dynamic typing of object references is supported through narrowing. An object reference can be narrowed to its real type, that is, the type that the object it refers to was created as, or to any of the real type's ancestor types. The following example illustrates how the IDL definition represents IDL typing information.

FIG. 9 IDL Typing Representation

module m1 {
  interface i1 {
    long op1();
    long op2();
  };
  interface i2 :i1 {
    long op3();
  };
  interface i3 :i1 {
    long op4();
    long op5();
  };
};
module m2 {
  interface i4 :m1::i2 {
    long op6();
    long op7();
  };
};

If an object reference is of real type i4 and its apparent type is i1, this object reference can be narrowed to i2 or i4, but not to i3. This requires a traverse up the inheritance graph from the real type of the object reference.