(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 basically the IDL defined operations on the CORBA object to be invoked, allow program variables to be passed to the operation as inbound parameters, and allow return values or 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 . Developers of client applications which use SII must know the name of the operation, and all parameters/return types prior to program compilation. The actual operation names and parameters/return values are in effect hard coded into the application source code.
[ Top | Bottom | Previous section | Next section ]
[Recently created (3/1999). Click here to go to the next FAQ in the “chain” of recent changes]
Generally speaking, SII is the easiest mechanism which can be used to invoke operations on a CORBA object. All applications which use SII could be implemented with DII. Not all applications which use DII can be implemented with SII. If an application can be developed with SII then it probably should be. This is because developing code with SII requires less code and is much more straight forward. The language compiler can be used to validate types and optimize code. There are certain conditions which make DII a better alternative.
[ Top | Bottom | Previous section | Next section ]
[Recently created (3/1999). Click here to go to the next FAQ in the “chain” of recent changes]
Implementations of the CORBA specification (i.e. a CORBA ORB) support SII in the following way. The ORB will provide an IDL compiler which is specific to that particular ORB product. When a developer compiles their IDL with the ORB vendor’s IDL compiler, stubs and skeletons are created. These stubs and skeletons are static. This is because they do not change. If changes are made to the IDL, the stubs and skeletons must be regenerated by running the IDL compiler again. The IDL compiler generates a stub and skeleton based on the structure of the appropriate IDL interfaces. The stubs and skeletons are statically generated at IDL compilation time. These stubs are then either imported or included into the application which needs access to the CORBA Objects. The stubs and skeletons will have been generated to either directly or indirectly utilize IIOP to communicate. In many cases, the IDL compiler, will generate stubs to utilize Dynamic Invocation Interface to interact with the skeletons. The IDL compiler may also generate skeletons which utilize Dynamic Skeleton Interface to interact with the stubs.
[ Top | Bottom | Previous section | Next section ]
E-mail us