CORBA, the Common Object Request Broker, provides integration of object systems within a client/server framework. Clients issue requests for services on objects and the server performs the requested service. The CORBA server is termed the "object implementation". The clients are isolated from the object implementation through commonly defined interfaces which specify the makeup and operations associated with each object and how the operations on the object are provided. Clients seamlessly access the object implementation wherever that object implementation may reside, i.e., in a library on the same host as the client, in another process on the same host as the client, or on a different host from the client where the two hosts are connected by a network.
IDL is the language used for defining interfaces. IDL is programming language independent. When IDL is compiled, the output is programming language source code. Using IDL, the programmer describes the interfaces to the objects. The IDL compiler then takes the descriptions and outputs language in the target language. This code is a skeleton which the programmer then fills in. CORBA provides the Dynamic Invocation Interface which allows applications to generate requests at run-time. Target Language bindings are provided for C, C++, Ada and SmallTalk. The interfaces and methods of the IDL are mapped into programming constructs of the target language. For example, when IDL is mapped into C++, interfaces are mapped into classes and methods are mapped into functions, which perform the services of the interface. IDL does not specify how an interface is implemented. IDL does provide detailed information about the operations permitted on each object, the arguments expected, what is returned, and what happens when errors occur.
Running an IDL script containing an interface definition through an IDL compiler generates the code for the client stubs and the implementation skeleton. Every possible operation on an object defined in the IDL generates a client stub. The client stubs bind the client to the object, i.e. translate between local and standard data representations, and marshal the method call parameters to and from the object. The implementation skeleton marshals the method call parameters to and from the client. The CORBA components and flow of information is shown in figure 1.
CORBA includes
These standard services are used by clients and object implementations when interacting with the CORBA environment. Examples of standard services include the Interface Repository which permits applications to get information about objects and their methods and Dynamic Invocation which permits applications to make requests to object implementations without having to be recompiled.
CORBA is specified in three documents available from the Object Management Group (OMG): The Common Object Request Broker: Architecture and Specification (CORBA) [CORBASPEC], CORBAservices, and CORBAfacilities. The CORBA specification includes the object model, the semantics of the ORB, the IDL, the language mappings, interoperability, and basic object services. The CORBAservices specification includes additional services useful for realizing and maintaining objects within a distributed computing environment. These services include naming, events, lifecycle, persistence, transactions, concurrency, externalization, and relationships. The CORBAfacilities specification includes both higher level services applicable across all application domains and higher level services targeted to specific application domains, such as manufacturing or healthcare.
As new capabilities are developed, they are added to these documents. Currently under development in the OMG are the following specifications:
At a minimum, a CORBA implementation includes the ORB, the IDL, the standard services in the CORBA specification, and one language mapping. Optionally, a CORBA implementation may include additional language mappings, Interoperability, and additional services from the CORBAservices specification. Note that all of the components of a CORBA Implementation need not come from a single producer. In particular, services from the CORBAservices specification may come from a producer different from the one that provides the ORB.
CORBA can be viewed as the technological successor to Remote Procedure Calls (RPC). While CORBA provides a means for implementing applications using the client/server paradigm, CORBA has the following capabilities not found in RPCs:
The purpose of the ORB is to direct object service requests from the client to the server and return server output values back to the client. The client and object implementation can exist in the same process, on different processes on the same or different hosts on the same or different networks. The ORB, based on the availability of the object implementation to the client, facilitates the transfer of object service requests from the client to the server and the results back to the client. These ORB facilities: transparency of object location, activation, and communication, are completely transparent to the client.
Because CORBA supports various types and styles of object implementations, the details for supporting specialized object implementations must be handled by the host of the object implementation requiring these objects. The OA (Object Adapter) provides an interface for this purpose. It assists the ORB with providing services such as activation, deactivation, object creation, and object reference management, such as generation and interpretation of object references and marshaling. A CORBA implementation may have many OAs. Each object implementation determines the OA it will use. CORBA expects each ORB to provide a general OA, the BOA (Basic Object Adapter). The BOA is intended to support objects implemented as separate programs. It is expected that most object implementations can work with the BOA.
The client operates on an object by issuing requests to the object. From the client's viewpoint, issuing a request is similar to a method invocation in a conventional C++ program. Most of the work is done by the client stubs and implementation skeleton generated by the IDL compiler. The steps associated with processing a client request, assuming the object implementation has registered its services with the ORB, are:
The object reference, which is opaque, identifies and locates a particular object. A client of an object has access to the object reference for that object. An object implementation may also be a client of other objects. To facilitate an efficient means for obtaining the object reference, the ORB services can make the opaque object reference persistent by converting it to a string. This string can then be stored and later retrieved and changed back to its object reference.
CORBA provides for interoperability between client and object implementations when the client and object implementations are located on different hosts connected by a network. This capability has two dimensions. The ORB provides the means for a client application to locate the object implementation even if the object implementation migrates to another host. The ORB also provides the means by which the client application can transmit a request to an object implementation and receive the response from that object implementation.
There are two protocols which provide interoperability in CORBA: the General Inter-ORB Protocol (GIOP) and the DCE Common Inter-ORB Protocol (DCE-CIOP). Support for the GIOP is mandatory for all implementations. The GIOP specifies protocols that are supported by the TCP/IP protocol suite. The DCE-CIOP is optional and is designed to work within an OSF DCE environment. In that environment, applications may make use of DCE security and management services. A CORBA implementation which provides the optional DCE-CIOP must also provide either the GIOP in addition to the DCE-CIOP or a bridge (CORBA terminology for gateway) to implementations that provide the GIOP. It is by means of either direct GIOP support by the DCE-CIOP implementation or this bridge that object systems within a DCE-CIOP environment can interoperate with object systems in a GIOP environment.