summaryrefslogtreecommitdiff
path: root/TAO/docs/INS.html
blob: b08247c97ecfe4b039139eda5696c6a4e2d9d725 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
  <!-- $Id$ -->
<HTML>

<HEAD>
<TITLE>TAO Interoperable Naming Service</TITLE>

<BODY text = "#000000"
link="#000fff"
vlink="#ff0f0f"
bgcolor="#ffffff">

<HR><P>
<H3>TAO Interoperable Naming Service</H3>

The CORBA <A
HREF="ftp://ftp.omg.org/pub/docs/orbos/98-10-11.pdf">Interoperable
Naming Service</A> (INS) service allows the ORB to be configured
administratively to return object references from
<CODE>CORBA::ORB::resolve_initial_references</CODE> for non-locality
constrained objects.  The service also introduces the
<CODE>iioploc</CODE> and <CODE>iiopname</CODE> IOR formats, which can
be used to bootstrap services not available at ORB installation time.
<P>

This document presents an overview of TAO's INS implementation and
addresses common questions. <P>

<HR align=left width=80% ><P>
<H4>How does <CODE>resolve_initial_references</CODE> work ?</H4><P>

The following is the order that <CODE>resolve_initial_references</CODE>
locates a service: <P>

<OL>
<LI><A HREF="#oir">ORBInitRef</A> <br>
<LI><A HREF="#odir">ORBDefaultInitRef</A> <br>
<LI>ORB Default Settings <br>
<LI>Multicast to Service <p>
</OL>

TAO uses the <A
HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/man/html/ACE_Hash_Map_Manager.html">ACE_Hash_Map_Manager</A>
to keep track of the ObjectID:IOR mappings specified on the
command-line. The IOR could be in <CODE>IOR</CODE>, <CODE>iiop</CODE>,
or <CODE>iioploc</CODE> 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. <P>

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 <A
HREF="Options.html#ev">environment variables</A> prior to using
multicast to obtain the appropriate port number or IOR.<p>

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

<img width=200 height=5
src="http://www.cs.wustl.edu/~schmidt/gifs/space.gif"><img width=723
height=529
src="http://www.cs.wustl.edu/~schmidt/gifs/interop-naming.gif"><p>

<HR align=left width=80% ><P>

<H4>ORB Parameters Used for Configuration</H4>
<A NAME="oir"></A>
<DL>
<DT> <img alt="o" src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif">
<B><FONT COLOR="#000000">-ORBInitRef :</FONT> </B>
The ORB initial reference argument allows specification of an
    arbitrary object reference for an initial service. The format is :
    <p>
    <CODE>-ORBInitRef [ObjectID]=[ObjectURL]</CODE> <p>
    Examples of use are: <p>
    <CODE>-ORBInitRef  NameService=IOR:0002342344AB345</CODE> ...<br>
    <CODE>-ORBInitRef MyServiceID=iioploc://tango.cs.wustl.edu:87777/myService </CODE><p>

    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 <CODE>CORBA::ORB::string_to_object</CODE>.<p>

    <A NAME="odir"></A>
<DT> <img alt="o" src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif"><B><FONT COLOR="#000000">
-ORBDefaultInitRef :</FONT></B></LI>
The ORB default initial reference argument assists in resolution of
    initial references not explicitly specified with
    <CODE>-ORBInitRef</CODE>. <CODE>-ORBDefaultInitRef</CODE> requires a URL that, after
    appending a slash '/' and a stringified object key, forms a new
    URL to identify an initial object reference. <p>
    For example: <P>
    <CODE>-ORBDefaultInitRef
    iioploc://tango.cs.wustl.edu:89899,merengue.cs.wustl.edu:99990</CODE> <p>

    A call to <CODE>resolve_initial_references ("NameService")</CODE> with this
    argument results in a new multiple profile URL equivalent to the following: <P>
    <CODE>iioploc://tango.cs.wustl.edu:89899/NameService</CODE> <br>
    <CODE>iioploc://merengue.cs.wustl.edu:99990/NameService</CODE> <p>
    
    The URL is passed to <CODE>CORBA::ORB::string_to_object</CODE> to obtain the
    initial reference for the service.
</DL>

<HR align=left width=80% ><P>

<H4>iioploc:// IOR format</H4>
The <CODE>CORBA::ORB::string_to_object</CODE> now understands the <CODE>iioploc://</CODE>
format IORs. These are user-friendly multiple end-point IORs. For
example - <p>
 <img width=50 height=5
src="http://www.cs.wustl.edu/~schmidt/gifs/space.gif">iioploc:1.0//tango.cs.wustl.edu:99999/SimpleKey,
merengue.cs.wustl.edu:99990/SimpleKey <p>

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.<p>

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. <p>

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. <p>

<HR align=left width=80% ><P>

<!--<EM>
Visitor #1 since Thu Apr 15 22:33:36 1999

from merengue.cs.wustl.edu

<EM><br> -->
<I> Last modified Tue Apr 20 14:47:21 CDT 1999 </I>


</BODY>
</HTML>