summaryrefslogtreecommitdiff
path: root/TAO/docs/implrepo.html
diff options
context:
space:
mode:
Diffstat (limited to 'TAO/docs/implrepo.html')
-rw-r--r--TAO/docs/implrepo.html677
1 files changed, 0 insertions, 677 deletions
diff --git a/TAO/docs/implrepo.html b/TAO/docs/implrepo.html
deleted file mode 100644
index 3d4e5e016f7..00000000000
--- a/TAO/docs/implrepo.html
+++ /dev/null
@@ -1,677 +0,0 @@
-<!-- $Id$ -->
-<html>
-
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
-<title>TAO Implementation Repository</title>
-</head>
-
-<body bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#CC0000">
-
-<hr>
-
-<h1>TAO Implementation Repository </h1>
-
-<p>Revision 3.04 - August 5, 1998</p>
-
-<hr>
-
-<h2>Table of Contents</h2>
-
-<ul>
- <li><a href="#Changes">Recent Changes</a> </li>
- <li><a href="#Overview">Overview</a> <ul>
- <li><a href="#PersistentandTransientIORs">Persistent and Transient IORs</a> </li>
- <li><a href="#TheImplementationRepository">The Implementation Repository</a> </li>
- </ul>
- </li>
- <li><a href="#TAOsImplementationRepository">TAO's Implementation Repository</a> <ul>
- <li><a href="#VirtualServers">Virtual Servers</a> </li>
- <li><a href="#PingObject">Ping Object</a></li>
- <li><a href="#NewIORs">New IORs</a> <ul>
- <li><a href="#WhatwaswrongwiththeoldIOR">What was wrong with the old IOR?</a> </li>
- <li><a href="#WhydoesImplRepocontainanOBJKey">Why does the Implementation Repository profile
- contain an Object Key?</a> </li>
- </ul>
- </li>
- <li><a href="#POAExtensions">POA Extensions</a> </li>
- <li><a href="#PossibleFutureGoals">Possible Future Goals</a> </li>
- <li><a href="#ServerRestrictions">Server Restrictions</a> </li>
- <li><a href="#PreliminaryInterface">Preliminary Interface</a> </li>
- </ul>
- </li>
- <li><a href="#AlternateImplementations">Alternate Implementations</a> </li>
- <li><a href="#AccessingtheImplementationRepository">Accessing the Implementation Repository</a>
- <ul>
- <li><a href="#HelperApplication">Helper Application</a> </li>
- <li><a href="#LocatinganinstanceofImplRepo">Locating an instance of the Implementation
- Repository</a> <ul>
- <li><a href="#Serverside">Server Side</a> </li>
- <li><a href="#Clientside">Client Side</a> </li>
- </ul>
- </li>
- </ul>
- </li>
- <li><a href="#Howitworks">How It Works</a> <ul>
- <li><a href="#HowServerProducesPersistentIORdefault">How a server produces a Persistent IOR
- (in the default case)</a> </li>
- <li><a href="#HowServerProducesPersistentIORcomplex">How a server produces a Persistent IOR
- (in the complex case)</a> </li>
- <li><a href="#HowClientUsesPersistentIOR">How a client uses a Persistent IOR</a> </li>
- </ul>
- </li>
-</ul>
-
-<hr>
-
-<h2><a name="Changes">Recent Changes</a></h2>
-
-<p>Since 3.03
-
-<ul>
- <li>Added information on the new POA policy where the format of the persistent IOR can be
- changed from that of both the last-known-server-IOR and Implementation Repository to that
- just of the Implementation Repository</li>
- <li>TAO is now fork-safe, with the introduction of the CLOEXEC flag through ACE_CLOEXEC.</li>
-</ul>
-
-<p>Since 3.02
-
-<ul>
- <li>Added a section to give more detailed information on how Ping Objects work.</li>
- <li>Rewrote the Virtual Server section</li>
-</ul>
-
-<hr>
-
-<h2><a name="Overview">Overview</a></h2>
-
-<p>This document describes the proposed design of the TAO Implementation Repository, which
-was originally known as the reactivator/activation service. If you have any questions or
-comments on our design, please post them to the <a
-HREF="http://www.cs.wustl.edu/~schmidt/ACE-mail.html">ACE</a> mailing list &lt;<a
-HREF="mailto:ace-useres@cs.wustl.edu">ace-users@cs.wustl.edu</a>&gt; or send email to
-Darrell Brunsch &lt;<a HREF="mailto:brunsch@cs.wustl.edu">brunsch@cs.wustl.edu</a>&gt;.</p>
-
-<h3><a name="PersistentandTransientIORs">Persistent and Transient IORs</a></h3>
-
-<p>CORBA defines two types of object references: <a
-HREF="http://www.cs.wustl.edu/~schmidt/C++-report-col12.ps.gz">persistent and transient</a>.
-The difference between the two stems from the lifetime of the reference in relation to the
-lifetime of the server process that created it. The lifetime of a transient object
-reference is limited to the lifetime of its server process. Once the server process exits
-the transient object reference no longer exists. All references to this object should now
-be invalid, even if the server is restarted. In contrast, persistent object references can
-outlive their originating server process. Therefore, the server can exit and be restarted
-without invalidating its persistent object references. This enables the implementation of
-features like automatic server activation and object migration.</p>
-
-<p>Note that both persistent and transient object references can refer to objects that
-reside in <em>manually activated</em> servers, <em>i.e.</em>, the so-called ``persistent
-servers.'' A persistent server is a server that is launched manually, <em>i.e.</em>, it is
-always running. A persistent server can generate transient references and/or persistent
-references. </p>
-
-<p>Developers should be aware that persistence of the object reference does not imply any
-persistence on the object implementation state. It is certainly possible to provide
-persistent object references for objects whose state is not persistent. Therefore, servant
-implementors are responsible for preserving the state of their servants, <em>e.g.</em>,
-using a database or file. </p>
-
-<h3><a name="TheImplementationRepository">The Implementation Repository</a></h3>
-
-<p>According to the CORBA specification, &quot;The Implementation Repository contains
-information that allows the ORB to locate and activate implementations of objects&quot;
-[CORBA Spec Rev. 2.2: 2.1.14] In earlier revisions of the specification, there was a
-method <code>get_implementation</code> in the CORBA Object interface. This has been
-deprecated as of the CORBA 2.2 specification, leaving both the interface and
-implementation of the Implementation Repository to the ORB vendor.</p>
-
-<p>A good paper describing the functionality of the CORBA Implementation Repository is
-&quot;<a href="http://danzon.cs.wustl.edu/binding.pdf">Binding, Migration, and
-Scalability in CORBA</a>&quot; [Henning]. This paper describes the following three
-functions of the Implementation Repository:
-
-<ol>
- <li>Maintain a registry of known servers.</li>
- <li>Record which server is currently running, and which port and host it uses.</li>
- <li>Starts servers on demand if they are registered with the Implementation Repository.</li>
-</ol>
-
-<p>The TAO Implementation Repository is based on the design in this paper. The next
-section details our goals and plans for the implementation.</p>
-
-<hr>
-
-<h2><a name="TAOsImplementationRepository">TAO's Implementation Repository</a></h2>
-
-<p>The following is an brief outline of TAO'S Implementation Repository.
-
-<ul>
- <li>Use of TAO's Implementation Repository will be optional. Real-time applications can
- choose not to use the Implementation Repository according to their
- performance/predictability/footprint requirements.</li>
- <li>Use of TAO's Implementation Repository will be invisible to clients and servers for
- common use-case. For more complicated behavior, programs can use Implementation Repository
- extensions of the POA.</li>
- <li>TAO's Implementation Repository will work with any CORBA client that supports <code>LOCATION_FORWARD</code>
- IIOP messages and multiple profiles in IORs, even if the client is not implemented using
- TAO.</li>
- <li>TAO's Implementation Repository will know if one of the servers registered with it is
- running by the use of a &quot;ping&quot;-like service in the server. This service allows
- the Implementation Repository to know when it should restart the server.</li>
- <li>TAO will be fork-safe. Since there will be an open connection to the client while the
- server is restarted (via fork or CreateProcess) then care will be needed to make sure that
- the open sockets will be closed in the client process. The addition of CLOEXEC feature to
- TAO will cover this problem.</li>
- <li>TAO will exploit features of IIOP 1.1 to safely and efficiently verify if an IOR was
- generated by TAO itself on the client side. The server will still determine this through
- the object key, since that is all that is passed in a request.</li>
- <li>TAO will support multiple profiles in IORs. A profile contains the host/port and object
- key of a CORBA Object. An optimization that will be possible is to have a last known
- profile of the object as the first profile and an Implementation Repository as the second
- profile in an IOR. The client will first try the object to see if it still active at the
- host/port before it contacts the Implementation Repository. This strategy will reduce
- latency. </li>
-</ul>
-
-<h3><a name="VirtualServers">Virtual Servers</a></h3>
-
-<p>TAO's Implementation Repository must keep track of whether an object's implementation
-is currently running or is stopped. To have a record for every object would require too
-much overhead, but having a record for every executable server would be inflexible and
-prevent the migration of objects. In the <a
-href="http://danzon.cs.wustl.edu/binding.pdf">Henning</a> paper, he mentions the use
-of a <em>server name</em> as the index for the table maintained by the Implementation
-Repository. </p>
-
-<p>The virtual server does not refer to the executable but instead to a group of objects.
-An executable may have one or more virtual servers on it. This allows one virtual server
-to be moved off the executable to another executable (for instance, onto another machine)
-without affecting the objects in other virtual servers on the original executable. </p>
-
-<p>Each virtual server will be indexed in the Implementation Repository by a name that is
-given to it by the user. It is also the users responsibility to make sure that each
-virtual server name is unique. By default, this name is the name of the executable (since
-by default there is only one virtual server per executable). However, this default
-behavior can be overridden. </p>
-
-<h3><a name="PingObject">Ping Object</a></h3>
-
-<p>Ping objects are simple objects that reside in the server, one for every virtual
-server. It is contacted by the Implementation Repository to determine if the virtual
-server is still running and responding. At certain intervals the Implementation Repository
-will invoke a one-way method on the ping object, and then will expect a &quot;pong&quot;
-message to be sent back. Different strategies for pinging will be used by the
-implementation repository. If a server is expected to be responsive, the Implementation
-Repository will not wait long for a response before considering the server to be gone.
-Other servers may be computationally-intensive and need to be held under less stringent
-expectations.</p>
-
-<p>We chose the ping method to be a one-way (instead of two-way) because if the server
-became unresponsive, it would not return from the method invocation. The Implementation
-Repository needs some form of a timeout with the ping to be able to determine if the
-server is unresponsive or not.</p>
-
-<h3><a name="NewIORs">New IORs</a></h3>
-
-<p>Standard CORBA IORs contain the following two sections:</p>
-
-<table border="1">
- <tr>
- <td>Type ID</td>
- <td>Sequence of Tagged Profiles</td>
- </tr>
-</table>
-
-<p>The Type ID is an indicator for the most derived type known at the time of the
-reference creation. It is used as a hint for the client in determining what interfaces the
-object can support. The Sequence of Tagged Profiles consist of one or more profiles that
-encapsulate information used by the associated protocol in order to communicate with the
-object (host, port, object id, etc.).</p>
-
-<p>Currently, TAO uses only one IIOP 1.0 Tagged Profile, which is defined as follows:</p>
-
-<table border="1">
- <tr>
- <td>Version</td>
- <td>Host</td>
- <td>Port</td>
- <td>Object Key</td>
- </tr>
-</table>
-
-<table border="0">
- <tr>
- <td>Object Key: </td>
- <td><table border="1">
- <tr>
- <td>Transient/Persistent Flag</td>
- <td>TimeStamp</td>
- <td>POA ID</td>
- <td>OBJ ID</td>
- </tr>
- </table>
- </td>
- </tr>
-</table>
-
-<p>To accomodate the Implementation Repository and IIOP 1.1, the Profile was changed
-according to the CORBA specification as follows:</p>
-
-<table border="1">
- <tr>
- <td>Version</td>
- <td>Host</td>
- <td>Port</td>
- <td>Object Key</td>
- <td>Components</td>
- </tr>
-</table>
-
-<table border="0">
- <tr>
- <td>Object Key: </td>
- <td><table border="1">
- <tr>
- <td>TAO</td>
- <td>TAO version</td>
- <td>TimeStamp/Server Name</td>
- <td>POA ID</td>
- <td>OBJ ID</td>
- </tr>
- </table>
- </td>
- </tr>
-</table>
-
-<p>In TAO, Transient object references will have a TimeStamp to ensure uniqueness.
-Likewise, persistent object references will have a server name to identify them in the
-Implementation Repository.</p>
-
-<p>TAO will support two difference classes of Persistent IORs.&nbsp; For servers that move
-around or need to be restarted often, the IOR will actually contain a reference to the
-Implementation Repository with the object key of the server and the server name imbedded.
-&nbsp; Once the client contacts the Implementation Repository, it will be forwarded to the
-correct object.</p>
-
-<table border="1">
- <tr>
- <td>Version</td>
- <td>Host</td>
- <td>Port</td>
- <td>Object Key</td>
- <td>Components</td>
- </tr>
-</table>
-
-<table border="0">
- <tr>
- <td>Object Key: </td>
- <td><table border="1">
- <tr>
- <td>TAO</td>
- <td>TAO version</td>
- <td>Server Name</td>
- <td>POA ID</td>
- <td>OBJ ID (actually the OBJ Key of the Server)</td>
- </tr>
- </table>
- </td>
- </tr>
-</table>
-
-<p>If the server is expected to remain in the same host/port for a long time, then the IOR
-can be optimized by placing the server profile in the IOR before the Implementation
-Repository profile.&nbsp; TAO clients will first try the server, and if that fails, then
-try the Implementation Repository.&nbsp; Clients from other ORBs may behave the same way,
-but this isn't guaranteed since the handling of multiple profiles is not yet in the CORBA
-spec.</p>
-
-<p>There will be a POA policy to determine which type of Persistent IOR to use.&nbsp; By
-default, the Implementation Repository alone version will be used.</p>
-
-<h4><a name="WhatwaswrongwiththeoldIOR">What was wrong with the old IOR?</a></h4>
-
-<p>We need a place to put a TAO marker in the IOR it so TAO servers can differentiate TAO
-IORs from IORs of other vendors. In the original scheme used in TAO, Persistent IORs had a
-null timestamp. To support virtual servers, we will use that slot to store the server name
-so the Implementation Repository knows which server to launch.</p>
-
-<h4><a name="WhydoesImplRepocontainanOBJKey">Why does the Implementation Repository
-profile contain an Object Key?</a></h4>
-
-<p>It needs to know what the object key of the object when forwarding is used. A server
-may contain more than one object, so the object key is needed to forward to the correct
-object on the server. </p>
-
-<h3><a name="POAExtensions">POA Extensions</a></h3>
-
-<p>TAO's POA will contain a new TAO-specific method called <code>create_reference_with_virtual_server[_and_id]
-(...)</code>. This method takes additional arguments for a virtual server name and a
-sequence of Implementation Repository IORs. The POA will register the virtual server name
-with each of the Implementation Repositories in the sequence passed in. Several
-Implementation Repositories can be specified to enhance availability through redundancy. </p>
-
-<p>TAO's POA will also contain a policy for the type of IOR created with <code>create_reference</code>.
-&nbsp; It can either produce the standard type, with just a reference to the
-Implementation Repository, or it can produce one also containing a reference to the
-current server.</p>
-
-<h3><a name="PossibleFutureGoals">Possible Future Goals</a></h3>
-
-<p>The following are features that may be added to support TAO's Implementation
-Repository:
-
-<ul>
- <li>Optimization on TAO clients to recognize when a server is restarted, and change all
- other IORs that contain the server instead of going through the Implementation Repository</li>
- <li>Some sort of server security that checks the executable to make sure it is the correct
- executable (checksum, signatures, etc).</li>
- <li>Add the ability to put servers into DLLs or Shared Object files so the Implementation
- Repository can load it via those methods.</li>
- <li>GUI interface for such things as the helper application.</li>
- <li>Federations of Implementation Repositories.</li>
- <li>The ability to start a remote server (possibly with rsh, ssh, rexec, etc)</li>
-</ul>
-
-<h3><a name="ServerRestrictions">Server Restrictions</a></h3>
-
-<p>Most often servers that have Persistent IORs will save their state to secondary
-storage. Databases are a good example of this, where the server can be stopped and
-restarted with all the information remaining on disk. </p>
-
-<p>The server must also make sure it creates the POA and Object in a way that does not
-change the POA ID and Object ID. The Implementation Repository forwards requests based on
-the information in the IOR; if the POA ID or Object ID changes, then the Implementation
-Repository will be unable to sucessfully forward requests. If the server implements
-dynamic servants and dynamic POA activations, then this is not an issue since the
-necessary POAs and servants will be created on demand.</p>
-
-<h3><a name="PreliminaryInterface">Preliminary Interface</a></h3>
-
-<p>The following is a proposed IDL interface for the TAO Implementation Repository: </p>
-
-<pre>module TAO
-{
- // ....
-
- exception Already_Registered {};
- // Object already bound in the Implementation Repository
-
- exception Cannot_Activate
- {
- string reason_;
- };
-
- exception Not_Found {};
- // Object not found in the Implementation Repository
-
- struct Environment_Variable
- {
- string name_;
- string value_;
- };
- // One environment variable
-
- struct INET_Addr
- {
- unsigned short port_;
- unsigned long host_;
- };
- // The location of a server
-
- typedef sequence&lt;Environment_Variable&gt; Environment;
- // Complete environment
-
- typedef sequence&lt;string&gt; Command_Line_Options;
- // Command line options
-
- struct Process_Options
- {
- string executable_name_;
- // Executable name
-
- Command_Line_Options command_line_options_;
- // Command line options
-
- Environment environment_;
- // Environment
-
- string working_directory_;
- // Working directory
-
- unsigned long creation_flags_;
- // Creation flags
- };
-
- interface Ping_Object
- {
- oneway void ping ();
- // Used for checking for liveness of a server. When the server receives
- // this, it should send back a response indicating it is sill alive.
- // Depending on the policy specified, a timeout can be reached where the
- // Implementation Repository will restart the server.
- };
-
- interface Implementation_Repository
- {
- Object activate_object (in Object obj)
- raises (Not_Found,
- Cannot_Activate);
- // Restart server that will contain this persistent object and return the
- // new Object reference.
- //
- // The &lt;Not_Found&gt; exception is raised when &lt;obj&gt; is not found
- // in the Implementation Repository. The &lt;Cannot_Activate&gt; exception
- // is raised when &lt;obj&gt; is found in the Repository but could not be
- // activated.
-
- INET_Addr activate_server (in string server)
- raises (Not_Found,
- Cannot_Activate);
- // Restart server that is named &lt;server&gt; and return the host/port
- //
- //
- // The &lt;Not_Found&gt; exception is raised when &lt;server&gt; is not found
- // in the Implementation Repository. The &lt;Cannot_Activate&gt; exception
- // is raised when &lt;server&gt; is found in the Repository but could not be
- // activated.
-
- void register_server (in string server,
- in Process_Options options)
- raises (Already_Registered);
- // Restart server process when client is looking for &lt;server&gt;.
- //
- // The &lt;Already_Registered&gt; exception is raised when &lt;server&gt; has
- // already been registered with the Implementation Repository.
- //
- // The &lt;Object_Not_Persistent&gt; exception is raised when &lt;server&gt; is
- // not a Persistent Object Reference.
-
- void reregister_server (in string server,
- in Process_Options options)
- raises (Already_Registered);
- // Restart server process when client is looking for &lt;server&gt;.
- //
- // The &lt;Already_Registered&gt; exception is raised when &lt;server&gt; has
- // already been registered with the Implementation Repository.
- //
- // The &lt;Object_Not_Persistent&gt; exception is raised when &lt;server&gt; is
- // not a Persistent Object Reference.
-
- void remove_server (in string server)
- raises (Not_Found);
- // Remove &lt;server&gt; from the Implementation Repository.
- //
- // The &lt;Not_Found&gt; exception is raised when &lt;server&gt; is not found
- // in the Implementation Repository.
-
- Profile server_is_running (in string server,
- in INET_Addr addr,
- in Ping_Object ping);
- // Used to notify the Implementation Repository that &lt;server&gt; is alive and
- // well at &lt;addr&gt;.
-
- void server_is_shutting_down (in string server);
- // Used to tell the Implementation Repository that &lt;server&gt; is shutting
- // down.
- };
-};</pre>
-
-<hr>
-
-<h2><a name="AlternateImplementations">Alternate Implementations</a></h2>
-
-<p>Other ORB vendors use alternative techniques for their Implementation Repositories.
-These techniques usually require new naming techniques to access persistent object
-references and new client-side APIs to bind to persistent object references. TAO's
-Implementation Repository will not require such extensions. </p>
-
-<p>Another design of an Implementation Repository uses an Object Reference that points to
-the Implementation Repository instead of pointing directly to the persistent object. This
-extra level of indirection is used by the Implementation Repository to start the server
-(if needed), and then uses the Location Forwarding mechanism to forward the client request
-to the server. The difference between this design and TAO's design is that the persistent
-IOR in TAO will contain a profile pointing to a location of the server (where it still
-might be running) to try first, and then only if that fails does the client contact the
-Implementation Repository. This is an optimization for case where the server does not shut
-down often, and most requests do not need to be forwarded to a new address.</p>
-
-<p>In cases where most requests will require a forward, TAO can support a policy that is
-just like this alternative, where the Implmentation Repository will be contacted first.</p>
-
-<hr>
-
-<h2><a name="AccessingtheImplementationRepository">Accessing the Implementation Repository</a>
-</h2>
-
-<p>The Implementation Repository will be transparent to the clients and the servers.
-Clients will only deal with IIOP 1.1 IORs, and in the default case all the Implementation
-Repository logic on the server side will be handled internally by the ORB and the POA. </p>
-
-<h3><a name="HelperApplication">Helper Application</a></h3>
-
-<p>A helper application will be included with the Implementation Repository. It will be a
-command-line utility that will assist users with adding and removing server records
-(containing virtual server names and executable name/options) from the Implementation
-Repository. </p>
-
-<h3><a name="LocatinganinstanceofImplRepo">Locating an Instance of the Implementation
-Repository </a></h3>
-
-<h4><a name="Serverside">Server-side</a></h4>
-
-<p>In the default case, the Implementation Repository will be found via the command-line,
-environment variables, and multicast (in that order). This location strategy is consistent
-with that used by TAO to local its default Naming Service instance. Using the POA
-extensions, other Implementation Repositories can be specified in the call to <code>POA::create_reference_with_virtual_server</code>.
-The default port of the Implementation Repository can be overridden through command-line
-options or environment variables. </p>
-
-<h4><a name="Clientside">Client-side</a></h4>
-
-<p>One or more Implementation Repositories will be stored in additional profiles in the
-IOR. Other Implementation Repositories can also be located by multicasting (on a default
-multicast group) the server name of the Persistent Object the client is interested in. The
-default multicast group and default port of the Implementation Repository can be
-overridden through command line options or environment variables. </p>
-
-<p>In most cases, one Implementation Repository will be enough. For redundancy, several
-Implementation Repositories can be specified.</p>
-
-<hr>
-
-<h2><a name="Howitworks">How It Works</a></h2>
-
-<h3><a name="HowServerProducesPersistentIORdefault">How a server produces a Persistent IOR
-(in the default case)</a></h3>
-
-<p>Before a server starts, it must be registered (via a command-line utility) with an
-implementation repository. On platforms that don't support multicast, the Implementation
-Repository must be specified on the command line or in an environment variable.
-
-<ol>
- <li>Now the server will start up and call <code>ORB_init</code>. <code>ORB_init</code>, if
- not passed a server name, will take argv[0] and use that as a default server name (TAO
- expects this to be the executable name). </li>
- <li><code>ORB_init</code> will create a ping object.</li>
- <li><code>ORB_init</code> will look for Implementation Repositories on the command-line,
- environmental variables, and then through multicast (in that order). Once it finds one it
- registers itself and passes the ping object to the implementation repository with <code>server_is_running</code>
- operation. </li>
- <li>The profile returned by registration will be stored for later use.</li>
- <li>Client later can call the <code>POA::create_reference</code> operation.</li>
- <li>The <code>create_reference</code> operation will create the local profile.</li>
- <li>The stored Implementation Repository profile will have its object id changed to be the
- object key just created.</li>
- <li>Both profiles will be joined together if the multiple profile IOR policy is set, and
- then returned.</li>
-</ol>
-
-<h3><a name="HowServerProducesPersistentIORcomplex">How a server produces a Persistent IOR
-(in complex cases)</a></h3>
-
-<p>As with the default case, the server must be registered with an Implementation
-Repository, although it does not need to be multicast aware since the IORs will be passed
-to the POA by the program.
-
-<ol>
- <li><code>ORB_init</code> is called and does the default work (if it has Implementation
- Repositories to contact).</li>
- <li><code>POA::create_reference_with_virtual_server[_and_id]</code> will be called with a
- server name and list of Implementation Repositories. </li>
- <li>The profile for the object is created.</li>
- <li>The ping object created in <code>ORB_init</code> and the object key is passed to the
- Implementation Repositories, and their profiles are returned.</li>
- <li>Both profiles will be joined together if the multiple profile IOR policy is set, and
- then returned.</li>
-</ol>
-
-<h3><a name="HowClientUsesPersistentIOR">How a client uses a Persistent IOR</a></h3>
-
-<p>For all Clients:
-
-<ul>
- <li>Client obtains a Persistent Object Reference, which contains multiple profiles to both
- regular objects and Implementation Repositories.</li>
- <li>It will now make a request on the first profile.</li>
- <li>If the first profile if the server profile, and the server is still there, then it will
- be successful.&nbsp; If the server has moved (or shut down), then the next profile will be
- tried.</li>
- <li>If the first profile is the Implementation Repository, or if the server profile failed,
- then it will be contacted.&nbsp; The Implemenation Repository will then return NOT_FOUND
- or will start up the server and return a Location Forward message.</li>
-</ul>
-
-<p>If everything fails, then most clients will return failure for the request. TAO clients
-will also have added functionality where other Implementation Repositories that are
-specified on the command-line, in environment variables, or found through multicast will
-also be contacted.
-
-<ul>
- <li>If all of the profiles fail, then contact the other Implementation Repositories. First
- get those specified on the command line or in environment variables.</li>
- <li>Then, if multicast is available: <ul>
- <li>Multicast the Object Reference to a group of Implementation Repositories </li>
- <li>Wait until response or a timeout. The response will contain the Object Reference of a
- Implementation Repository that knows about the Object Reference </li>
- </ul>
- </li>
- <li>Now connect to any Implementation Repositories that have been found.</li>
- <li>Call <i>activate</i> passing the Persistent Object Reference.</li>
- <li>If a new Object Reference was sent back then retry the request using the it. If this
- request fails, then fail (no more retries).</li>
- <li>If a null reference was sent back, then fail.</li>
-</ul>
-
-<p>TAO clients will have an optimization where if there are several IORs that have the
-same server name, and one of them gets forwarded, then the client will be able to change
-its other IORs without going through the overhead of contacting Implementation Repository.</p>
-
-<hr>
-
-<p>Back to the <a href="index.html">TAO documentation</a> page.</p>
-<!--#include virtual="/~schmidt/cgi-sig.html" -->
-</body>
-</html>