Open Hypermedia Systems Working Group

CORBA

CORBA is an acronym for Common Object Request Broker Architecture. CORBA is a mature component technology currently in its second design generation. CORBA is being developed by an organization called OMG or the Object Management Group. OMG's members consist of people from a large number of companies, universities, and government organizations. The goal of the OMG is to create an open distributed object infrastructure. The OMG formed in 1989 and produced an initial specification, CORBA 1.2, soon thereafter. CORBA vendors offered products based on this specification, however a major problem with CORBA was soon identified: the ORB of one vendor could not interoperate with the ORBs of other vendors. This led to the design of the interoperability protocol, IIOP, and the current version of the CORBA specification, CORBA 2.0.

The main work of the OMG is, thus, to identify and develop specifications which are then left to CORBA vendors to implement. The development of specifications has a long life-cycle. First, a need or service useful to CORBA's domain is identified (for instance, transaction processing). Second, proposals for the interface to the identified service are submitted by OMG members. Third, these proposals are evaluated and refined by an OMG committee. Often the best features of competing proposals are combined. Finally, the specification is voted upon and, if approved, released as part of the CORBA standard. Note: this does not imply that the service is then immediately available to CORBA users. On the contrary, only the interface to the service has been standardized. The onus is then upon CORBA vendors to provide implementations of the defined service so that CORBA developers can make use of the provided features.

In addition to the core CORBA specification, the OMG produces two other sets of specifications: the Common Facilities and the Common Object Services. The Common Facilities are a set of vertical and horizontal frameworks (in the business sense) designed to enable enterprise computing, also known as business objects. The Common Object Services address domains such as naming, transactions, security, time, queries, persistence, and more. For additional information on the development and nature of CORBA specifications, see the references.

CORBA Basics

CORBA, in a nutshell, enables the creation of distributed object architectures. CORBA provides the Interface Definition Language (IDL) as a mechanism for specifying the interface to an object (although its more appropriate to think of this object as a service or component). If a developer desires only to make use of a service, the IDL specification is the only information required. The specification is compiled by an IDL processor that creates a stub which is linked into the client. This stub class hides from the client all the details required to connect to the object that implements the service. These details include locating the (possibly) remote object, establishing a connection, marshalling language specific parameters, and retrieving the results of an operation. Alternatively, the client can make use of CORBA's interface repository to dynamically invoke a service on a remote object without the use of the stub file. For this situation, the developer again uses the information contained within the IDL specification to create the dynamic invocation. The tradeoff between the two approaches is size-vs-speed. The stub approach is faster but increases the size of the client since it has to be incorporated into the client. The dynamic invocation approach avoids having to link a file into the client but its performance in invoking a request is slower. (This is because a client has to spend time creating a request and then invoking it whereas with the stub approach the request is created statically and the client simply skips to the invocation step.

The IDL compiler also generates a skeleton file that is used to connect the implementation of a service into CORBA's distributed object architecture. A client developer can safely ignore this file; the developer of the component uses it as a starting point for the component. Typically, since CORBA's target programming languages are object-oriented, the skeleton file is a base class from which an implementation of the service inherits the functionality required of a CORBA server. For instance, the skeleton class contains the code which registers the implementation with CORBA's run-time environment, marshalls parameters, receives requests from and returns results to connected clients. A developer of service then simply has to implement the operations defined in the IDL specification and CORBA takes care of the time-consuming low-level details of writing a server.

CORBA Run-time

The next piece of the CORBA puzzle is the run-time environment for CORBA's distributed object infrastructure. The key architectural element is the Object Request Broker (ORB). A CORBA ORB is a federated set of services that handle a variety of run-time activities. These activities include, locating (possibly) remote objects to provide services to clients and providing access to the interfaces stored in the interface repository (used to enable dynamic invocation of services). With respect to the former activity, if a service is not currently running, the ORB may automatically invoke certain types of servers to handle a client's requests. The basic CORBA architecture is shown below:

The ORB receives requests from clients, either statically via the stubs or dynamically via the Interface Repository (not shown), and routes them to a server that can handle the requests. The server's response is routed back in a similar way. Both clients and servers may make requests on the ORB's interface directly in order to register themselves with the ORB or to retrieve a handle to a remote object, for example.

A nice feature of this architecture is that it makes no assumptions about the location of the clients with respect to the servers. An invocation request from a client to a server can be transparently scaled from a procedure call occurring within a single operating system process to a remote procedure call across a LAN or WAN. This transparency is possible because of the encapsulation provided by the stub and skeleton files generated by the IDL compiler. Another aspect of this transparency is that the client and server may be talking to completely different ORBs (by possibly different vendors). CORBA's protocol, IIOP, enables this interoperability.

Feedback? Send it to Ken Anderson.
Last Modified: 12/11/97; 1:49:53 PM PST