## Table of Contents

- Current Status
- Known Issues
- Ongoing work
- Future Work
- Completed Work

# 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:

- Fully compliant with OMG 3.0 spec.

- Fully compatible with CorbaScript.

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, 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.
  tao_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.