Horus Doc || Corba Reference || Corba   Client Server   Stubs C++   Stubs Java   Servant Generator  

Corba architecture

A Corba object is a virtual entity capable of being located by an ORB and having client requests invoked on it. It is virtual in the sense that it does not really exist unless it is made concrete by an implementation written in a programming language.

A request in an invocation of an operation on a Corba object by a client. Requests flow from a client to the target object in the server, and the target object sends the results back if the request requires one.

An object reference is a handle used to identify, locate, and address a Corba object. To clients, object references are opaque entities.

A servant is a programming language entity that implements one or more Corba objects. Servants are said to incarnate Corba objects because they provide bodies, or implementations, for those objects. Servants exist within the context of a server application. In C++, servants are object instances of a particular class.

Corba.gif

Common Object Request Broker Architecture (CORBA)

General request flow:

  1. The client can choose to make requests either using static stubs (generated from the IDL definition, see below) or using the Dynamic Invocation Interface (DII). Either way, the client directs the request into the ORB core linked into its process.
  2. The client ORB core transmits the request to the ORB core linked with the server application.
  3. The server ORB core dispatches the request to the object adapter that created the target object.
  4. The object adapter further dispatches the request to the servant that is implementing the target object. Like the client, the server can choose between static and dynamic dispatching mechanisms for its servants. It can rely on static skeletons generated from the object's IDL definition, or its servants can use the Dynamic Skeleton Interface (DSI).
  5. After the servant carries out the request, it returns its response to the client application.
To invoke operations on a Corba object, a client must know the interface offered by the object. An object's interface is composed of the operations it supports and the types of data that can be passed to and from those operations. The interface is defined in IDL - the Interface Definition Language. IDL is not a programming language, so objects and applications cannot be implemented in IDL. The sole purpose of IDL is to allow object interfaces to be defined in a manner that is independent of any particular programming language.

Language mappings specify how IDL is translated into different programming languages. IDL is translated into stubs and skeletons that are compiled into applications. Compiling stubs and skeletons into an application gives it static knowledge of the programming language type and functions mapped from the IDL descriptions of remote objects. A stub is a client-side function that allows a request invocation to be made via a normal local function call. In C++, a Corba stub is a member function of a class. The local C++ object that supports stubs functions is often called a proxy because it represents the remote target object to the local application. Similarly, a skeleton is a server-side function that allows a request invocation received by a server to be dispatched to the appropriate servant.

In Corba, object adapters serve as the glue between servants and the ORB. As described by the Adapter design pattern, an object adapter is an object that adapts the interface of one object to a different interface expected by a caller. In other words, an object adapter is an interposed object that uses delegation to allow a caller to invoke requests on an object without knowing the object's true interface.

Corba object adapters fulfill three key requirements

  1. They create object references, which allow clients to address objects.
  2. They ensure that each target object is incarnated by a servant.
  3. They take requests dispatched by a server-side ORB and further direct them to the servants incarnating each of the target objects.
The General Inter-ORB Protocol (GIOP) is an abstract protocol that specifies transfer syntax and a standard set of message formats to allow independently developed ORBs to communicate over any connection-oriented transport. The Internet Inter-ORB Protocol (IIOP) specifies how GIOP is implemented over Transmission Control Protocol/Internet Protocol (TCP/IP). In the remainder, we will focus on IIOP.


Go to the next section or return to the index.


Generated on Mon Jan 27 15:20:57 2003 for CorbaReference by doxygen1.2.12 written by Dimitri van Heesch, © 1997-2001