TAO/docs/implrepo/paper.html

   1 <html>
   2
   3 <head>
   4 <meta http-equiv="Content-Type"
   5 content="text/html; charset=iso-8859-1">
   6 <meta name="GENERATOR" content="Microsoft FrontPage Express 2.0">
   7 <title>TAO Implementation Repository</title>
   8 <!--  -->
   9 </head>
  10
  11 <body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
  12 vlink="#CC0000">
  13
  14 <hr>
  15
  16 <h1>TAO Implementation Repository </h1>
  17
  18 <p>Revision 3.05</p>
  19
  20 <hr>
  21
  22 <h2>Table of Contents</h2>
  23
  24 <ul>
  25     <li><a href="#Changes">Recent Changes</a> </li>
  26     <li><a href="#Overview">Overview</a> <ul>
  27             <li><a href="#PersistentandTransientIORs">Persistent
  28                 and Transient IORs</a> </li>
  29             <li><a href="#TheImplementationRepository">The
  30                 Implementation Repository</a> </li>
  31         </ul>
  32     </li>
  33     <li><a href="#TAOsImplementationRepository">TAO's
  34         Implementation Repository</a> <ul>
  35             <li><a href="#VirtualServers">Virtual Servers</a> </li>
  36             <li><a href="#PingObject">Ping Object</a></li>
  37             <li><a href="#NewIORs">New IORs</a> <ul>
  38                     <li><a href="#WhatwaswrongwiththeoldIOR">What
  39                         was wrong with the old IOR?</a> </li>
  40                     <li><a href="#WhydoesImplRepocontainanOBJKey">Why
  41                         does the Implementation Repository
  42                         profile contain an Object Key?</a> </li>
  43                 </ul>
  44             </li>
  45             <li><a href="#POAExtensions">POA Extensions</a> </li>
  46             <li><a href="#PossibleFutureGoals">Possible Future
  47                 Goals</a> </li>
  48             <li><a href="#ServerRestrictions">Server Restrictions</a>
  49             </li>
  50             <li><a href="#PreliminaryInterface">Preliminary
  51                 Interface</a> </li>
  52         </ul>
  53     </li>
  54     <li><a href="#AlternateImplementations">Alternate
  55         Implementations</a> </li>
  56     <li><a href="#AccessingtheImplementationRepository">Accessing
  57         the Implementation Repository</a> <ul>
  58             <li><a href="#HelperApplication">Helper Application</a>
  59             </li>
  60             <li><a href="#LocatinganinstanceofImplRepo">Locating
  61                 an instance of the Implementation Repository</a> <ul>
  62                     <li><a href="#Serverside">Server Side</a> </li>
  63                     <li><a href="#Clientside">Client Side</a> </li>
  64                 </ul>
  65             </li>
  66         </ul>
  67     </li>
  68     <li><a href="#Howitworks">How It Works</a> <ul>
  69             <li><a href="#HowServerProducesPersistentIORdefault">How
  70                 a server produces a Persistent IOR (in the
  71                 default case)</a> </li>
  72             <li><a href="#HowServerProducesPersistentIORcomplex">How
  73                 a server produces a Persistent IOR (in the
  74                 complex case)</a> </li>
  75             <li><a href="#HowClientUsesPersistentIOR">How a
  76                 client uses a Persistent IOR</a> </li>
  77         </ul>
  78     </li>
  79 </ul>
  80
  81 <hr>
  82
  83 <h2><a name="Changes">Recent Changes</a></h2>
  84
  85 <p>Since 3.04</p>
  86
  87 <ul>
  88     <li>Moved it to the same directory as all the new</li>
  89     <li>After a long delay (too long, if you ask me) addressed
  90         the comments that John Mulhern &lt;<a
  91         href="mailto:9107@mn3.lawson.lawson.com">9107@mn3.lawson.lawson.com</a>&gt;
  92         sent me. </li>
  93 </ul>
  94
  95 <p>Since 3.03 </p>
  96
  97 <ul>
  98     <li>Added information on the new POA policy where the format
  99         of the persistent IOR can be changed from that of both
 100         the last-known-server-IOR and Implementation Repository
 101         to that just of the Implementation Repository</li>
 102     <li>TAO is now fork-safe, with the introduction of the
 103         CLOEXEC flag through ACE_CLOEXEC.</li>
 104 </ul>
 105
 106 <p>Since 3.02 </p>
 107
 108 <ul>
 109     <li>Added a section to give more detailed information on how
 110         Ping Objects work.</li>
 111     <li>Rewrote the Virtual Server section</li>
 112 </ul>
 113
 114 <hr>
 115
 116 <h2><a name="Overview">Overview</a></h2>
 117
 118 <p>This document describes the proposed design of the TAO
 119 Implementation Repository, which was originally known as the
 120 reactivator/activation service. If you have any questions or
 121 comments on our design, please open an issue or discussion at <a
 122 href="https://github.com/DOCGroup/ACE_TAO">github</a>.</p>
 123
 124 <h3><a name="PersistentandTransientIORs">Persistent and Transient
 125 IORs</a></h3>
 126
 127 <p>CORBA defines two types of object references: <a
 128 href="http://www.cs.wustl.edu/~schmidt/C++-report-col12.ps.gz">persistent
 129 and transient</a>. The difference between the two stems from the
 130 lifetime of the reference in relation to the lifetime of the
 131 server process that created it. The lifetime of a transient
 132 object reference is limited to the lifetime of its server
 133 process. Once the server process exits the transient object
 134 reference no longer exists. All references to this object should
 135 now be invalid, even if the server is restarted. In contrast,
 136 persistent object references can outlive their originating server
 137 process. Therefore, the server can exit and be restarted without
 138 invalidating its persistent object references. This enables the
 139 implementation of features like automatic server activation and
 140 object migration.</p>
 141
 142 <p>Note that both persistent and transient object references can
 143 refer to objects that reside in <em>manually activated</em>
 144 servers, <em>i.e.</em>, the so-called ``persistent servers.'' A
 145 persistent server is a server that is launched manually, <em>i.e.</em>,
 146 it is always running. A persistent server can generate transient
 147 references and/or persistent references. </p>
 148
 149 <p>Developers should be aware that persistence of the object
 150 reference does not imply any persistence on the object
 151 implementation state. It is certainly possible to provide
 152 persistent object references for objects whose state is not
 153 persistent. Therefore, servant implementors are responsible for
 154 preserving the state of their servants, <em>e.g.</em>, using a
 155 database or file. </p>
 156
 157 <h3><a name="TheImplementationRepository">The Implementation
 158 Repository</a></h3>
 159
 160 <p>According to the CORBA specification, &quot;The Implementation
 161 Repository contains information that allows the ORB to locate and
 162 activate implementations of objects&quot; [CORBA Spec Rev. 2.2:
 163 2.1.14] In earlier revisions of the specification, there was a
 164 method <code>get_implementation</code> in the CORBA Object
 165 interface. This has been deprecated as of the CORBA 2.2
 166 specification, leaving both the interface and implementation of
 167 the Implementation Repository to the ORB vendor.</p>
 168
 169 <p>A good paper describing the functionality of the CORBA
 170 Implementation Repository is &quot;<a
 171 href="http://www.triodia.com/staff/michi/cacm.pdf">Binding,
 172 Migration, and Scalability in CORBA</a>&quot; [Michi Henning].
 173 This paper describes the following three functions of the
 174 Implementation Repository: </p>
 175
 176 <ol>
 177     <li>Maintain a registry of known servers.</li>
 178     <li>Record which server is currently running, and which port
 179         and host it uses.</li>
 180     <li>Starts servers on demand if they are registered with the
 181         Implementation Repository.</li>
 182 </ol>
 183
 184 <p>The TAO Implementation Repository is based on the design in
 185 this paper. He also wrote an earlier <a
 186 href="http://www.triodia.com/staff/michi/binding.txt">email</a>
 187 that may be useful to see the issues involved. The next section
 188 details our goals and plans for the implementation.</p>
 189
 190 <hr>
 191
 192 <h2><a name="TAOsImplementationRepository">TAO's Implementation
 193 Repository</a></h2>
 194
 195 <p>The following is an brief outline of TAO'S Implementation
 196 Repository. </p>
 197
 198 <ul>
 199     <li>Use of TAO's Implementation Repository will be optional.
 200         Real-time applications can choose not to use the
 201         Implementation Repository according to their
 202         performance/predictability/footprint requirements.</li>
 203     <li>Use of TAO's Implementation Repository will be invisible
 204         to clients and servers for common use-case. For more
 205         complicated behavior, programs can use Implementation
 206         Repository extensions of the POA.</li>
 207     <li>TAO's Implementation Repository will work with any CORBA
 208         client that supports <code>LOCATION_FORWARD</code> IIOP
 209         messages and multiple profiles in IORs, even if the
 210         client is not implemented using TAO.</li>
 211     <li>TAO's Implementation Repository will know if one of the
 212         servers registered with it is running by the use of a
 213         &quot;ping&quot;-like service in the server. This service
 214         allows the Implementation Repository to know when it
 215         should restart the server.</li>
 216     <li>TAO will be fork-safe. Since there will be an open
 217         connection to the client while the server is restarted
 218         (via fork or CreateProcess) then care will be needed to
 219         make sure that the open sockets will be closed in the
 220         client process. The addition of CLOEXEC feature to TAO
 221         will cover this problem.</li>
 222     <li>TAO will exploit features of IIOP 1.1 to safely and
 223         efficiently verify if an IOR was generated by TAO itself
 224         on the client side. The server will still determine this
 225         through the object key, since that is all that is passed
 226         in a request.</li>
 227     <li>TAO will support multiple profiles in IORs. A profile
 228         contains the host/port and object key of a CORBA Object.
 229         An optimization that will be possible is to have a last
 230         known profile of the object as the first profile and an
 231         Implementation Repository as the second profile in an
 232         IOR. The client will first try the object to see if it
 233         still active at the host/port before it contacts the
 234         Implementation Repository. This strategy will reduce
 235         latency. </li>
 236 </ul>
 237
 238 <h3><a name="VirtualServers">Virtual Servers</a></h3>
 239
 240 <p>TAO's Implementation Repository must keep track of whether an
 241 object's implementation is currently running or is stopped. To
 242 have a record for every object would require too much overhead,
 243 but having a record for every executable server would be
 244 inflexible and prevent the migration of objects. In the Henning
 245 paper, he mentions the use of a <em>server name</em> as the index
 246 for the table maintained by the Implementation Repository. </p>
 247
 248 <p>A virtual server does not refer to the executable but instead
 249 to a group of objects. An executable may have one or more virtual
 250 servers within it. This allows one virtual server to be moved off
 251 the executable to another executable (for instance, onto another
 252 machine) without affecting the objects in other virtual servers
 253 on the original executable. </p>
 254
 255 <p>Each virtual server will be indexed in the Implementation
 256 Repository by a name that is given to it by the user. It is the
 257 users responsibility to make sure that each virtual server name
 258 is unique. By default, this name is the name of the executable
 259 (since by default there is only one virtual server per
 260 executable). However, this default behavior can be overridden. </p>
 261
 262 <h3><a name="PingObject">Ping Object</a></h3>
 263
 264 <p>Ping objects are simple objects that reside in the server, one
 265 for every virtual server. It is contacted by the Implementation
 266 Repository to determine if the virtual server is still running
 267 and responding. At certain intervals the Implementation
 268 Repository will invoke a one-way method on the ping object, and
 269 then will expect a &quot;pong&quot; message to be sent back.
 270 Different strategies for pinging (which will depend on a TAO
 271 option) will be used by the implementation repository. If a
 272 server is expected to be responsive, the Implementation
 273 Repository will not wait long for a response before considering
 274 the server to be gone. Other servers may be
 275 computationally-intensive and need to be held under less
 276 stringent expectations.</p>
 277
 278 <p>We chose the ping method to be a one-way (instead of two-way)
 279 because if the server became unresponsive, it would not return
 280 from the method invocation. The Implementation Repository needs
 281 some form of a timeout with the ping to be able to determine if
 282 the server is unresponsive or not.</p>
 283
 284 <h3><a name="NewIORs">New IORs</a></h3>
 285
 286 <p>Standard CORBA IORs contain the following two sections:</p>
 287
 288 <table border="1">
 289     <tr>
 290         <td>Type ID</td>
 291         <td>Sequence of Tagged Profiles</td>
 292     </tr>
 293 </table>
 294
 295 <p>The Type ID is an indicator for the most derived type known at
 296 the time of the reference creation. It is used as a hint for the
 297 client in determining what interfaces the object can support. The
 298 Sequence of Tagged Profiles consist of one or more profiles that
 299 encapsulate information used by the associated protocol in order
 300 to communicate with the object (host, port, object id, etc.).</p>
 301
 302 <p>Currently, TAO uses only one IIOP 1.0 Tagged Profile, which is
 303 defined as follows:</p>
 304
 305 <table border="1">
 306     <tr>
 307         <td>Version</td>
 308         <td>Host</td>
 309         <td>Port</td>
 310         <td>Object Key</td>
 311     </tr>
 312 </table>
 313
 314 <table border="0">
 315     <tr>
 316         <td>Object Key: </td>
 317         <td><table border="1">
 318             <tr>
 319                 <td>Transient/Persistent Flag</td>
 320                 <td>TimeStamp</td>
 321                 <td>POA ID</td>
 322                 <td>OBJ ID</td>
 323             </tr>
 324         </table>
 325         </td>
 326     </tr>
 327 </table>
 328
 329 <p>To accomodate the Implementation Repository and IIOP 1.1, the
 330 Profile was changed according to the CORBA specification as
 331 follows:</p>
 332
 333 <table border="1">
 334     <tr>
 335         <td>Version</td>
 336         <td>Host</td>
 337         <td>Port</td>
 338         <td>Object Key</td>
 339         <td>Components</td>
 340     </tr>
 341 </table>
 342
 343 <table border="0">
 344     <tr>
 345         <td>Object Key: </td>
 346         <td><table border="1">
 347             <tr>
 348                 <td>TAO</td>
 349                 <td>TAO version</td>
 350                 <td>TimeStamp/Server Name</td>
 351                 <td>POA ID</td>
 352                 <td>OBJ ID</td>
 353             </tr>
 354         </table>
 355         </td>
 356     </tr>
 357 </table>
 358
 359 <p>The two main changes is the addition of the Components field
 360 (which is a IIOP 1.1 thing) and the addition of TAO with its
 361 version. Transient object references will still have a TimeStamp
 362 to ensure uniqueness, but persistent object references will have
 363 a server name to identify themselves to the Implementation
 364 Repository.&nbsp; </p>
 365
 366 <p>For servers that move around or need to be restarted often,
 367 the IOR will contain a reference to the Implementation Repository
 368 with the object key of the server and the server name embedded.
 369 &nbsp; Once the client contacts the Implementation Repository, it
 370 will be forwarded to the correct object. This IOR will look like
 371 the following:</p>
 372
 373 <table border="1">
 374     <tr>
 375         <td>Version</td>
 376         <td>Host</td>
 377         <td>Port</td>
 378         <td>Object Key</td>
 379         <td>Components</td>
 380     </tr>
 381 </table>
 382
 383 <table border="0">
 384     <tr>
 385         <td>Object Key: </td>
 386         <td><table border="1">
 387             <tr>
 388                 <td>TAO</td>
 389                 <td>TAO version</td>
 390                 <td>Server Name</td>
 391                 <td>POA ID</td>
 392                 <td>OBJ ID (actually the OBJ Key of the Server)</td>
 393             </tr>
 394         </table>
 395         </td>
 396     </tr>
 397 </table>
 398
 399 <p>For servers that expect to remain in the same host/port for a
 400 long time, the above IOR can be optimized by placing the server
 401 profile in the IOR before the Implementation Repository
 402 profile.&nbsp; TAO clients will first try the server, and if that
 403 fails, then try the Implementation Repository.&nbsp; Clients from
 404 other ORBs may behave the same way, but this isn't guaranteed
 405 since the handling of multiple profiles is not yet in the CORBA
 406 spec. There will be an option to only generate the IR-only IORs
 407 for ORBs that do not support multiple profiles in the needed
 408 manner. </p>
 409
 410 <p>There will be a POA policy to determine which type of
 411 Persistent IOR to use.&nbsp; By default, the Implementation
 412 Repository alone version will be used.</p>
 413
 414 <h4><a name="WhatwaswrongwiththeoldIOR">What was wrong with the
 415 old IOR?</a></h4>
 416
 417 <p>We need a place to put a TAO marker in the IOR so TAO servers
 418 can differentiate TAO IORs from IORs of other vendors. In the
 419 original scheme used in TAO, Persistent IORs had a null
 420 timestamp. To support virtual servers, we will use that slot to
 421 store the server name so the Implementation Repository knows
 422 which server to launch.</p>
 423
 424 <h4><a name="WhydoesImplRepocontainanOBJKey">Why does the
 425 Implementation Repository profile contain an Object Key?</a></h4>
 426
 427 <p>It needs to know what the object key of the object when
 428 forwarding is used. A server may contain more than one object, so
 429 the object key is needed to forward to the correct object on the
 430 server. </p>
 431
 432 <h3><a name="POAExtensions">POA Extensions</a></h3>
 433
 434 <p>TAO's POA will contain a new TAO-specific method called <code>create_reference_with_virtual_server[_and_id]
 435 (...)</code>. This method takes additional arguments for a
 436 virtual server name and a sequence of Implementation Repository
 437 IORs. The POA will register the virtual server name with each of
 438 the Implementation Repositories in the sequence passed in.
 439 Several Implementation Repositories can be specified to enhance
 440 availability through redundancy. </p>
 441
 442 <p>TAO's POA will also contain a policy for the type of IOR
 443 created with <code>create_reference</code>. &nbsp; It can either
 444 produce the standard type, with just a reference to the
 445 Implementation Repository, or it can produce one also containing
 446 a reference to the current server.</p>
 447
 448 <h3><a name="PossibleFutureGoals">Possible Future Goals</a></h3>
 449
 450 <p>The following are features that may be added to support TAO's
 451 Implementation Repository: </p>
 452
 453 <ul>
 454     <li>Optimization on TAO clients to recognize when a server is
 455         restarted, and change all other IORs that contain the
 456         server instead of going through the Implementation
 457         Repository</li>
 458     <li>Some sort of server security that checks the executable
 459         to make sure it is the correct executable (checksum,
 460         signatures, etc).</li>
 461     <li>Add the ability to put servers into DLLs or Shared Object
 462         files so the Implementation Repository can load it via
 463         those methods.</li>
 464     <li>GUI interface for such things as the helper application.</li>
 465     <li>Federations of Implementation Repositories.</li>
 466     <li>The ability to start a remote server (possibly with rsh,
 467         ssh, rexec, etc)</li>
 468 </ul>
 469
 470 <h3><a name="ServerRestrictions">Server Restrictions</a></h3>
 471
 472 <p>Most often servers that have Persistent IORs will save their
 473 state to secondary storage. Databases are a good example of this,
 474 where the server can be stopped and restarted with all the
 475 information remaining on disk. </p>
 476
 477 <p>The server must also make sure it creates the POA and Object
 478 in a way that does not change the POA ID and Object ID. The
 479 Implementation Repository forwards requests based on the
 480 information in the IOR; if the POA ID or Object ID changes, then
 481 the Implementation Repository will be unable to sucessfully
 482 forward requests. If the server implements dynamic servants and
 483 dynamic POA activations, then this is not an issue since the
 484 necessary POAs and servants will be created on demand.</p>
 485
 486 <h3><a name="PreliminaryInterface">Preliminary Interface</a></h3>
 487
 488 <p>The following is a proposed IDL interface for the TAO
 489 Implementation Repository: </p>
 490
 491 <pre>module TAO
 492 {
 493   // ....
 494
 495   exception Already_Registered {};
 496   // Object already bound in the Implementation Repository
 497
 498   exception Cannot_Activate
 499   {
 500     string reason_;
 501   };
 502
 503   exception Not_Found {};
 504   // Object not found in the Implementation Repository
 505
 506   struct Environment_Variable
 507   {
 508     string name_;
 509     string value_;
 510   };
 511   // One environment variable
 512
 513   struct INET_Addr
 514   {
 515     unsigned short port_;
 516     unsigned long host_;
 517   };
 518   // The location of a server
 519
 520   typedef sequence&lt;Environment_Variable&gt; Environment;
 521   // Complete environment
 522
 523   typedef sequence&lt;string&gt; Command_Line_Options;
 524   // Command line options
 525
 526   struct Process_Options
 527   {
 528     string executable_name_;
 529     // Executable name
 530
 531     Command_Line_Options command_line_options_;
 532     // Command line options
 533
 534     Environment environment_;
 535     // Environment
 536
 537     string working_directory_;
 538     // Working directory
 539
 540     unsigned long creation_flags_;
 541     // Creation flags
 542   };
 543
 544   interface Ping_Object
 545   {
 546     oneway void ping ();
 547     // Used for checking for liveness of a server.  When the server receives
 548     // this, it should send back a response indicating it is sill alive.
 549     // Depending on the policy specified, a timeout can be reached where the
 550     // Implementation Repository will restart the server.
 551   };
 552
 553   interface Implementation_Repository
 554   {
 555     Object activate_object (in Object obj)
 556       raises (Not_Found,
 557               Cannot_Activate);
 558       // Restart server that will contain this persistent object and return the
 559       // new Object reference.
 560       //
 561       // The &lt;Not_Found&gt; exception is raised when &lt;obj&gt; is not found
 562       // in the Implementation Repository.  The &lt;Cannot_Activate&gt; exception
 563       // is raised when &lt;obj&gt; is found in the Repository but could not be
 564       // activated.
 565
 566     INET_Addr activate_server (in string server)
 567       raises (Not_Found,
 568               Cannot_Activate);
 569       // Restart server that is named &lt;server&gt; and return the host/port
 570       //
 571       //
 572       // The &lt;Not_Found&gt; exception is raised when &lt;server&gt; is not found
 573       // in the Implementation Repository.  The &lt;Cannot_Activate&gt; exception
 574       // is raised when &lt;server&gt; is found in the Repository but could not be
 575       // activated.
 576
 577     void register_server (in string server,
 578                           in Process_Options options)
 579       raises (Already_Registered);
 580       // Restart server process when client is looking for &lt;server&gt;.
 581       //
 582       // The &lt;Already_Registered&gt; exception is raised when &lt;server&gt; has
 583       // already been registered with the Implementation Repository.
 584       //
 585       // The &lt;Object_Not_Persistent&gt; exception is raised when &lt;server&gt; is
 586       // not a Persistent Object Reference.
 587
 588     void reregister_server (in string server,
 589                             in Process_Options options)
 590       raises (Already_Registered);
 591       // Restart server process when client is looking for &lt;server&gt;.
 592       //
 593       // The &lt;Already_Registered&gt; exception is raised when &lt;server&gt; has
 594       // already been registered with the Implementation Repository.
 595       //
 596       // The &lt;Object_Not_Persistent&gt; exception is raised when &lt;server&gt; is
 597       // not a Persistent Object Reference.
 598
 599     void remove_server (in string server)
 600       raises (Not_Found);
 601       // Remove &lt;server&gt; from the Implementation Repository.
 602       //
 603       // The &lt;Not_Found&gt; exception is raised when &lt;server&gt; is not found
 604       // in the Implementation Repository.
 605
 606     Profile server_is_running (in string server,
 607                                in INET_Addr addr,
 608                                in Ping_Object ping);
 609       // Used to notify the Implementation Repository that &lt;server&gt; is alive and
 610       // well at &lt;addr&gt;.
 611
 612     void server_is_shutting_down (in string server);
 613       // Used to tell the Implementation Repository that &lt;server&gt; is shutting
 614       // down.
 615     };
 616 };</pre>
 617
 618 <hr>
 619
 620 <h2><a name="AlternateImplementations">Alternate Implementations</a></h2>
 621
 622 <p>Other ORB vendors use alternative techniques for their
 623 Implementation Repositories. These techniques usually require new
 624 naming techniques to access persistent object references and new
 625 client-side APIs to bind to persistent object references. TAO's
 626 Implementation Repository will not require such extensions. </p>
 627
 628 <p>A possible design alternative for the IR might use an Object
 629 Reference that points to the Implementation Repository instead of
 630 pointing directly to the persistent object. This extra level of
 631 indirection would be used by the Implementation Repository to
 632 start the server, if needed. The Location Forwarding mechanism
 633 would then be used to forward the client request to the server.
 634 The difference between this design and TAO's design is that the
 635 persistent IOR in TAO will contain a profile pointing to a
 636 location of the server (where it still might be running) to try
 637 first, and then only if that fails does the client contact the
 638 Implementation Repository. This is an optimization for case where
 639 the server does not shut down often, and most requests do not
 640 need to be forwarded to a new address.</p>
 641
 642 <p>In cases where most requests will require a forward, TAO can
 643 support a policy that is just like this alternative, where the
 644 Implmentation Repository will be contacted first.</p>
 645
 646 <hr>
 647
 648 <h2><a name="AccessingtheImplementationRepository">Accessing the
 649 Implementation Repository</a> </h2>
 650
 651 <p>The Implementation Repository will be transparent to the
 652 clients and the servers. Clients will only deal with IIOP 1.1
 653 IORs, and in the default case all the Implementation Repository
 654 logic on the server side will be handled internally by the ORB
 655 and the POA. </p>
 656
 657 <h3><a name="HelperApplication">Helper Application</a></h3>
 658
 659 <p>A helper application will be included with the Implementation
 660 Repository. It will be a command-line utility that will assist
 661 users with adding and removing server records (containing virtual
 662 server names and executable name/options) from the Implementation
 663 Repository. </p>
 664
 665 <h3><a name="LocatinganinstanceofImplRepo">Locating an Instance
 666 of the Implementation Repository </a></h3>
 667
 668 <h4><a name="Serverside">Server-side</a></h4>
 669
 670 <p>In the default case, the Implementation Repository will be
 671 found via the command-line, environment variables, and multicast
 672 (in that order). This location strategy is consistent with that
 673 used by TAO to local its default Naming Service instance. Using
 674 the POA extensions, other Implementation Repositories can be
 675 specified in the call to <code>POA::create_reference_with_virtual_server</code>.
 676 The default port of the Implementation Repository can be
 677 overridden through command-line options or environment variables.
 678 </p>
 679
 680 <h4><a name="Clientside">Client-side</a></h4>
 681
 682 <p>One or more Implementation Repositories will be stored in
 683 additional profiles in the IOR. Other Implementation Repositories
 684 can also be located by multicasting (on a default multicast
 685 group) the server name of the Persistent Object the client is
 686 interested in. The default multicast group and default port of
 687 the Implementation Repository can be overridden through command
 688 line options or environment variables. </p>
 689
 690 <p>In most cases, one Implementation Repository will be enough.
 691 For redundancy, several Implementation Repositories can be
 692 specified.</p>
 693
 694 <hr>
 695
 696 <h2><a name="Howitworks">How It Works</a></h2>
 697
 698 <h3><a name="HowServerProducesPersistentIORdefault">How a server
 699 produces a Persistent IOR (in the default case)</a></h3>
 700
 701 <p>Before a server starts, it must be registered (via a
 702 command-line utility) with an implementation repository. On
 703 platforms that don't support multicast, the Implementation
 704 Repository must be specified on the command line or in an
 705 environment variable. </p>
 706
 707 <ol>
 708     <li>When the server starts up it calls <code>ORB_init</code>.
 709         <code>ORB_init</code>, if not passed a server name, will
 710         take argv[0] and use that as a default server name (TAO
 711         expects this to be the executable name). </li>
 712     <li><code>ORB_init</code> will create a ping object.</li>
 713     <li><code>ORB_init</code> will look for Implementation
 714         Repositories on the command-line, environmental
 715         variables, and then through multicast (in that order).
 716         Once it finds one it registers itself and passes the ping
 717         object to the implementation repository with <code>server_is_running</code>
 718         operation. </li>
 719     <li>The profile returned by registration will be stored for
 720         later use.</li>
 721     <li>Client later can call the <code>POA::create_reference</code>
 722         operation.</li>
 723     <li>The <code>create_reference</code> operation will create
 724         the local profile.</li>
 725     <li>The stored Implementation Repository profile will have
 726         its object id changed to be the object key just created.</li>
 727     <li>Both profiles will be joined together if the multiple
 728         profile IOR policy is set, and then returned.</li>
 729 </ol>
 730
 731 <h3><a name="HowServerProducesPersistentIORcomplex">How a server
 732 produces a Persistent IOR (in complex cases)</a></h3>
 733
 734 <p>As with the default case, the server must be registered with
 735 an Implementation Repository, although it does not need to be
 736 multicast aware since the IORs will be passed to the POA by the
 737 program. </p>
 738
 739 <ol>
 740     <li><code>ORB_init</code> is called and does the default work
 741         (if it has Implementation Repositories to contact).</li>
 742     <li><code>POA::create_reference_with_virtual_server[_and_id]</code>
 743         will be called with a server name and list of
 744         Implementation Repositories. </li>
 745     <li>The profile for the object is created.</li>
 746     <li>The ping object created in <code>ORB_init</code> and the
 747         object key is passed to the Implementation Repositories,
 748         and their profiles are returned.</li>
 749     <li>Both profiles will be joined together if the multiple
 750         profile IOR policy is set, and then returned.</li>
 751 </ol>
 752
 753 <h3><a name="HowClientUsesPersistentIOR">How a client uses a
 754 Persistent IOR</a></h3>
 755
 756 <p>For all Clients: </p>
 757
 758 <ul>
 759     <li>Client obtains a Persistent Object Reference, which
 760         contains multiple profiles to both regular objects and
 761         Implementation Repositories.</li>
 762     <li>It will now make a request on the first profile.</li>
 763     <li>If the first profile if the server profile, and the
 764         server is still there, then it will be successful.&nbsp;
 765         If the server has moved (or shut down), then the next
 766         profile will be tried.</li>
 767     <li>If the first profile is the Implementation Repository, or
 768         if the server profile failed, then it will be
 769         contacted.&nbsp; The Implementation Repository will then
 770         return NOT_FOUND or will start up the server and return a
 771         Location Forward message.</li>
 772 </ul>
 773
 774 <p>If everything fails, then most clients will return failure for
 775 the request. TAO clients will attempt to contact other
 776 Implementation Repositories that are specified on the
 777 command-line, in environment variables, or found through
 778 multicast. </p>
 779
 780 <ul>
 781     <li>If all of the profiles fail, then contact the other
 782         Implementation Repositories. First get those specified on
 783         the command line or in environment variables.</li>
 784     <li>Then, if multicast is available: <ul>
 785             <li>Multicast the Object Reference to a group of
 786                 Implementation Repositories </li>
 787             <li>Wait until response or a timeout. The response
 788                 will contain the Object Reference of a
 789                 Implementation Repository that knows about the
 790                 Object Reference </li>
 791         </ul>
 792     </li>
 793     <li>Connect to the Implementation Repository that responds
 794         first.</li>
 795     <li>Call <i>activate</i> passing the Persistent Object
 796         Reference.</li>
 797     <li>If a new Object Reference was sent back then retry the
 798         request using the it. If this request fails, then fail
 799         (no more retries).</li>
 800     <li>If a null reference was sent back, then fail.</li>
 801 </ul>
 802
 803 <p>TAO clients will have an optimization where if there are
 804 several IORs that have the same server name, and one of them gets
 805 forwarded, then the client will be able to change its other IORs
 806 without going through the overhead of contacting Implementation
 807 Repository.</p>
 808
 809 <hr>
 810
 811 <p>Back to <a href="../releasenotes/index.html">TAO Release Notes</a></p>
 812
 813 <p>Back to <a href="index.html">Implementation Repository</a></p>
 814 </body>
 815 </html>