In the examples we’ve seen so far, we’ve always assumed
that the Java interfaces for the remote objects are available at
compile time. But what happens if they aren’t? You might get a
reference to a CORBA
Object from a
Naming Service, for example, and not know what interface that object
implements or (more likely) not have that Java interface in the client
JVM. We mentioned earlier that you can use an
org.omg.CORBA.Object reference directly to
make requests and exchange data with its remote object—now we’ll
briefly look at how the Dynamic Invocation Interface (DII) makes that
The CORBA standard actually defines two complementary APIs for this purpose. The DII is used by a CORBA client to make remote method requests of a server object, while the DSI can be used by a server-side skeleton to forward method invocations to its server implementation object when it doesn’t have the actual servant interface available. Both of these APIs perform the same essential function: providing a dynamic interface to an object whose interface is not known at compile time.
The DII and DSI may seem like sidebar topics in the CORBA world, but in reality they are at the heart of CORBA and how it works. When we generate Java stubs and skeletons from IDL interfaces, the generated code uses the DII and DSI to execute remote method calls. The details of how this is done are shielded from you, the developer, by the Java interface you use to interact with ...