CORBA

 

CORBA is part of the Object Management Architecture (OMA), developed by OMG, which is also the broadest distributed object middleware available in terms of scope. It allows integration of a wide variety of object systems. Figure 4 shows the basic OMA reference model from the OMG specification [5]. The Object Request Broker (ORB) component enables clients and objects to communicate in a distributed environment. Four categories of object interfaces use ORB to interact:

• Object Services are interfaces for general services that are likely to be used in any program based on distributed objects.
• Common Facilities are interfaces for horizontal end-user-oriented facilities applicable to most application domains.
• Domain Interfaces are application domain-specific interfaces, which may also be a collection of different Domain Interfaces such as Finance, Telecom, Transportation, etc.
• Application Interfaces are non-standardized application-specific interfaces.

  
Figure 4: OMG reference model architecture

The key component in OMA is ORB, or specified as CORBA. From the above description, it is not hard to see that ORB needs to provide the functions of delivering requests to objects and returning any responses to the clients targeted. As a distributed environment, ORB shall also support the transparency requirement. CORBA presents a nice architecture of an ORB, which handles a series of jobs like object allocation, object implementation, object execution state, object communication mechanisms, etc. Following the CORBA architecture, most of the jobs to delivery object communication are transparent. In this sense, the four categories of OMA objects can be connected to a CORBA ORB to form a distributed computing environment without worrying about any of the communication issues among them. Figure 5 demonstrates CORBA ORB architecture with its key components. Here, we try to understand CORBA structure through studying some of its key components. Some features that are important to CORBA are also discussed below.

  
Figure 5: CORBA ORB architecture

Clients

Based on OO model, a client of an object has access to an object reference for the object, and invokes operations on the object. A client only knows the logical structure of the object according to its interface and experiences the behavior of the object through invocations. Clients are normally the programming end, and thus shall be able to initiate and process requests on an object. Another important feature to be concerned is the portability of a client, which is more related with dynamic invocation.

Object Implementations

An object implementation provides the semantics of an object, usually by defining data for the object instance and code for the object's methods. CORBA object implementations do not depend on the ORB or the client, as the client does not know how an object is implemented. An object implementation provides one or multiple interfaces for referencing.

Object References

In distribution environment, the client does not know where the target object resides. An object reference specifies an object within an ORB. Both clients and object implementations have an opaque notion of object references according to the language mapping, and thus are insulated from the actual representation of them. Note that CORBA also has a distinguished object reference, guaranteed to be different from all object references, that denotes no object.

OMG Interface Definition Language

OMG IDL defines the types of objects by specifying their interfaces. An object's interface specifies the operations and types that the object supports and thus defines the requests that can be made on the object. OMG IDL is language-independent declarative language (i.e., not a programming language). Interfaces are defined separately from object implementations. The beauty is to allow objects to be constructed using different programming languages and yet still communicate with one another through interfaces, which can be implemented based on platforms.

OMG IDL can be mapped to classes in C++ and interfaces in Java naturally. CORBA specification defines all basic types, constructed types, template types, object reference types, and interface inheritance. Vinoski gives the results mapping OMG IDL types to C++ in Table 1 [10].

 

OMG IDL Type C++ Type

long,short long,short

float,double float,double

enum enum

char char

boolean bool

octet unsigned char

any Any class

struct struct

union class string wstring

sequence class

fixed Fixed template class

object reference pointer or object

interface class

 

IDL is essentially the means by which a particular object implementation tells its potential clients what operations are available and how they should be invoked.

Stubs and Skeletons

Client stubs and implementation skeletons are generated to enable static invocations to objects much like the case in RPC. The stubs make calls on the rest of the ORB using interfaces that are private to, and presumably optimized for, the particular ORB Core. The skeletons provide up-call interfaces for accessing objects. So in an invocation process, the stub works directly with the client ORB to marshal the request. Once the request arrives at the target object, the server ORB and the skeleton cooperate to unmarshal the request and dispatch it to the object. It is worth to notice that the dispatching through stubs and skeletons is a static invocation, because both of the stubs and skeletons have complete priori knowledge of the OMG IDL interfaces of CORBA objects being invoked.

Dynamic Invocation and Skeleton Interfaces

In comparing with the static invocation, CORBA also provides a way of handling invocation dynamically through dynamic invocation interface (DII) and dynamic skeleton interface (DSI). DII supports dynamic client request invocation, that is, rather than calling a stub routine that is specific to a particular operation on a particular object, a client may specify the object to be invoked, the operation to be performed, and the set of parameters for the operation through a call or sequence of calls. DSI provides dynamic dispatch to objects. An object's implementation is reached through an interface that provides access to the operation name and parameters in a manner analogous to the client side's DII. The dynamic invocation also allows three ways of invocation, namely synchronous invocation, deferred synchronous invocation, and oneway invocation (see [5] for details).

Object Adapters

Object adapter is a critical component in CORBA. It serves as the glue between CORBA object implementations and the ORB itself providing access to ORB services. Without object adapters, the ability of CORBA to support diverse object implementation styles would be severely compromised, because object implementations need to connect to the ORB directly, which apparently increases the complexity of ORB, and sacrifices the flexibility. CORBA normally allows multiple object adapters. A different object adapter may necessary for each different programming language or object implementation. CORBA also intends to develop object adapters that are easy to use with multiple ORBs, which is named Portable Object Adapter (POA). The main design goal of POA is to minimize the rewriting effort for different vendors' implementations, and make the IDL mapping to languages largely automatic.

ORB Interface

ORB interface is a simple interface that goes directly to the ORB providing the access ability. As CORBA itself is a model-driven architecture, most components in CORBA provide interface classes for the reason of flexibility.

Interface Repository and Implementation Repository

Interface repository and implementation repository provide a way of supporting dynamic invocation. Interface repository is a service that provides persistent objects that represent the IDL information in a form available at run-time. Implementation repository contains information that allows the ORB to locate and activate implementations of objects.

CORBA provides a flexible communication and activation substrate for distributed heterogeneous OO computing environments. Many other features are described in [5], which we can not cover here for the purpose of this survey. One important thing CORBA trying to achieve is to integrate different legacies like DCE, COM, etc. In other words, the integration helps solving the heterogeneity problem. With the use of OMG IDL to define object interfaces, a CORBA system can be written in C, C++, Smalltalk, Ada'95, Java, COBOL, Modula-3, Perl, and Python.

Although COBRA seems to be designed to achieve all communication functions, the design theme underlying is still to keep the ORB as simple as possible, and push as much functionality as possible to other OMA components such as Object Services and Common Facilities [10]. The reason is that CORBA is designed to achieve a high level of abstraction, which can supervise any specific implementation later. Thus, simplify ORB structure is key to make CORBA successful. In other words, The job of ORB is to simply provide the communication and activation infrastructure for distributed object applications.