TAO Interoperable Naming Service

This document presents an overview of how the above mentioned features are implemented in TAO and addresses some common questions.

How does resolve_initial_references work ?

The following is the order of mechanisms checked by resolve_initial_references for locating a service:

1. ORBInitRef
   
2. ORBDefaultInitRef
   
3. ORB Default Settings
   
4. Multicast to Service

The following diagram illustrates the order in which these various components interact.

ORB Parameters Used for Configuration

-ORBInitRef : The ORB initial reference argument allows specification of an arbitrary object reference for an initial service. The format is :

-ORBInitRef [ObjectID]=[ObjectURL]

Examples of use are:

-ORBInitRef NameService=IOR:0002342344AB345 ...
-ORBInitRef MyServiceID=corbaloc:iiop:tango.cs.wustl.edu:8777/myService

This mechanism allows an ORB to be configured with new initial service Object IDs that were not defined when the ORB was installed. The ObjectURL can be any of the URL schemes supported by CORBA::ORB::string_to_object.

-ORBDefaultInitRef : The ORB default initial reference argument assists in resolution of initial references not explicitly specified with -ORBInitRef. -ORBDefaultInitRef requires a URL that, after appending a slash '/' and a stringified object key, forms a new URL to identify an initial object reference.

For example:

-ORBDefaultInitRef corbaloc:iiop:tango.cs.wustl.edu:8989,iiop:merengue.cs.wustl.edu:9999

A call to resolve_initial_references ("NameService") with this argument results in a new multiple profile URL equivalent to the following:

corbaloc::tango.cs.wustl.edu:8989/NameService
corbaloc::merengue.cs.wustl.edu:9999/NameService

The URL is passed to CORBA::ORB::string_to_object to obtain the initial reference for the service.

corbaloc: IOR format

corbaloc:iiop:tango.cs.wustl.edu:9999,iiop:merengue.cs.wustl.edu:9999/SimpleKey

Each of the endpoints can use any transport protocols ex: iiop, rir. The corbaloc:rir URL is defined to allow access to the ORB's configured initial references through an URL. Each of the end-points is converted into a Profile. These profiles are used to construct the Multiple Profile Object. This object is then used to construct the Object Reference.

The object references constructed using this format have a 'SimpleKey' in the Object Key field of the IOR. The server side ORB intercepts the incoming request, recognizes the Simple Key and looks up a table to get the complete IOR. It then raises a LOCATION_FORWARD or an OBJECT_NOT_EXIST exception to forward/fail the request depending on if a mapping for the given simple key exists.

All default TAO Object keys are preceded by a special sequence of octets ^t^a^o/0. This is taken care of by the POA when it generates the Object key for the IOR. The sequence is useful for the ORB to distinguish a simple key from the usual TAO object key.

The corbaloc::iiop URL also supports the IPv6 decimal address for the host field using the same format as for IIOP endpoint definitions:

corbaloc:iiop:1.2@[01ef::1]:123/KeyName

TAO only supports IPv6 endpoints in GIOP/IIOP >= 1.2. Since the CORBA spec requires (and such is implemented in TAO) that by default when no version is specified the version will be 1.0 the version has been explicitly set or not the result is that for corbalocs the version needs to be explicitly set.
If not set the corbaloc parser will report an error for encountering an unresolvable hostname.

corbaloc: server setup and the IORTable

The key name used in a corbaloc string may be a stringified object ID associated with some POA, or it might be a human-readable hint to be used to look up the fully qualified object reference.

Stringified ObjectIds are most easily generated by using the -ORBObjRefStyle url command line option. However, these are quite cumbersome to work with For example:

corbaloc:iiop:[email protected]:32948/%14%01%0f%00RST%a5B%a5Eb%c2%04%00%00%00%00%00%01%00%00%00%01%00%00%00

The advantage to using such strings is that server applications need no modifications in order to use such IORs. The disadvantage is that there is no way to attach tagged components to profiles presented as corbaloc strings.

Server applications can get around both of the problem of the unwieldy stringified object ID and the lack of tagged components by using the IOR_Table service. The IORTable service is used inside server applications to associate object key strings with full IORs.

Programs wishing to use the IOR Table must do the following.

• include the header.

  #include "tao/IORTable/IORTable.h"

• get a reference to the table.

     CORBA::Object_var table_object =
          orb->resolve_initial_references ("IORTable");
  
     IORTable::Table_var adapter =
          IORTable::Table::_narrow (table_object.in ());
  

• bind object references into the table. IORs are bound as strings.

     CORBA::String_var ior = orb->object_to_string(myobjref.in());
     adapter->bind ("MyObj", ior.in());