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.