| Previous | Table of Contents | Next |
Interface Repositories contain the information necessary to allow programs to determine and manipulate the type information
at run-time. Programs may attempt to access the interface repository at any time by using the get_interface operation on the
object reference. Once information has been installed in the repository, programs, stubs, and objects may depend on it. Updates
to the repository must be done with care to avoid disrupting the environment. A variety of techniques are available to help
do so.
A coherent repository is one whose contents can be expressed as a valid collection of OMG IDL definitions. For example, all
inherited interfaces exist, there are no duplicate operation names or other name collisions, all parameters have known types,
and so forth. As information is added to the repository, it is possible that it may pass through incoherent states. Media
failures or communication errors might also cause it to appear incoherent. In general, such problems cannot be completely
eliminated.
Replication is one technique to increase the availability and performance of a shared database. It is likely that the same
interface information will be stored in multiple repositories in a computing environment. Using repository IDs, the repositories
can establish the identity of the interfaces and other information across the repositories.
Multiple repositories might also be used to insulate production environments from development activity. Developers might be
permitted to make arbitrary updates to their repositories, but administrators may control updates to widely used repositories.
Some repository implementations might permit sharing of information, for example, several developers’ repositories may refer
to parts of a shared repository. Other repository implementations might instead copy the common information. In any case,
the result should be a repository facility that creates the impression of a single, coherent repository.
The interface repository itself cannot make all repositories have coherent information, and it may be possible to enter information
that does not make sense. The repository will report errors that it detects (e.g., defining two attributes with the same name)
but might not report all errors, for example, adding an attribute to a base interface may or may not detect a name conflict
with a derived interface. Despite these limitations, the expectation is that a combination of conventions, administrative
controls, and tools that add information to the repository will work to create a coherent view of the repository information.
Transactions and concurrency control mechanisms defined by the Object Services may be used by some repositories when updating
the repository. Those services are designed so that they can be used without changing the operations that update the repository.
For example, a repository that supports the Transaction Service would inherit the Repository interface, which contains the
update operations, as well as the Transaction interface, which contains the transaction management operations. (For more information
about Object Services, including the Transaction and Concurrency Control Services, refer to the individual CORBA Services
specifications).
Often, rather than change the information, new versions will be created, allowing the old version to continue to be valid.
The new versions will have distinct repository IDs and be completely different types as far as the repository and the ORBs
are concerned. The IR provides storage for version identifiers for named types, but does not specify any additional versioning
mechanism or semantics.