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. 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 which is not reflected in the object's interface.
The Structure of Object Request Broker
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 runtime access to these components(Dynamic Interface Invocation). 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.
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 . 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.
The Object Implementation may choose which Object Adapter to use. This decision is based on what kind of services the Object Implementation requires.
Interface and Implementation Repositories
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.
The object implementation information is provided at installation time and is stored in the Implementation Repository for use during request delivery.
Clients access object-type-specific stubs as library routines in their program. The client program thus sees routines callable in the normal way in its programming language. All implementations will provide a language-specific data type to use to refer to objects, often an opaque pointer. The client then passes that object reference to the stub routines to initiate an invocation. The stubs have access to the object reference representation and interact with the ORB to perform the invocation
An alternative set of library code is available to perform invocations on objects, for example when the object was not defined at compile time. In that case, the client program provides additional information to name the type of the object and the method being invoked, and performs a sequence of calls to specify the parameters and initiate the invocation.
Structure of an Object Implementation
The object implementation interacts with the ORB in a variety of ways to establish its identity, to create new objects, and to obtain ORB-dependent services. It primarily does this via access to an Object Adapter, which provides an interface to ORB services that is convenient for a particular style of object implementation.
When an invocation occurs, the ORB Core, object adapter, and skeleton arrange that a call is made to the appropriate method of the implementation. A parameter to that method specifies the object being invoked, which the method can use to locate the data for the object. Additional parameters are supplied according to the skeleton definition. When the method is complete, it returns, causing output parameters or exception results to be transmitted back to the client.
When a new object is created, the ORB may be notified so that the it knows where to find the implementation for that object. Usually, the implementation also registers itself as implementing objects of a particular interface, and specifies how to start up the implementation if it is not already running.
Architecture of a distributed
CORBA application.
Inter-ORB Protocols
The General Inter-ORB Protocol (GIOP) is a high-level standard protocol
for communication between ORBs. Because GIOP is a generalized protocol,
it is not used directly; instead, it is specialized by a particular protocol
that would then be used directly.CORBA specification is neutral with respect
to network protocols. .
GIOP-based protocols exist for TCP/IP and DCE Additionally, vendors can (and do) define and use proprietary protocols for communication between CORBA components.
The Internet Inter-ORB Protocol (IIOP) is a specialization of the GIOP. IIOP is the standard protocol for communication between ORBs on TCP/IP based networks. An ORB must support IIOP (but can support other additional protocols) in order to be considered CORBA 2.0-compliant.
Essentially, CORBA applications are built on top of GIOP-derived protocols
such as IIOP. These protocols, in turn, rest on top of TCP/IP, DCE, or
whatever underlying transport protocol the network uses. CORBA applications
aren't limited to using only one of these protocols; an application architecture
can be designed to use a bridge that would interconnect, for instance,
DCE-based application components with IIOP-based ones. You can see, then,
that rather than supplant network transport protocols, the CORBA architecture
creates another layer--the inter-ORB protocol layer--which uses the underlying
transport layer as its foundation. This, too, is a key to interoperability
between CORBA applications, as CORBA does not dictate the use of a particular
network transport protocol.
[Index]
[Introduction]
[Architecture]
[Applications]
[Alternatives]
[Tools]
[Links]