SEC . 9.1 CORBA 497
not available to a client . Instead , what it needs is to find out during runtime what the interface to a specific object looks like , and subsequently compose an invocation request for that object . For this purpose , CORBA offers a Dynamic Invocation Interface ( DII ) to clients , which allows them to construct an invocation request at runtime . In essence , the DII provides a generic invoke operation , which takes an object reference , a method identifier , and a list of input values as parameters , and returns its result in a list of output variables provided by the caller .
Object servers are organized in the way we described in Chap . 3 . As shown in Fig . 9-2 , a CORBA system provides an object adapter , which takes care of forwarding incoming requests to the proper object . The actual unmarshaling at the server side is done by means of stubs , called skeletons in CORBA , but it is also possible that the object implementation takes care of unmarshaling . As in the case of clients , server-side stubs can either be statically compiled from IDL specifications , or be available in the form a generic dynamic skeleton . When using a dynamic skeleton , an object will have to provide the proper implementation of the invoke function as offered to the client . We return to object servers below .
Interface and Implementation Repository
To allow the dynamic construction of invocation requests , it is important that a process can find out during runtime what an interface looks like . CORBA offers an interface repository , which stores all interface definitions . In many systems , the interface repository is implemented by means of a separate process offering a standard interface to store and retrieve interface definitions . An interface repository can also be viewed as that part of CORBA that assists in runtime type checking facilities .
Whenever an interface definition is compiled , the IDL compiler assigns a repository identifier to that interface . This repository ID is the basic means to retrieve an interface definition from the repository . The identifier is by default derived from the name of the interface and its methods , implying that no guarantees are given with respect to its uniqueness . If uniqueness is required , the default can be overridden .
Given that all interface definitions stored in an interface repository adhere to IDL syntax , it becomes possible to organize each definition in a standard way . ( In database terminology , this means that the conceptual schema associated with an interface repository is the same for every repository .) As a consequence , the interface repositories in CORBA systems offer the same operations for navigating through interface definitions .
Besides an interface repository , a CORBA system generally offers also an implementation repository . Conceptually , an implementation repository contains all that is needed to implement and activate objects . Because such functionality is intimately related to the ORB itself and the underlying operating system , it is difficult to provide a standard implementation .