Interface Repository
The Interface Repository provides run-time information about IDL
interfaces. Using this information, it is possible for a program to
encounter an object whose interface was not known when the program was
compiled, yet, be able to determine what operations are valid on the
object and invoke requests using the DII.
tao_ifr Guide - Guide to the usage of, and
command line options for, tao_ifr, the interface repository loader.
-
Fully compliant with OMG 3.0 spec.
-
Fully compatible with CorbaScript.
- If, while processing an IDL file, tao_ifr discovers that the
interface repository id of some declaration in that file already
exists in the repository, the reason may be one of the following: (1)
the existing entry is for a different type, and so there is a name
clash with some repository entry which came from another IDL file; (2)
both entries are for an interface declaration, in which case the new
entry may be (a) a full definition of a forward declaration from the
other IDl file or (b) there is a name clash. If the case is (2), then
tao_ifr has no way of telling whether it has an instance of (a) or
(b). We have chosen to follow the path taken by other ORB vendors -
when tao_ifr comes across this situation, it will replace the old
repository entry with the new one.
- With the chosen design, calling move() on a Contained IR object
will invalidate the object reference, since the object ID is based on
the path to the object in the database. This is not expected to be a
serious problem in the forthcoming implementation of automatic IFR
administration, but users should be aware of this, if they attempt to
write their own IFR administration code.
- Add support for recursive structs and unions to the IFR, and for
their typecodes to the TypeCodeFactory.
- Add capability to resize the hash maps that provide low-level
storage for the IFR, when the hash map resize feature is added to
ACE.
- Add pluggability for commonly used OTS databases.
- The Interface Repository Service has been added to TAO, in
ACE_wrappers/TAO/orbsvcs/IFR_Service. The implementation follows the
expanded IDL found in CORBA Components vol. III. The database used to
store IR objects is an ACE tool called ACE_Configuration, written by
Chris Hafey. This class
represents its contents to the user as a tree of hash maps. By
specifying a disk file to read from at startup, the storage may be
made persistent. There is also an option to use a win32 registry to
store the data, although persistence is not available with this
option.
- Several methods have been added to class TypeCodeFactory,
including create_exception_tc, create_alias_tc, create_native_tc,
create_wstring_tc, create_value_box_tc, and create_union_tc. Union
typecodes with both multiple and default case labels have been
tested.
- Test code for the IFR service has been added in the directory
ACE_wrappers/TAO/orbsvcs/tests/InterfaceRepo/IFR_Test.
- Code to support multicast discovery of the Interface Repository
IOR has been added to TAO. Testing has been done using loopback on NT,
loopback on Solaris, and remotely between these two platforms in both
directions.
- Read/write locking option added to IFR service. This option should
be used if the IFR service is started using a service config file that
chooses the thread-per-request threading model.
- A test of the persistence option for the IFR added in the
directory
ACE_wrappers/TAO/orbsvcs/tests/InterfaceRepo/Persistence_Test.
- Executable to add or subtract the contents of an IDL file to/from
the IFR, has been added. This executable uses the TAO IDL compiler
front end library, with a new back end library and top level
executable. An application-style test has also been added wherein a
server is started, the IFR started, the contents of the IDL file added
to the IFR, a client started, which discovers information about a
desired operation by searching the IFR, and a DII request constructed
from this information.
- The TypeCodeFactory has been moved from the IFR_Service directory
to its own directory under TAO/tao, taking its place alongside the
other satellite libraries that have been created recently.
- IFR has been made compliant with the CORBA 2.4 version of
Interface.idl. Two new IFR object classes have been added,
AbstractInterfaceDef and LocalInterfaceDef. Some data structures have
changed, as well as the signature of some operations.
- The create_*_tc functions have been replaced in CORBA::ORB (as
part of the CORBA 2.x IFR compliance). These functions call the
corresponding TypeCodeFactory functions. The methods are also hooks,
so that the TypeCodeFactory does not have to be built and linked if an
application does not intend to call those functions. If it does,
however, the application should have #include
"tao/TypeCodeFactory_Adapter_Impl.h" or something similar in
it somewhere, and also link to the TAO_TypeCodeFactory library. This
will automatically load the library if it has been compiled. Please
see the example in ACE_ROOT/TAO/examples/TypeCode_Creation.
- The CORBA::Object::_get_interface() method has been implemented.
This method will resolve the IFR of the target object (whether local
or remote), and return the InterfaceDef associated with that object,
if it is found in the repository. The test in
orbsvcs/tests/InterfaceRepo/Application_Test has been modified to use
_get_interface().
- The executable tao_ifr now handles -ORB options and multiple IDL
files in the command line. The option
-ORBInitRef InterfaceRepository=file://[filename]
can now be used instead of relying on IP multicast to resolve the
IFR service.
- The executable tao_ifr now works with the Interoperable Naming Service.
IFR_Service -ORBEndpoint iiop://[hostname]:[port]
tao_ifr -ORBInitRef
InterfaceRepository=corbaloc:iiop:[hostname]:[port]/InterfaceRepository
[idl file]
- A command line option -Si has been added to tao_ifr which
suppresses processing of included IDL files. The default is to process
them.
- tao_ifr can now process multiple IDL files per execution portably
on all supported platforms. File names and command line options may
occur in any order on the command line.
- Underlying mechanism of access to the IFR has been changed from servant
locator (where a servant is created and destroyed for each access invocation)
to default servant (where persistent servants and their associated POAs are
created at IFR startup and destroyed at shutdown).
- IFR now supports valuetypes, components, homes and eventtypes. A test
for this support has been added in TAO/orbsvcs/tests/InterfaceRepo/IDL3_Test.

[top]