1 files changed, 90 insertions, 0 deletions
diff --git a/trunk/TAO/docs/forwarding.html b/trunk/TAO/docs/forwarding.html
new file mode 100644
index 00000000000..82301a47905
--- /dev/null
+++ b/trunk/TAO/docs/forwarding.html
@@ -0,0 +1,90 @@
+<html>
+  <!-- $Id$ -->
+  <head>
+    <title>Implementation of location forwarding</title>
+  </head>
+  
+  <BODY text = "#000000"
+    link="#0000ff"
+    vlink="#cc0000"
+    bgcolor="#ffffff">
+    
+    <body>
+      <HR>
+	<h1>Location forwarding</h1>
+	<HR>
+	  <h2>Context</h2>
+
+	  The motivation to support location forwarding for objects is
+	  to allow objects to move or forward certain requests to
+	  other objects.  Moving of objects is very important for the
+	  Common Object Services LifeCycle Service. An object
+	  complying to the LifeCycleObject interface, defined by the
+	  LifeCycle Service should support the move() operation. The
+	  move() operation allows the client to keep its object
+	  reference to the object, but the object is going to be
+	  relocated on the same or a different server.  Making
+	  location forwarding transparent to the client is the most
+	  important issue.
+	  
+	  <h2>Communication between server and client</h2>
+
+	  GIOP defines a message named "LOCATION_FORWARD", which
+	  should be used to inform the client stub, that the object
+	  has been moved. The message body has to contain an object
+	  reference to the new location of the forwarded object.
+	  	  
+	  <h2>Server side implementation</h2>
+
+	  Two approaches are possible, one is to use a POA servant
+	  locator and the other is to use a servant activator. 
+	  
+	  <h2>Client side implementation</h2>
+
+	  The client has to expect the location forwarding GIOP
+	  message and should respond to it in setting the Profile of
+	  its Object right.	  
+	  
+	  <h2>Conclusion</h2>
+
+	  Changing the Profile is transparent to the client. So the
+	  client gets no idea that the object now resides somewhere
+	  else.
+	  	  
+	  The result of the above mentioned solution is that if an
+	  object moves the client will notice it with the next call to
+	  the object. If the object moves again, the original location
+	  is not bothered at all again. Say if the original location
+	  was A, then it moved to B and finally to C. First location A
+	  responded with a GIOP Location Forward to the client, then B
+	  gets used and finally after moving the object to C, B will
+	  send a GIOP Location Forward and location C gets used.
+
+	  There is "no" concept of a home location. If the object
+	  moves very often and old servers die it might be a problem,
+	  because clients, which did not call on the object lately
+	  will not know where to search. Though in the situation of a
+	  home location, there is also the risk that this server might
+	  die and the object is not reachable any more.
+
+	  <h2>Optimization</h2>
+
+	  In the case, when the object moves several times, a chain of
+	  forwarding servers is created. But this chain might be
+	  easily disturbed by just one server failing. A good idea is
+	  to give the servant locator more intelligence to tell all
+	  the other/previous servers where the object is now.  This
+	  will of course increase the communication overhead in the
+	  case of a move, but we get a high reliability against dying
+	  hosts.
+ 
+	  <HR>
+	    For more details and questions,
+	    <p>
+	      
+	      <address><a href="mailto:mk1@cs.wustl.edu">Michael Kircher</a></address>
+	      <p>
+		<address><a href="mailto:irfan1@cs.wustl.edu">Irfan Pyarali</a></address>
+    </body>
+</html>
+