diff options
| author | brunsch <brunsch@ae88bc3d-4319-0410-8dbf-d08b4c9d3795> | 1999-01-24 04:38:43 +0000 |
|---|---|---|
| committer | brunsch <brunsch@ae88bc3d-4319-0410-8dbf-d08b4c9d3795> | 1999-01-24 04:38:43 +0000 |
| commit | 115c983871d62381eb06331701ea7092e6d7d422 (patch) | |
| tree | 4009c704086726fe7a5d5f479a688cc327fbe61e /TAO/docs/implrepo.html | |
| parent | b403a1ad9c10ccbdb6ed61fd732f97ba3297a55b (diff) | |
| download | ATCD-115c983871d62381eb06331701ea7092e6d7d422.tar.gz | |
Moved the IR document to the implrepo subdirectory and updated it to
address comments from John Mulhern <9107@mn3.lawson.lawson.com>.
Diffstat (limited to 'TAO/docs/implrepo.html')
| -rw-r--r-- | TAO/docs/implrepo.html | 691 |
1 files changed, 11 insertions, 680 deletions
diff --git a/TAO/docs/implrepo.html b/TAO/docs/implrepo.html index 9aa93adda3a..8263bff6d4c 100644 --- a/TAO/docs/implrepo.html +++ b/TAO/docs/implrepo.html @@ -1,681 +1,12 @@ +<HTML> <!-- $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> - -<p><a href="http://tao.cs.wustl.edu/~brunsch/implrepo.html">Implementation Repository Status</a></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 <<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://danzon.cs.wustl.edu/binding.pdf">Binding, Migration, and -Scalability in CORBA</a>" [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 "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 <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 "pong" -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. 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. - 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. 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.</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 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>. - 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<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>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. 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 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> +<HEAD> +<TITLE>IR docs have moved</TITLE> +<META HTTP-EQUIV="Refresh" CONTENT="1; URL=implrepo/index.html"> +</HEAD> +<BODY> +<P>The IR docs have moved to <A HREF="implrepo/index.html">here</A>.</P> +<P>This page should automatically redirect you there, if not, click on +the link above.</P> +</BODY> +</HTML>
\ No newline at end of file |