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
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
|
<html>
<head>
<title>
TAO Reactivation Service
</title>
</head>
<BODY text = "#000000"
link="#0000ff"
vlink="#cc0000"
bgcolor="#ffffff">
<hr>
<h3>
TAO Reactivation Service
</h3>
This document describes the proposed design of the TAO reactivator.
If you have any comments or suggestions for improvement, please let <A
HREF="mailto:schmidt@cs.wustl.edu">me</A> know. <P>
<hr>
<h3>
Goals of the Reactivation Service
</h3>
The Reactivation Service will add support to TAO's architecture so
that servers using Persistent Object References (defined in the
Portable Object Adapter (POA) specification) can be restarted. This
service will allow servers to come and go without invalidating the
Persistent Object References that they use.
<h3>
Constraints when using the Reactivation Service
</h3>
<ul>
<li>
When a server is restarted by the Reactivation Service, it must be
able to recreate enough state to deal correctly with the request
issued by a client on the Persistent Object Reference. Therefore, the
restarted server's endpoint must be the same endpoint specified in the
Persistent Object Reference. Unless dynamic servant and POA activation
is used, the restarted server must also recreate the POA in which the
Persistent object was registered and register the persistent object
with that POA.
<li>
The Reactivation Service will track all processes it has restarted. It
will ensure that multiple instances of same server processes are not
started simultaneously.
<li>
The use of the Reactivation Service in TAO will be optional. Real-time
applications can choose not to use the Reactivation Service.
</ul>
<h3>
Alternate Implementations
</h3>
Other ORB vendors use alternative techniques for Activation /
Reactivation Services. These techniques usually require new naming
techniques for persistent objects and new client-side APIs to bind to
persistent objects. TAO's Reactivation Service will not require such
extensions.
<p>
One implementation of an Activation / Reactivation Service is to use
an Object Reference that points to the Activation Service instead of
pointing directly to the persistent object. This extra level of
indirection is used by the Activation Service to start the server, and
then use the Location Forwarding mechanism to forward the client
request to the server. This technique forces clients to use the
Activation Service (at least once) even when the server is already
running.
<p>
<h3>
Design Constraints of the Reactivation Service
</h3>
This design makes TAO dependent on the Reactivation Service.
<p>
<hr>
<h2>
Implementation
</h2>
Here is a preliminary interface of the Reactivation Service in IDL:
<code><pre>
module TAO
{
// ....
exception Already_Registered {};
// Object already bound in the Reactivator
exception Object_Not_Persistent {};
// Object is not persistent
exception Not_Found {};
// Object not found in the Reactivator
struct Environment_Variable
{
string name_;
string value_;
};
// One environment variable
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 Reactivator
{
boolean reactivate_object (in Object obj)
raises (Not_Found);
// Restart server that will contain this persistent object
//
// The <Not_Found> exception is raised when <obj> is not found
// in the Reactivation Service.
void register_object (in Object obj,
in Process_Options options)
raises (Already_Registered,
Object_Not_Persistent);
// Restart server process when client is looking for <obj>.
//
// The <Already_Registered> exception is raised when <obj> has
// already been registered with the Reactivation Service.
//
// The <Object_Not_Persistent> exception is raised when <obj> is
// not a Persistent Object Reference.
enum Host_Port_Options
{
NONE,
HOST,
PORT,
HOST_AND_PORT
};
// NONE: Use no information from the Object Reference
//
// HOST: Use the host information taken from the Object
// Reference (-ORBhost)
//
// PORT: Use the port information taken from the Object
// Reference (-ORBport)
//
// HOST_AND_PORT: Use both the host and port information from
// the Object Reference (-ORBport) and (-ORBhost)
void register_object_using_info_in_ior (in Object obj,
in Process_Options options,
in Host_Port_Options host_port_options)
raises (Already_Registered,
Object_Not_Persistent);
// Restart server process <executable_name> when client is
// looking for <obj>. Depending on the <host_port_options>,
// information from the <obj> object reference is used to
// specify (-ORBport) and (-ORBhost) options for the server.
void reregister_object (in Object obj,
in Process_Options options)
raises (Not_Found,
Object_Not_Persistent);
void reregister_object_using_info_in_ior (in Object obj,
in Process_Options options,
in Host_Port_Options host_port_options)
raises (Not_Found,
Object_Not_Persistent);
// The above reregister methods are similar to the register
// methods except they are used for rebinding.
void remove_object (in Object obj)
raises (Not_Found);
// Remove <obj> from the Reactivation Service.
//
// The <Not_Found> exception is raised when <obj> is not found
// in the Reactivation Service.
};
};
</pre></code>
<hr>
<h2>
Accessing the Reactivation Service
</h2>
Servers can use either of the following techniques to get access to
the Reactivation Service. Remember that the Reactivation Service will
be transparent to the clients.
<ul>
<li>
Use ORB::resolve_initial_reference ("TAO Reactivation Service")
<br>
This works like the bootstrapping mechanism to obtain the Naming
Service. This method will return the reference to a Reactivation
Service.
<p>
<li>
Use a Helper Application
<br>
A helper application will be part of the Reactivation Service. It
will be a command-line utility that will assist users with adding and
removing Persistent Object References from the Reactivation Service.
<p>
</ul>
<h3>
Locating an instance of Reactivation Service
</h3>
<h4>
Server side
</h4>
The Reactivation Service will be located on the same host as the
server. If not, host information can be specified through command
line options or environment variables. The default port of the
Reactivation Service can be overwriting through command line options
or environment variables.
<h4>
Client side
</h4>
The correct Reactivation Service will be located by multicasting (on a
default multicast group) the Persistent Object Reference the client is
interested in. The default multicast group can be overwriting through
command line options or environment variables. If multicasting is not
preferred, the location of a the Reactivation Service will be assumed
to be the same as the Persistent Object. The default port of the
Reactivation Service can be overwriting through command line options
or environment variables.
<hr>
<h2>
Reactivation algorithm used on the Client Side
</h2>
<ul>
<li>
Client obtains an Object Reference
<li>
Then it makes a request on the Object Reference. If the IOR has
multiple Object References, then it will try all of the Object
References until one succeeds
<li>
If all of the Object References fail, then for each Object Reference
in the IOR, the following steps will be taken to reactivate the
server
<li>
The ORB examines the Object Reference
<li>
If it is a Transient Object Reference, then the call fails
<li>
If multicast is available:
<ul>
<li>
Multicast the Object Reference to a group of Reactivation Services
<li>
Wait until response or a timeout. The response will contain the
Object Reference of a Reactivation Service that knows about the Object
Reference
<p>
</ul>
<li>
If no multicast:
<ul>
<li>
Extract the host from the Persistent Object Reference
<li>
Manufacture an Object Reference for the Reactivation Service
<p>
</ul>
<li>
Now connect to the Reactivation Service
<li>
Call <i>reactivate ()</i> passing the Persistent Object Reference
<li>
Reactivation service sends back a yes / no response
<li>
If "yes", retry the request using the Persistent Object Reference
again. If request fails, then fail (no more retries)
<li>
If "no", then fail
</ul>
<hr><P>
Back to the <A
HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/docs/index.html">TAO
documentation</A> page.
<!--#include virtual="/~schmidt/cgi-sig.html" -->
</BODY>
</html>
|
