CORBA::ORB::resolve_initial_references
for non-locality
constrained objects. The service also introduces the
iioploc
and iiopname
IOR formats, which can
be used to bootstrap services not available at ORB installation time.
This document presents an overview of TAO's INS implementation and addresses common questions.
resolve_initial_references
work ?
The following is the order that resolve_initial_references
locates a service:
IOR
, iiop
,
or iioploc
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 environment variables prior to using multicast to obtain the appropriate port number or IOR.
The following diagram illustrates the order in which these various components interact.
-ORBInitRef [ObjectID]=[ObjectURL]
Examples of use are:
-ORBInitRef NameService=IOR:0002342344AB345
...
-ORBInitRef MyServiceID=iioploc://tango.cs.wustl.edu:87777/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
.
-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
iioploc://tango.cs.wustl.edu:89899,merengue.cs.wustl.edu:99990
A call to resolve_initial_references ("NameService")
with this
argument results in a new multiple profile URL equivalent to the following:
iioploc://tango.cs.wustl.edu:89899/NameService
iioploc://merengue.cs.wustl.edu:99990/NameService
The URL is passed to CORBA::ORB::string_to_object
to obtain the
initial reference for the service.
CORBA::ORB::string_to_object
now understands the iioploc://
format IORs. These are user-friendly multiple end-point IORs. For
example -
iioploc:1.0//tango.cs.wustl.edu:99999/SimpleKey,
merengue.cs.wustl.edu:99990/SimpleKey
Each of the end-points is converted into an IIOP 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 IIOP 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.
Last modified Tue Apr 20 14:47:21 CDT 1999