interface Doc <id 123> { };
| Previous | Table of Contents | Next |
Interface definitions are maintained in the Interface Repository as a set of objects that are accessible through a set of
OMG IDL-specified interface definitions. An interface definition contains a description of the operations it supports, including
the types of the parameters, exceptions it may raise, and context information it may use.
In addition, the interface repository stores constant values, which might be used in other interface and value definitions
or might simply be defined for programmer
convenience and it stores TypeCodes [Section 4.11, “TypeCodes,? on page 4-53],
which are values that describe a type in structural terms.
The Interface Repository uses modules as a way to group interfaces and to navigate through those groups by name. Modules can
contain constants, typedefs, exceptions, interface/ component/home definitions, and other modules. Modules may, for example,
correspond to the organization of OMG IDL definitions. They may also be used to represent organizations defined for administration
or other purposes.
The Interface Repository consists of a set of interface repository objects that represent the information in it. There are
operations that operate on this apparent object structure. It is an implementation’s choice whether these objects exist persistently
or are created when referenced in an operation on the repository. There are also operations that extract information in an
efficient form, obtaining a block of information that describes a whole interface or a whole operation.
An ORB may have access to multiple Interface Repositories. This may occur because
• two ORBs have different requirements for the implementation of the Interface Repository,
• an object implementation (such as an OODB) prefers to provide its own type information, or
• it is desired to have different additional information stored in different repositories.
The use of TypeCodes (Section 4.11, “TypeCodes,? on page 4-53) and repository
identifiers is intended to allow different repositories to keep their information consistent.
As shown in Figure 10-1 on page 10-3, the same interface
Doc is installed in two different repositories, one at SoftCo, Inc., which sells Doc objects, and one at Customer, Inc., which
buys Doc objects from SoftCo. SoftCo sets the repository id for the Doc interface when it defines it. Customer might first
install the interface in its repository in a module where it could be tested before exposing it for general use. Because it
has the same repository id, even though the Doc interface is stored in a different repository and is nested in a different
module, it is known to be the same.
Meanwhile at SoftCo, someone working on a new Doc interface has given it a new repository id 456, which allows the ORBs to
distinguish it from the current product Doc interface.
SoftCo, Inc., Repository Customer, Inc., Repository
module softco { module testfirst {interface Doc <id 123> { module softco {void print();
interface Doc <id 123> { };
void print();};
};};};module newrelease {interface Doc <id 456> {void print();};};
Figure 10-1 Using Repository IDs to establish correspondence between repositories
Not all interfaces will be visible in all repositories. For example, Customer employees cannot see the new release of the
Doc interface. However, widely used interfaces will generally be visible in most repositories.
This Interface Repository specification defines operations for retrieving information from the repository as well as creating
definitions within it. There may be additional ways to insert information into the repository (for example, compiling OMG
IDL definitions, copying objects from one repository to another).
A critical use of the interface repository information is for connecting ORBs together. When an object is passed in a request
from one ORB to another, it may be necessary to create a new object to represent the passed object in the receiving ORB. This
may require locating the interface information in an interface repository in the receiving ORB. By getting the repository
id from a repository in the sending ORB, it is possible to look up the interface in a repository in the receiving ORB. To
succeed, the interface for that object must be installed in both repositories with the same repository id.