CORBA Basics

Related Sites

* CORBA object: A "virtual" entity capable of being located by an ORB and having client requests delivered to it. A CORBA object is identified, located, and addressed by its object reference. Within the context of a request invocation, the CORBA object to which the request is sent is called the "target object."
[This is like a pure abstract class in C++, or an interface in Java -YS]

* Servant: A programming language entity that exists in the context of a server and implements a CORBA object. In non-OO languages like C and COBOL, a servant is implemented as a collection of functions that manipulate data (e.g., an instance of a struct or record) that represent the state of a CORBA object. In OO languages like C++ and Java, servants are object instances of a particular class.

[...]

The relationship between a CORBA object and a servant is very much like the relationship between virtual memory and physical memory in an operating system. Just as virtual address space does not actually exist, neither does a CORBA object. A virtual memory location can be read and written by a computer program because of the work performed by the computer's memory management unit (MMU). The MMU maps virtual memory addresses into physical memory addresses and ensures that each valid virtual memory address is mapped to a physical memory storage location. Similarly, the ORB and the OA cooperate to allow client applications to invoke requests on CORBA objects and ensure that each valid CORBA object is mapped to a servant. In addition, the ORB and the OA cooperate to transparently locate and invoke the proper servants given the addressing information stored in CORBA object references.

* Skeleton: A programming language entity that connects a servant to an OA, allowing the OA to dispatch requests to the servant. In C, a skeleton is a collection of pointers to servant-specific functions. In C++, a skeleton is a base class from which the servant class derives. For static request invocation, skeletons are typically generated automatically by an IDL compiler [IDL is Interface Definition Language - the language used to define CORBA objects -YS]. In addition, CORBA supports the Dynamic Skeleton Interface (DSI), which enables a server to handle requests for objects that have no static skeletons available.

* Object Id: A user- or system-specified identifier used to "name" an object within the scope of its OA. Object Ids are not guaranteed to be globally unique, nor are they necessarily unique within a single server process. The only constraint is that each is unique within the OA where it is created or registered.

* Activation: The act of starting an existing CORBA object to allow it to service requests. Since servants ultimately perform client requests, activation requires that the CORBA object be associated with a suitable servant. Note that activation does not imply CORBA object creation since a CORBA object can't be activated if it does not exist already. Activation may, however, cause the creation of the servant.

This discussion of activation may beg the question of how CORBA objects are created. Unlike C++ classes, IDL interfaces do not have a notion of constructors or any other special object creation functions. From a client perspective, CORBA objects are often created by invoking normal CORBA operations on factory objects. From the server perspective, the servants for factory objects are implemented such that they invoke operations on the OA in order to associate servants with the CORBA objects they create, as well as to create object references for those new objects. In addition, factory operations activate the new CORBA object as well.

* Deactivation: The act of shutting down an active CORBA object. Obviously, deactivation is the opposite of activation. Deactivation requires the destruction of the association between a CORBA object and its servant. Note that deactivation does not imply CORBA object destruction. After deactivation, a CORBA object can be reactivated to receive more requests. Deactivation may, however, result in the destruction of the servant.

* Incarnation: The dictionary defines this word as "the act of giving bodily form or substance to." In the general context of CORBA objects and servants, incarnation is the act of associating a servant with a CORBA object so that it may service requests. In other words, incarnation provides a servant "body" for the virtual CORBA object.

* Etherealization: The opposite of incarnation, this is the act of destroying the association between a CORBA object and its servant. Etherealization takes away the "body" that was associated with the CORBA object at the point of incarnation. After etherealization, the CORBA object still exists as a virtual entity, but it has no associated body to carry out requests for it.

* Active Object Map: A table maintained by an object adapter that maps its active CORBA objects to their associated servants. Active CORBA objects are named in the map via Object Ids. [...]

Much of the terminology introduced here is concerned with the lifetimes of entities in a CORBA system. Perhaps the easiest way to remember the distinction between servants and CORBA objects is that a single CORBA object may be represented by one or more servants over its lifetime. Likewise, a servant may represent one or more CORBA objects simultaneously. Activation and deactivation refer only to CORBA objects, while the terms incarnation and etherealization refer to servants. In fact, the latter two terms were introduced to allow servant lifetimes to be discussed separately from the lifetimes of CORBA objects.

The complete article: Object Adapters: Concepts and Terminology

Douglas Schmidt's CORBA page

CORBA FAQ