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
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
|
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Microsoft FrontPage Express 2.0">
<title>TAO Implementation Repository</title>
<!-- $Id$ -->
</head>
<body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
vlink="#CC0000">
<hr>
<h1>TAO Implementation Repository </h1>
<p>Revision 3.05</p>
<hr>
<h2>Table of Contents</h2>
<ul>
<li><a href="#Changes">Recent Changes</a> </li>
<li><a href="#Overview">Overview</a> <ul>
<li><a href="#PersistentandTransientIORs">Persistent
and Transient IORs</a> </li>
<li><a href="#TheImplementationRepository">The
Implementation Repository</a> </li>
</ul>
</li>
<li><a href="#TAOsImplementationRepository">TAO's
Implementation Repository</a> <ul>
<li><a href="#VirtualServers">Virtual Servers</a> </li>
<li><a href="#PingObject">Ping Object</a></li>
<li><a href="#NewIORs">New IORs</a> <ul>
<li><a href="#WhatwaswrongwiththeoldIOR">What
was wrong with the old IOR?</a> </li>
<li><a href="#WhydoesImplRepocontainanOBJKey">Why
does the Implementation Repository
profile contain an Object Key?</a> </li>
</ul>
</li>
<li><a href="#POAExtensions">POA Extensions</a> </li>
<li><a href="#PossibleFutureGoals">Possible Future
Goals</a> </li>
<li><a href="#ServerRestrictions">Server Restrictions</a>
</li>
<li><a href="#PreliminaryInterface">Preliminary
Interface</a> </li>
</ul>
</li>
<li><a href="#AlternateImplementations">Alternate
Implementations</a> </li>
<li><a href="#AccessingtheImplementationRepository">Accessing
the Implementation Repository</a> <ul>
<li><a href="#HelperApplication">Helper Application</a>
</li>
<li><a href="#LocatinganinstanceofImplRepo">Locating
an instance of the Implementation Repository</a> <ul>
<li><a href="#Serverside">Server Side</a> </li>
<li><a href="#Clientside">Client Side</a> </li>
</ul>
</li>
</ul>
</li>
<li><a href="#Howitworks">How It Works</a> <ul>
<li><a href="#HowServerProducesPersistentIORdefault">How
a server produces a Persistent IOR (in the
default case)</a> </li>
<li><a href="#HowServerProducesPersistentIORcomplex">How
a server produces a Persistent IOR (in the
complex case)</a> </li>
<li><a href="#HowClientUsesPersistentIOR">How a
client uses a Persistent IOR</a> </li>
</ul>
</li>
</ul>
<hr>
<h2><a name="Changes">Recent Changes</a></h2>
<p>Since 3.04</p>
<ul>
<li>Moved it to the same directory as all the new</li>
<li>After a long delay (too long, if you ask me) addressed
the comments that John Mulhern <<a
href="mailto:9107@mn3.lawson.lawson.com">9107@mn3.lawson.lawson.com</a>>
sent me. </li>
</ul>
<p>Since 3.03 </p>
<ul>
<li>Added information on the new POA policy where the format
of the persistent IOR can be changed from that of both
the last-known-server-IOR and Implementation Repository
to that just of the Implementation Repository</li>
<li>TAO is now fork-safe, with the introduction of the
CLOEXEC flag through ACE_CLOEXEC.</li>
</ul>
<p>Since 3.02 </p>
<ul>
<li>Added a section to give more detailed information on how
Ping Objects work.</li>
<li>Rewrote the Virtual Server section</li>
</ul>
<hr>
<h2><a name="Overview">Overview</a></h2>
<p>This document describes the proposed design of the TAO
Implementation Repository, which was originally known as the
reactivator/activation service. If you have any questions or
comments on our design, please post them to the <a
href="http://www.cs.wustl.edu/~schmidt/ACE-mail.html">ACE</a>
mailing list <<a href="mailto:ace-useres@cs.wustl.edu">ace-users@cs.wustl.edu</a>>
or send email to Darrell Brunsch <<a
href="mailto:brunsch@cs.wustl.edu">brunsch@cs.wustl.edu</a>>.</p>
<h3><a name="PersistentandTransientIORs">Persistent and Transient
IORs</a></h3>
<p>CORBA defines two types of object references: <a
href="http://www.cs.wustl.edu/~schmidt/C++-report-col12.ps.gz">persistent
and transient</a>. The difference between the two stems from the
lifetime of the reference in relation to the lifetime of the
server process that created it. The lifetime of a transient
object reference is limited to the lifetime of its server
process. Once the server process exits the transient object
reference no longer exists. All references to this object should
now be invalid, even if the server is restarted. In contrast,
persistent object references can outlive their originating server
process. Therefore, the server can exit and be restarted without
invalidating its persistent object references. This enables the
implementation of features like automatic server activation and
object migration.</p>
<p>Note that both persistent and transient object references can
refer to objects that reside in <em>manually activated</em>
servers, <em>i.e.</em>, the so-called ``persistent servers.'' A
persistent server is a server that is launched manually, <em>i.e.</em>,
it is always running. A persistent server can generate transient
references and/or persistent references. </p>
<p>Developers should be aware that persistence of the object
reference does not imply any persistence on the object
implementation state. It is certainly possible to provide
persistent object references for objects whose state is not
persistent. Therefore, servant implementors are responsible for
preserving the state of their servants, <em>e.g.</em>, using a
database or file. </p>
<h3><a name="TheImplementationRepository">The Implementation
Repository</a></h3>
<p>According to the CORBA specification, "The Implementation
Repository contains information that allows the ORB to locate and
activate implementations of objects" [CORBA Spec Rev. 2.2:
2.1.14] In earlier revisions of the specification, there was a
method <code>get_implementation</code> in the CORBA Object
interface. This has been deprecated as of the CORBA 2.2
specification, leaving both the interface and implementation of
the Implementation Repository to the ORB vendor.</p>
<p>A good paper describing the functionality of the CORBA
Implementation Repository is "<a
href="http://www.triodia.com/staff/michi/cacm.pdf">Binding,
Migration, and Scalability in CORBA</a>" [Michi Henning].
This paper describes the following three functions of the
Implementation Repository: </p>
<ol>
<li>Maintain a registry of known servers.</li>
<li>Record which server is currently running, and which port
and host it uses.</li>
<li>Starts servers on demand if they are registered with the
Implementation Repository.</li>
</ol>
<p>The TAO Implementation Repository is based on the design in
this paper. He also wrote an earlier <a
href="http://www.triodia.com/staff/michi/binding.txt">email</a>
that may be useful to see the issues involved. The next section
details our goals and plans for the implementation.</p>
<hr>
<h2><a name="TAOsImplementationRepository">TAO's Implementation
Repository</a></h2>
<p>The following is an brief outline of TAO'S Implementation
Repository. </p>
<ul>
<li>Use of TAO's Implementation Repository will be optional.
Real-time applications can choose not to use the
Implementation Repository according to their
performance/predictability/footprint requirements.</li>
<li>Use of TAO's Implementation Repository will be invisible
to clients and servers for common use-case. For more
complicated behavior, programs can use Implementation
Repository extensions of the POA.</li>
<li>TAO's Implementation Repository will work with any CORBA
client that supports <code>LOCATION_FORWARD</code> IIOP
messages and multiple profiles in IORs, even if the
client is not implemented using TAO.</li>
<li>TAO's Implementation Repository will know if one of the
servers registered with it is running by the use of a
"ping"-like service in the server. This service
allows the Implementation Repository to know when it
should restart the server.</li>
<li>TAO will be fork-safe. Since there will be an open
connection to the client while the server is restarted
(via fork or CreateProcess) then care will be needed to
make sure that the open sockets will be closed in the
client process. The addition of CLOEXEC feature to TAO
will cover this problem.</li>
<li>TAO will exploit features of IIOP 1.1 to safely and
efficiently verify if an IOR was generated by TAO itself
on the client side. The server will still determine this
through the object key, since that is all that is passed
in a request.</li>
<li>TAO will support multiple profiles in IORs. A profile
contains the host/port and object key of a CORBA Object.
An optimization that will be possible is to have a last
known profile of the object as the first profile and an
Implementation Repository as the second profile in an
IOR. The client will first try the object to see if it
still active at the host/port before it contacts the
Implementation Repository. This strategy will reduce
latency. </li>
</ul>
<h3><a name="VirtualServers">Virtual Servers</a></h3>
<p>TAO's Implementation Repository must keep track of whether an
object's implementation is currently running or is stopped. To
have a record for every object would require too much overhead,
but having a record for every executable server would be
inflexible and prevent the migration of objects. In the Henning
paper, he mentions the use of a <em>server name</em> as the index
for the table maintained by the Implementation Repository. </p>
<p>A virtual server does not refer to the executable but instead
to a group of objects. An executable may have one or more virtual
servers within it. This allows one virtual server to be moved off
the executable to another executable (for instance, onto another
machine) without affecting the objects in other virtual servers
on the original executable. </p>
<p>Each virtual server will be indexed in the Implementation
Repository by a name that is given to it by the user. It is the
users responsibility to make sure that each virtual server name
is unique. By default, this name is the name of the executable
(since by default there is only one virtual server per
executable). However, this default behavior can be overridden. </p>
<h3><a name="PingObject">Ping Object</a></h3>
<p>Ping objects are simple objects that reside in the server, one
for every virtual server. It is contacted by the Implementation
Repository to determine if the virtual server is still running
and responding. At certain intervals the Implementation
Repository will invoke a one-way method on the ping object, and
then will expect a "pong" message to be sent back.
Different strategies for pinging (which will depend on a TAO
option) will be used by the implementation repository. If a
server is expected to be responsive, the Implementation
Repository will not wait long for a response before considering
the server to be gone. Other servers may be
computationally-intensive and need to be held under less
stringent expectations.</p>
<p>We chose the ping method to be a one-way (instead of two-way)
because if the server became unresponsive, it would not return
from the method invocation. The Implementation Repository needs
some form of a timeout with the ping to be able to determine if
the server is unresponsive or not.</p>
<h3><a name="NewIORs">New IORs</a></h3>
<p>Standard CORBA IORs contain the following two sections:</p>
<table border="1">
<tr>
<td>Type ID</td>
<td>Sequence of Tagged Profiles</td>
</tr>
</table>
<p>The Type ID is an indicator for the most derived type known at
the time of the reference creation. It is used as a hint for the
client in determining what interfaces the object can support. The
Sequence of Tagged Profiles consist of one or more profiles that
encapsulate information used by the associated protocol in order
to communicate with the object (host, port, object id, etc.).</p>
<p>Currently, TAO uses only one IIOP 1.0 Tagged Profile, which is
defined as follows:</p>
<table border="1">
<tr>
<td>Version</td>
<td>Host</td>
<td>Port</td>
<td>Object Key</td>
</tr>
</table>
<table border="0">
<tr>
<td>Object Key: </td>
<td><table border="1">
<tr>
<td>Transient/Persistent Flag</td>
<td>TimeStamp</td>
<td>POA ID</td>
<td>OBJ ID</td>
</tr>
</table>
</td>
</tr>
</table>
<p>To accomodate the Implementation Repository and IIOP 1.1, the
Profile was changed according to the CORBA specification as
follows:</p>
<table border="1">
<tr>
<td>Version</td>
<td>Host</td>
<td>Port</td>
<td>Object Key</td>
<td>Components</td>
</tr>
</table>
<table border="0">
<tr>
<td>Object Key: </td>
<td><table border="1">
<tr>
<td>TAO</td>
<td>TAO version</td>
<td>TimeStamp/Server Name</td>
<td>POA ID</td>
<td>OBJ ID</td>
</tr>
</table>
</td>
</tr>
</table>
<p>The two main changes is the addition of the Components field
(which is a IIOP 1.1 thing) and the addition of TAO with its
version. Transient object references will still have a TimeStamp
to ensure uniqueness, but persistent object references will have
a server name to identify themselves to the Implementation
Repository. </p>
<p>For servers that move around or need to be restarted often,
the IOR will contain a reference to the Implementation Repository
with the object key of the server and the server name imbedded.
Once the client contacts the Implementation Repository, it
will be forwarded to the correct object. This IOR will look like
the following:</p>
<table border="1">
<tr>
<td>Version</td>
<td>Host</td>
<td>Port</td>
<td>Object Key</td>
<td>Components</td>
</tr>
</table>
<table border="0">
<tr>
<td>Object Key: </td>
<td><table border="1">
<tr>
<td>TAO</td>
<td>TAO version</td>
<td>Server Name</td>
<td>POA ID</td>
<td>OBJ ID (actually the OBJ Key of the Server)</td>
</tr>
</table>
</td>
</tr>
</table>
<p>For servers that expect to remain in the same host/port for a
long time, the above IOR can be optimized by placing the server
profile in the IOR before the Implementation Repository
profile. TAO clients will first try the server, and if that
fails, then try the Implementation Repository. Clients from
other ORBs may behave the same way, but this isn't guaranteed
since the handling of multiple profiles is not yet in the CORBA
spec. There will be an option to only generate the IR-only IORs
for ORBs that do not support multiple profiles in the needed
manner. </p>
<p>There will be a POA policy to determine which type of
Persistent IOR to use. By default, the Implementation
Repository alone version will be used.</p>
<h4><a name="WhatwaswrongwiththeoldIOR">What was wrong with the
old IOR?</a></h4>
<p>We need a place to put a TAO marker in the IOR so TAO servers
can differentiate TAO IORs from IORs of other vendors. In the
original scheme used in TAO, Persistent IORs had a null
timestamp. To support virtual servers, we will use that slot to
store the server name so the Implementation Repository knows
which server to launch.</p>
<h4><a name="WhydoesImplRepocontainanOBJKey">Why does the
Implementation Repository profile contain an Object Key?</a></h4>
<p>It needs to know what the object key of the object when
forwarding is used. A server may contain more than one object, so
the object key is needed to forward to the correct object on the
server. </p>
<h3><a name="POAExtensions">POA Extensions</a></h3>
<p>TAO's POA will contain a new TAO-specific method called <code>create_reference_with_virtual_server[_and_id]
(...)</code>. This method takes additional arguments for a
virtual server name and a sequence of Implementation Repository
IORs. The POA will register the virtual server name with each of
the Implementation Repositories in the sequence passed in.
Several Implementation Repositories can be specified to enhance
availability through redundancy. </p>
<p>TAO's POA will also contain a policy for the type of IOR
created with <code>create_reference</code>. It can either
produce the standard type, with just a reference to the
Implementation Repository, or it can produce one also containing
a reference to the current server.</p>
<h3><a name="PossibleFutureGoals">Possible Future Goals</a></h3>
<p>The following are features that may be added to support TAO's
Implementation Repository: </p>
<ul>
<li>Optimization on TAO clients to recognize when a server is
restarted, and change all other IORs that contain the
server instead of going through the Implementation
Repository</li>
<li>Some sort of server security that checks the executable
to make sure it is the correct executable (checksum,
signatures, etc).</li>
<li>Add the ability to put servers into DLLs or Shared Object
files so the Implementation Repository can load it via
those methods.</li>
<li>GUI interface for such things as the helper application.</li>
<li>Federations of Implementation Repositories.</li>
<li>The ability to start a remote server (possibly with rsh,
ssh, rexec, etc)</li>
</ul>
<h3><a name="ServerRestrictions">Server Restrictions</a></h3>
<p>Most often servers that have Persistent IORs will save their
state to secondary storage. Databases are a good example of this,
where the server can be stopped and restarted with all the
information remaining on disk. </p>
<p>The server must also make sure it creates the POA and Object
in a way that does not change the POA ID and Object ID. The
Implementation Repository forwards requests based on the
information in the IOR; if the POA ID or Object ID changes, then
the Implementation Repository will be unable to sucessfully
forward requests. If the server implements dynamic servants and
dynamic POA activations, then this is not an issue since the
necessary POAs and servants will be created on demand.</p>
<h3><a name="PreliminaryInterface">Preliminary Interface</a></h3>
<p>The following is a proposed IDL interface for the TAO
Implementation Repository: </p>
<pre>module TAO
{
// ....
exception Already_Registered {};
// Object already bound in the Implementation Repository
exception Cannot_Activate
{
string reason_;
};
exception Not_Found {};
// Object not found in the Implementation Repository
struct Environment_Variable
{
string name_;
string value_;
};
// One environment variable
struct INET_Addr
{
unsigned short port_;
unsigned long host_;
};
// The location of a server
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 Ping_Object
{
oneway void ping ();
// Used for checking for liveness of a server. When the server receives
// this, it should send back a response indicating it is sill alive.
// Depending on the policy specified, a timeout can be reached where the
// Implementation Repository will restart the server.
};
interface Implementation_Repository
{
Object activate_object (in Object obj)
raises (Not_Found,
Cannot_Activate);
// Restart server that will contain this persistent object and return the
// new Object reference.
//
// The <Not_Found> exception is raised when <obj> is not found
// in the Implementation Repository. The <Cannot_Activate> exception
// is raised when <obj> is found in the Repository but could not be
// activated.
INET_Addr activate_server (in string server)
raises (Not_Found,
Cannot_Activate);
// Restart server that is named <server> and return the host/port
//
//
// The <Not_Found> exception is raised when <server> is not found
// in the Implementation Repository. The <Cannot_Activate> exception
// is raised when <server> is found in the Repository but could not be
// activated.
void register_server (in string server,
in Process_Options options)
raises (Already_Registered);
// Restart server process when client is looking for <server>.
//
// The <Already_Registered> exception is raised when <server> has
// already been registered with the Implementation Repository.
//
// The <Object_Not_Persistent> exception is raised when <server> is
// not a Persistent Object Reference.
void reregister_server (in string server,
in Process_Options options)
raises (Already_Registered);
// Restart server process when client is looking for <server>.
//
// The <Already_Registered> exception is raised when <server> has
// already been registered with the Implementation Repository.
//
// The <Object_Not_Persistent> exception is raised when <server> is
// not a Persistent Object Reference.
void remove_server (in string server)
raises (Not_Found);
// Remove <server> from the Implementation Repository.
//
// The <Not_Found> exception is raised when <server> is not found
// in the Implementation Repository.
Profile server_is_running (in string server,
in INET_Addr addr,
in Ping_Object ping);
// Used to notify the Implementation Repository that <server> is alive and
// well at <addr>.
void server_is_shutting_down (in string server);
// Used to tell the Implementation Repository that <server> is shutting
// down.
};
};</pre>
<hr>
<h2><a name="AlternateImplementations">Alternate Implementations</a></h2>
<p>Other ORB vendors use alternative techniques for their
Implementation Repositories. These techniques usually require new
naming techniques to access persistent object references and new
client-side APIs to bind to persistent object references. TAO's
Implementation Repository will not require such extensions. </p>
<p>A possible design alternative for the IR might use an Object
Reference that points to the Implementation Repository instead of
pointing directly to the persistent object. This extra level of
indirection would be used by the Implementation Repository to
start the server, if needed. The Location Forwarding mechanism
would then be used to forward the client request to the server.
The difference between this design and TAO's design is that the
persistent IOR in TAO will contain a profile pointing to a
location of the server (where it still might be running) to try
first, and then only if that fails does the client contact the
Implementation Repository. This is an optimization for case where
the server does not shut down often, and most requests do not
need to be forwarded to a new address.</p>
<p>In cases where most requests will require a forward, TAO can
support a policy that is just like this alternative, where the
Implmentation Repository will be contacted first.</p>
<hr>
<h2><a name="AccessingtheImplementationRepository">Accessing the
Implementation Repository</a> </h2>
<p>The Implementation Repository will be transparent to the
clients and the servers. Clients will only deal with IIOP 1.1
IORs, and in the default case all the Implementation Repository
logic on the server side will be handled internally by the ORB
and the POA. </p>
<h3><a name="HelperApplication">Helper Application</a></h3>
<p>A helper application will be included with the Implementation
Repository. It will be a command-line utility that will assist
users with adding and removing server records (containing virtual
server names and executable name/options) from the Implementation
Repository. </p>
<h3><a name="LocatinganinstanceofImplRepo">Locating an Instance
of the Implementation Repository </a></h3>
<h4><a name="Serverside">Server-side</a></h4>
<p>In the default case, the Implementation Repository will be
found via the command-line, environment variables, and multicast
(in that order). This location strategy is consistent with that
used by TAO to local its default Naming Service instance. Using
the POA extensions, other Implementation Repositories can be
specified in the call to <code>POA::create_reference_with_virtual_server</code>.
The default port of the Implementation Repository can be
overridden through command-line options or environment variables.
</p>
<h4><a name="Clientside">Client-side</a></h4>
<p>One or more Implementation Repositories will be stored in
additional profiles in the IOR. Other Implementation Repositories
can also be located by multicasting (on a default multicast
group) the server name of the Persistent Object the client is
interested in. The default multicast group and default port of
the Implementation Repository can be overridden through command
line options or environment variables. </p>
<p>In most cases, one Implementation Repository will be enough.
For redundancy, several Implementation Repositories can be
specified.</p>
<hr>
<h2><a name="Howitworks">How It Works</a></h2>
<h3><a name="HowServerProducesPersistentIORdefault">How a server
produces a Persistent IOR (in the default case)</a></h3>
<p>Before a server starts, it must be registered (via a
command-line utility) with an implementation repository. On
platforms that don't support multicast, the Implementation
Repository must be specified on the command line or in an
environment variable. </p>
<ol>
<li>When the server starts up it calls <code>ORB_init</code>.
<code>ORB_init</code>, if not passed a server name, will
take argv[0] and use that as a default server name (TAO
expects this to be the executable name). </li>
<li><code>ORB_init</code> will create a ping object.</li>
<li><code>ORB_init</code> will look for Implementation
Repositories on the command-line, environmental
variables, and then through multicast (in that order).
Once it finds one it registers itself and passes the ping
object to the implementation repository with <code>server_is_running</code>
operation. </li>
<li>The profile returned by registration will be stored for
later use.</li>
<li>Client later can call the <code>POA::create_reference</code>
operation.</li>
<li>The <code>create_reference</code> operation will create
the local profile.</li>
<li>The stored Implementation Repository profile will have
its object id changed to be the object key just created.</li>
<li>Both profiles will be joined together if the multiple
profile IOR policy is set, and then returned.</li>
</ol>
<h3><a name="HowServerProducesPersistentIORcomplex">How a server
produces a Persistent IOR (in complex cases)</a></h3>
<p>As with the default case, the server must be registered with
an Implementation Repository, although it does not need to be
multicast aware since the IORs will be passed to the POA by the
program. </p>
<ol>
<li><code>ORB_init</code> is called and does the default work
(if it has Implementation Repositories to contact).</li>
<li><code>POA::create_reference_with_virtual_server[_and_id]</code>
will be called with a server name and list of
Implementation Repositories. </li>
<li>The profile for the object is created.</li>
<li>The ping object created in <code>ORB_init</code> and the
object key is passed to the Implementation Repositories,
and their profiles are returned.</li>
<li>Both profiles will be joined together if the multiple
profile IOR policy is set, and then returned.</li>
</ol>
<h3><a name="HowClientUsesPersistentIOR">How a client uses a
Persistent IOR</a></h3>
<p>For all Clients: </p>
<ul>
<li>Client obtains a Persistent Object Reference, which
contains multiple profiles to both regular objects and
Implementation Repositories.</li>
<li>It will now make a request on the first profile.</li>
<li>If the first profile if the server profile, and the
server is still there, then it will be successful.
If the server has moved (or shut down), then the next
profile will be tried.</li>
<li>If the first profile is the Implementation Repository, or
if the server profile failed, then it will be
contacted. The Implemenation Repository will then
return NOT_FOUND or will start up the server and return a
Location Forward message.</li>
</ul>
<p>If everything fails, then most clients will return failure for
the request. TAO clients will attempt to contact other
Implementation Repositories that are specified on the
command-line, in environment variables, or found through
multicast. </p>
<ul>
<li>If all of the profiles fail, then contact the other
Implementation Repositories. First get those specified on
the command line or in environment variables.</li>
<li>Then, if multicast is available: <ul>
<li>Multicast the Object Reference to a group of
Implementation Repositories </li>
<li>Wait until response or a timeout. The response
will contain the Object Reference of a
Implementation Repository that knows about the
Object Reference </li>
</ul>
</li>
<li>Connect to the Implementation Repository that responds
first.</li>
<li>Call <i>activate</i> passing the Persistent Object
Reference.</li>
<li>If a new Object Reference was sent back then retry the
request using the it. If this request fails, then fail
(no more retries).</li>
<li>If a null reference was sent back, then fail.</li>
</ul>
<p>TAO clients will have an optimization where if there are
several IORs that have the same server name, and one of them gets
forwarded, then the client will be able to change its other IORs
without going through the overhead of contacting Implementation
Repository.</p>
<hr>
<p>Last update to this document: $Date$</p>
<p>Back to <a href="../releasenotes/">TAO Release Notes</a></p>
<p>Back to <a href="index.html">Implementation Repository</a></p>
</body>
</html>
|
