Merge pull request #1917 from jwillemsen/jwi-redefinedfallthrough
[ACE_TAO.git] / TAO / docs / forwarding.html
blob8f9093dff3d85e498deed860dddd17ff4f9d6f84
1 <html>
2 <!-- -->
3 <head>
4 <title>Implementation of location forwarding</title>
5 </head>
7 <BODY text = "#000000"
8 link="#0000ff"
9 vlink="#cc0000"
10 bgcolor="#ffffff">
12 <body>
13 <HR>
14 <h1>Location forwarding</h1>
15 <HR>
16 <h2>Context</h2>
18 The motivation to support location forwarding for objects is
19 to allow objects to move or forward certain requests to
20 other objects. Moving of objects is very important for the
21 Common Object Services LifeCycle Service. An object
22 complying to the LifeCycleObject interface, defined by the
23 LifeCycle Service should support the move() operation. The
24 move() operation allows the client to keep its object
25 reference to the object, but the object is going to be
26 relocated on the same or a different server. Making
27 location forwarding transparent to the client is the most
28 important issue.
30 <h2>Communication between server and client</h2>
32 GIOP defines a message named "LOCATION_FORWARD", which
33 should be used to inform the client stub, that the object
34 has been moved. The message body has to contain an object
35 reference to the new location of the forwarded object.
37 <h2>Server side implementation</h2>
39 Two approaches are possible, one is to use a POA servant
40 locator and the other is to use a servant activator.
42 <h2>Client side implementation</h2>
44 The client has to expect the location forwarding GIOP
45 message and should respond to it in setting the Profile of
46 its Object right.
48 <h2>Conclusion</h2>
50 Changing the Profile is transparent to the client. So the
51 client gets no idea that the object now resides somewhere
52 else.
54 The result of the above mentioned solution is that if an
55 object moves the client will notice it with the next call to
56 the object. If the object moves again, the original location
57 is not bothered at all again. Say if the original location
58 was A, then it moved to B and finally to C. First location A
59 responded with a GIOP Location Forward to the client, then B
60 gets used and finally after moving the object to C, B will
61 send a GIOP Location Forward and location C gets used.
63 There is "no" concept of a home location. If the object
64 moves very often and old servers die it might be a problem,
65 because clients, which did not call on the object lately
66 will not know where to search. Though in the situation of a
67 home location, there is also the risk that this server might
68 die and the object is not reachable any more.
70 <h2>Optimization</h2>
72 In the case, when the object moves several times, a chain of
73 forwarding servers is created. But this chain might be
74 easily disturbed by just one server failing. A good idea is
75 to give the servant locator more intelligence to tell all
76 the other/previous servers where the object is now. This
77 will of course increase the communication overhead in the
78 case of a move, but we get a high reliability against dying
79 hosts.
81 <HR>
82 For more details and questions,
83 <p>
85 <address><a href="mailto:mk1@cs.wustl.edu">Michael Kircher</a></address>
86 <p>
87 <address><a href="mailto:irfan1@cs.wustl.edu">Irfan Pyarali</a></address>
88 </body>
89 </html>