diff options
Diffstat (limited to 'TAO/docs/implrepo/paper.html')
| -rw-r--r-- | TAO/docs/implrepo/paper.html | 820 |
1 files changed, 0 insertions, 820 deletions
diff --git a/TAO/docs/implrepo/paper.html b/TAO/docs/implrepo/paper.html deleted file mode 100644 index 22f8e233512..00000000000 --- a/TAO/docs/implrepo/paper.html +++ /dev/null @@ -1,820 +0,0 @@ -<html> - -<head> -<meta http-equiv="Content-Type" -content="text/html; charset=iso-8859-1"> -<meta name="GENERATOR" content="Microsoft FrontPage Express 2.0"> -<title>TAO Implementation Repository</title> -<!-- $Id$ --> -</head> - -<body bgcolor="#FFFFFF" text="#000000" link="#0000FF" -vlink="#CC0000"> - -<hr> - -<h1>TAO Implementation Repository </h1> - -<p>Revision 3.05</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.04</p> - -<ul> - <li>Moved it to the same directory as all the new</li> - <li>After a long delay (too long, if you ask me) addressed - the comments that John Mulhern <<a - href="mailto:9107@mn3.lawson.lawson.com">9107@mn3.lawson.lawson.com</a>> - sent me. </li> -</ul> - -<p>Since 3.03 </p> - -<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 </p> - -<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 <<a href="mailto:ace-useres@cs.wustl.edu">ace-users@cs.wustl.edu</a>> -or send email to Darrell Brunsch <<a -href="mailto:brunsch@cs.wustl.edu">brunsch@cs.wustl.edu</a>>.</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, "The Implementation -Repository contains information that allows the ORB to locate and -activate implementations of objects" [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 "<a -href="http://www.triodia.com/staff/michi/cacm.pdf">Binding, -Migration, and Scalability in CORBA</a>" [Michi Henning]. -This paper describes the following three functions of the -Implementation Repository: </p> - -<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. He also wrote an earlier <a -href="http://www.triodia.com/staff/michi/binding.txt">email</a> -that may be useful to see the issues involved. 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. </p> - -<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 - "ping"-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 Henning -paper, he mentions the use of a <em>server name</em> as the index -for the table maintained by the Implementation Repository. </p> - -<p>A virtual server does not refer to the executable but instead -to a group of objects. An executable may have one or more virtual -servers within 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 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 "pong" message to be sent back. -Different strategies for pinging (which will depend on a TAO -option) 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>The two main changes is the addition of the Components field -(which is a IIOP 1.1 thing) and the addition of TAO with its -version. Transient object references will still have a TimeStamp -to ensure uniqueness, but persistent object references will have -a server name to identify themselves to the Implementation -Repository. </p> - -<p>For servers that move around or need to be restarted often, -the IOR will contain a reference to the Implementation Repository -with the object key of the server and the server name imbedded. - Once the client contacts the Implementation Repository, it -will be forwarded to the correct object. This IOR will look like -the following:</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>For servers that expect to remain in the same host/port for a -long time, the above IOR can be optimized by placing the server -profile in the IOR before the Implementation Repository -profile. TAO clients will first try the server, and if that -fails, then try the Implementation Repository. 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. There will be an option to only generate the IR-only IORs -for ORBs that do not support multiple profiles in the needed -manner. </p> - -<p>There will be a POA policy to determine which type of -Persistent IOR to use. 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 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>. 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: </p> - -<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<Environment_Variable> Environment; - // Complete environment - - typedef sequence<string> 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 <Not_Found> exception is raised when <obj> is not found - // in the Implementation Repository. The <Cannot_Activate> exception - // is raised when <obj> 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 <server> and return the host/port - // - // - // The <Not_Found> exception is raised when <server> is not found - // in the Implementation Repository. The <Cannot_Activate> exception - // is raised when <server> 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 <server>. - // - // The <Already_Registered> exception is raised when <server> has - // already been registered with the Implementation Repository. - // - // The <Object_Not_Persistent> exception is raised when <server> 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 <server>. - // - // The <Already_Registered> exception is raised when <server> has - // already been registered with the Implementation Repository. - // - // The <Object_Not_Persistent> exception is raised when <server> is - // not a Persistent Object Reference. - - void remove_server (in string server) - raises (Not_Found); - // Remove <server> from the Implementation Repository. - // - // The <Not_Found> exception is raised when <server> 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 <server> is alive and - // well at <addr>. - - void server_is_shutting_down (in string server); - // Used to tell the Implementation Repository that <server> 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>A possible design alternative for the IR might use an Object -Reference that points to the Implementation Repository instead of -pointing directly to the persistent object. This extra level of -indirection would be used by the Implementation Repository to -start the server, if needed. The Location Forwarding mechanism -would then be used 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. </p> - -<ol> - <li>When the server starts up it calls <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. </p> - -<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: </p> - -<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. - 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. 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 attempt to contact other -Implementation Repositories that are specified on the -command-line, in environment variables, or found through -multicast. </p> - -<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>Connect to the Implementation Repository that responds - first.</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>Last update to this document: $Date$</p> - -<p>Back to <a href="../releasenotes/">TAO Release Notes</a></p> - -<p>Back to <a href="index.html">Implementation Repository</a></p> -</body> -</html> |