Previous | Table of Contents | Next |
Figure 2-1 shows a request being sent by a client to an object implementation. The
Client is the entity that wishes to perform an operation on the object and the Object Implementation is the code and data
that actually implements the object.
July 2002 Common Object Request Broker Architecture (CORBA), v3.0 2-1
Figure 2-1 A Request Being Sent Through the Object Request Broker
The ORB is responsible for all of the mechanisms required to find the object implementation for the request, to prepare the
object implementation to receive the request, and to communicate the data making up the request. The interface the client
sees is completely independent of where the object is located, what programming language it is implemented in, or any other
aspect that is not reflected in the object’s interface.
Figure 2-2 on page 2-3 shows the structure of an individual Object Request Broker
(ORB). The interfaces to the ORB are shown by striped boxes, and the arrows indicate whether the ORB is called or performs
an up-call across the interface.
Interface identical for all ORB implementationsThere may be multiple object adaptersThere are stubs and a skeleton for each object typeORB-dependent interfaceFigure 2-2 |
Up-call interface |
||||
Normal call interface | |||||
The Structure of Object Request Interfaces |
To make a request, the Client can use the Dynamic Invocation interface (the same interface independent of the target object’s
interface) or an OMG IDL stub (the specific stub depending on the interface of the target object). The Client can also directly
interact with the ORB for some functions.
The Object Implementation receives a request as an up-call either through the OMG IDL generated skeleton or through a dynamic
skeleton. The Object Implementation may call the Object Adapter and the ORB while processing a request or at other times.
Definitions of the interfaces to objects can be defined in two ways. Interfaces can be defined statically in an interface
definition language, called the OMG Interface Definition Language (OMG IDL). This language defines the types of objects according
to the operations that may be performed on them and the parameters to those operations. Alternatively, or in addition, interfaces
can be added to an Interface Repository service; this service represents the components of an interface as objects, permitting
run-time access to these components. In any ORB implementation, the Interface Definition Language (which may be extended beyond
its definition in this document) and the Interface Repository have equivalent expressive power.
The client performs a request by having access to an Object Reference for an object and knowing the type of the object and
the desired operation to be performed. The client initiates the request by calling stub routines that are specific to the
object or by
constructing the request dynamically (see Figure 2-3).
Figure 2-3 A Client Using the Stub or Dynamic Invocation Interface
The dynamic and stub interface for invoking a request satisfy the same request semantics, and the receiver of the message
cannot tell how the request was invoked.
The ORB locates the appropriate implementation code, transmits parameters, and transfers control to the Object Implementation
through an IDL skeleton or a dynamic
skeleton (see Figure 2-4 on page 2-5). Skeletons are specific to the interface and the
object adapter. In performing the request, the object implementation may obtain some services from the ORB through the Object
Adapter. When the request is complete, control and output values are returned to the client.
Interface identical for all ORB implementationsThere may be multiple object adaptersThere are stubs and a skeleton for each object typeORB-dependent interfaceFigure 2-4 |
Up-call interface |
||||
Normal call interface | |||||
An Object Implementation Receiving a Request |
The Object Implementation may choose which Object Adapter to use. This decision is based on what kind of services the Object
Implementation requires.
Figure 2-5 on page 2-6 shows how interface and implementation information is made
available to clients and object implementations. The interface is defined in OMG IDL and/or in the Interface Repository; the
definition is used to generate the client Stubs and the object implementation Skeletons.
Figure 2-5 Interface and Implementation Repositories
The object implementation information is provided at installation time and is stored in the Implementation Repository for
use during request delivery.