Bionic Buffalo Tech Note #23: The France IDL Compiler: C Language Mapping
tbt_interface_info_T
. This structure contains the information from the IDL, and includes a
table of pointers to the
tbt_operation_info_T
structures for the interface's operations. The
structure is used by the stubs and skeletons to match the operation name to a position in the vector of
entry point vectors specified by the
POA
mapping to C. (The data structures, as defined by the C
mapping in the specification, don't have sufficient information, such as operation names.) For interface
intf2
(for example), the structure is named
vut_intf_intf2
.
Both the
tbt_operation_info_T
and
tbt_interface_info_T
structures are described in
the
tibet
headers.
Operation Stubs
Stubs are created for operations defined in IDL. The code in such stubs routes the request to the correct
method implementation or remote
ORB
, as appropriate.
The first step taken by a stub is to locate the object, based on its reference. This is done by a function
tbt_target_location()
, supplied by the
ORB
implementation. An object and its methods might
be accessible from the calling application in one of several ways.
Intrinsic implementation. The object's method implementation might be directly linked to
the application, using the same calling sequence as seen by the application. In other
words, the application calls the operation directly, bypassing the
ORB
. In this case, the
operation is linked in before the stub, so the stub is neither linked nor called. This
situation is seen most commonly in CORBA pseudo-objects, such as
TypeCode
s. There
can be only one implementation of each operation in this situation, and that
implementation must be local. We need not consider this situation further.
Linked implementation. When there is only one local implementation of an operation, and
the implementation is written for compatibility with the
POA
mapping, then the
implementation can be linked directly to the stub. In this situation, the stub must perform
a little housekeeping as well as substitution of the servant for the object reference as the
first parameter (since the stub and method signatures differ in the first parameter). Then
the stub can call the linked method directly. This mechanism obviates the need to walk
the
POA
servant mapping data structures to locate the method.
Addressable implementation. When more that one servant may be dynamically registered
with the
POA
for a given interface and operation, then the servants are addressable
indirectly through pointers found in the servant mapping data structures. There may be
more than one local implementation for a given interface. The
tbt_target_location()
function must walk the data structures and return a
pointer to the method implementation corresponding to the object reference passed to the
stub. After some housekeeping, the stub can call the method indirectly through the
method pointer.
Page 4 of 6