1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
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>
|
