The CORBA Interoperable Naming
Service (INS) service allows the ORB to be configured
administratively to return object references from
CORBA::ORB::resolve_initial_references
for non-locality
constrained objects. The service also introduces the
corbaloc
and corbaname
IOR formats, which can
be used to bootstrap services not available at ORB installation time.
This document presents an overview of how the above mentioned features are implemented in TAO and addresses some common questions.
The following is the order of mechanisms checked by
resolve_initial_references
for locating a service:
TAO uses the ACE_Hash_Map_Manager to keep track of the ObjectID:IOR
mappings specified on the command-line. The IOR could be in
IOR
, iiop
, or corbaloc
format. If
the ORB fails to resolve the IOR using the command-line parameters or the
default settings, it uses UDP multicast to resolve the service.
The Naming Service process acts as an IIOP Agent to respond with the IOR for the given service name. If the service being resolved is the Naming Service or the Trading Service, TAO checks the appropriate environmentvariables prior to using multicast to obtain the appropriate port number or IOR.
The following diagram illustrates the order in which these various components interact.
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
.
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:
iiop://tango.cs.wustl.edu:8989/NameService
iiop://merengue.cs.wustl.edu:9999/NameService
The URL is passed to CORBA::ORB::string_to_object
to
obtain the initial reference for the service.
The CORBA::ORB::string_to_object
now understands the
corbaloc:
format IORs (previously called iioploc). These are
user-friendly multiple end-point IORs. For example:
corbaloc:iiop:tango.cs.wustl.edu:9999,iiop:merengue.cs.wustl.edu:9999/SimpleKey
Each of the end-points 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.