The CORBA Architecture

The most fundamental component of CORBA is the Object Request Broker (ORB) whose task is to facilitate communication between objects. Given an Interoperable Object Reference (IOR), the ORB is able to locate target objects and transmit data to and fro remote method invocations. The interface to a CORBA object is specified using the CORBA Interface Definition Language (IDL). An IDL compiler translates the IDL definition into an application programming language, such as C++ or Java, generating IDL stubs and skeletons that respectively provide the framework for client-side and server-side proxy code. Compilation of applications incorporating IDL stubs provides a strongly-typed Static Invocation Interface (SII). Conversely, a more flexible communication mechanism can be established through the use of the Dynamic Invocation Interface (DII) and the Dynamic Skeleton Interface (DSI) allowing objects to be created without prior knowledge of the IDL interface. In such cases, a description of the interface is retrieved at runtime from an Interface Repository (IFR), a database containing the pertinent meta-data. Requests and responses between objects are delivered in a standard format defined by the Internet Inter-ORB Protocol (IIOP), a communications protocol which adheres to the CORBA General Inter-ORB Protocol (GIOP) specification and, as such, acts as the base for CORBA interoperability on the internet. Requests are marshaled in a platform independent format, by the client stub (or in the DII), and unmarshaled on the server-side into a platform specific format by the IDL skeleton (or in the DSI) and the object adaptor, which serves as a mediator between an object's implementation, the servant, and its ORB, thereby decoupling user code from ORB processing. In its mandatory version, the Portable Object Adaptor (POA) provides CORBA objects with a common set of methods for accessing ORB functions, ranging from user authentication to object activation and object persistence. It's most basic task, however, is to create object references and to dispatch ORB requests aimed at target objects to their respective servants. The characteristics of the POA are defined at creation time by a set of POA policies. A server can host any number of POAs, each with its own set of policies to govern the processing of requests. Among the more advanced features of the POA is the servant manager which assumes the role of reactivating server objects (servants) as they are required. It also provides a mechanism to save and restore an object's state. This, coupled with the use of the Implementation Repository (IMR), that handles the automated start and restart of servers, realizes object persistency. Requests for server reactivation can, alternatively, be delegated to a single default servant which provides implementations for many objects, thereby increasing the scalability for CORBA servers.

Figure: The CORBA client-server architecture

Fig.  shows the components of the CORBA architectural model. The ORB core is implemented as a runtime library linked into client-server applications.