diff options
Diffstat (limited to 'TAO/docs/implrepo.html')
-rw-r--r-- | TAO/docs/implrepo.html | 679 |
1 files changed, 0 insertions, 679 deletions
diff --git a/TAO/docs/implrepo.html b/TAO/docs/implrepo.html deleted file mode 100644 index 443b247503c..00000000000 --- a/TAO/docs/implrepo.html +++ /dev/null @@ -1,679 +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.03 - July 17, 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.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://www.cs.wustl.edu/~schmidt/michi.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. This will remove a resource leak. - <!-- Darrell, do you think that the new CLOEXEC feature of TAO --> - <!-- will handle this automagically?! --> -</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> - -<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://www.cs.wustl.edu/~schmidt/michi.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 in -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 objects will have a TimeStamp to ensure uniqueness. Likewise, -persistent object will have a server name to identify them in the Implementation -Repository.</p> - -<p>For Persistent IORs, a second tagged profile will be added in TAO to point to the -Implementation Repository, 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>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 profile was meant for just calls to the Implementation Repository, then the OBJ -ID would be that of the Implementation Repository Object.</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> - -<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 with POA activation, then this is not an -issue.</p> -<!-- Darrell, can you please explain why this isn't an issue, --> -<!-- briefly?! --> - -<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. -<!-- DCS: Darrell, can you please explain how this ping() will work, i.e., --> -<!-- DCS: will it throw an exception if the server isn't live? --> -<!-- DB: Ok. But do oneways also return exceptions? --> -<!-- Darrell, no! Maybe we shouldn't make this a oneway, but make it --> -<!-- a twoway with a return value or out parameter? --> - }; - - 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 in a multiple profile IOR and 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>The full IOR is built and 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, which is the last known profile for the - object.</li> - <li>If this fails, then the next one will be tried. And if that fails, the next. One of the - other profiles will be a reference to the Implementation Repository, in which it will - either 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 can be -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> |