background image
Bionic Buffalo Tech Note #23: The France IDL Compiler: C Language Mapping
Remote implementation. When none of the above situations apply, then the method
implementation is not directly addressable in the address space of the application. In this
situation, the arguments must be marshalled, a message sent to the implementation, a
reply message received, and returned arguments unmarshalled. Although this is called
“remote”, the situation also applies when the implementation is found in a different
process on the same machine. (Note that, on the same machine, some shortcuts may be
taken in marshalling arguments.) To effect this, the stub calls a function
tbt_stub_call_remote()
, provided by the 
ORB
 implementation. The details of the
ORB
's implementation of this function may vary depending on the 
ORB
.
A function's stub will determine which of the above situations applies, then take the steps necessary to
invoke the appropriate method implementation. In case of error (such as an invocation on a nonexistent
object), the stub will raise an appropriate exception.
An ORB with a dynamic invocation interface or dynamic skeleton interface must be prepared to
marshal and unmarshal arguments not only over the wire, but also onto or off from the stack. (Most
architectures pass parameters to functions on the stack.) When all interfaces are known at compile
time, however, the stack manipulation can be left to the stubs and skeletons. In the case of the stub,
before calling the generic 
tbt_stub_call_remote()
 remote function, the stub builds an array of
argument addresses, so the 
ORB
 developer need not be concerned with the parameter passing
mechanism. 
On the other end, when arguments must be unmarshalled from the wire and passed to the method, an
analogue of the stub is required, which this compiler generates and names (for example)
vut_call_intf2_oper3()
 for operation 
oper3
 on interface 
intf2
. These “call” functions
take an array of argument addresses and perform an ordinary C function call. The call functions are
highly portable. No specialized knowledge about stack structure or other parameter passing
mechanisms is required.
Servant Data Structures
For each interface defined in IDL, the compiler produces the 
POA
 servant data structures required by
the specification. For each operation, it produces the source code for a method which returns a
NO_IMPLEMENT
 exception. The generated servant data structures reference the generated methods, so
any application using the generated structures without modification will receive 
NO_IMPLEMENT
exceptions for every operation. The user can modify the data structures as needed to substitute real
implementations for the generated methods. To create a real method, the user can start with the
generated method as a model. It is recommended that modified servant data structures and methods use
modified names, so there will be no conflict or ambiguity when linking with generated code.
The data structures are named as described in the specification. For an operation 
oper3
 on interface
i
ntf2
 (for example), the generated method is named 
vut_meth_intf2_oper3()
Page 5 of 6