Table of Contents
Interface Repository
Point of contact: Jeff Parsons
Last Update: October 21, 2003
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.
Current status:
Back to TOC
Known issues:
- 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.
Back to TOC
Ongoing Work:
Back to TOC
Future work:
- 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.
Back to TOC
Completed Work:
- 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.