diff options
Diffstat (limited to 'TAO/docs/forwarding.html')
-rw-r--r-- | TAO/docs/forwarding.html | 90 |
1 files changed, 90 insertions, 0 deletions
diff --git a/TAO/docs/forwarding.html b/TAO/docs/forwarding.html new file mode 100644 index 00000000000..82301a47905 --- /dev/null +++ b/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> + |