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 from 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++, Java or Tcl/Tk, 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, the Dynamic Invocation Interface (DII) and the Dynamic Skeleton Interface (DSI) allows objects to be created without prior knowledge of the IDL interface. Requests and responses between objects are delivered in a standard format defined by the Internet Inter-ORB Protocol (IIOP). 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 adapter, which serves as a mediator between an object's implementation, the servant, and its ORB, thereby decoupling user code from ORB processing. The Portable Object Adapter (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 2: The CORBA client-server architecture

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