(Part of the CORBA FAQ, Copyright © 1996-99)
[Recently created (3/1999). Click here to go to the next FAQ in the “chain” of recent changes]
The CORBA specification defines two mechanisms for invoking operations on a CORBA Object. Functionaly, the two mechanisms provide the same capabilities. They allow the IDL defined operations on any CORBA object to be invoked, they allow program variables to be passed to the operation as inbound and in/out parameters, and allow return values or out and in/out parameters to be passed from the server to the client. The first mechanism is known as the Static Invocation Interface (SII, the other is known as Dynamic Invocation Interface (DII). Developers of client applications which use DII do not need to know the name of the operation or any of the parameter or return types when writing the program. The developer will utilize the DII mechanism which is part of the CORBA specification to make invocations of operations. DII also provides a facility to set up the parameters and return values of the particular invocation. DII is similiar to Java’s introspection features and RTTI in C++.
[ Top | Bottom | Previous section | Next section ]
[Recently created (3/1999). Click here to go to the next FAQ in the “chain” of recent changes]
The dynamic nature of DII provides certain advantages over SII. The following types of applications would require or benefit from DII:
Applications which utilize DII do not need to include or import stubs generated by an IDL compiler in order to access a service. Applications like object browsers or monitors can access ANY objects without previous (complile time) knowledge of the interface. Using DII is more tedious than coding w/ SII. The DII interfaces must be used to specify the operation and each parameter’s type and value. Type checking must be done by the developer using CORBA defined typecodes.
[ Top | Bottom | Previous section | Next section ]
[Recently created (3/1999). Click here to go to the next FAQ in the “chain” of recent changes]
DII also provides a deferred synchronous invocation. This feature is not part of CORBA 2.0’s SII. Deferred synchronous invocations are submitted without having to wait for a response. This is similiar to a one-way operation except a return values and out parameters are possible, but must be polled for. CORBA 3.0 will support this type of invocation for both static and dynamic modes via the Asynchronous Messaging Service.
[ Top | Bottom | Previous section | Next section ]
E-mail us