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
|
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="GENERATOR" CONTENT="Mozilla/4.04 [en] (X11; I; SunOS 5.5.1 sun4u) [Netscape]">
<TITLE>TAO Release Information and TODO List</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF">
<!-- $Id$ -->
<CENTER>
<HR></CENTER>
<CENTER>
<H3>
Release Information for The ACE ORB (TAO)</H3></CENTER>
Information is available on the following topics related to the <A HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/VERSION">current
release</A> of <A HREF="http://www.cs.wustl.edu/~schmidt/TAO.html">TAO</A>:
<UL>
<LI>
<A HREF="orbcore.html">ORB Core</A></LI>
<LI>
<A HREF="#idl">IDL Compiler</A></LI>
<LI>
<A HREF="#poa">Portable Object Adapter</A></LI>
<LI>
<A HREF="#nservices">CORBA Naming Service</A></LI>
<LI>
<A HREF="ec.html">CORBA Event Service</A></LI>
<LI>
<A HREF="#tservices">CORBA Trading Service</A></LI>
<LI>
<A HREF="#pservices">CORBA Property Service</A></LI>
<LI>
<A HREF="#cservices">CORBA Concurrency Control Service</A></LI>
<LI>
<A HREF="#logging">CORBA Logging Service</A></LI>
<LI>
<A HREF="#implrepo">Implementation Repository</A></LI>
<LI>
<A HREF="#av">CORBA Audio/Video Control Service</A></LI>
<LI>
<A HREF="#apps">Test & Example Applications</A></LI>
<LI>
<A HREF="#ace">ORB-related ACE Changes</A></LI>
<LI>
<A HREF="#dove">The DOVE Demo</A></LI>
<LI>
<A HREF="#forwarding">Location forwarding</A></LI>
<LI>
<A HREF="#leader">Global resources and leader-follower model</A></LI>
<LI>
<A HREF="#locate">Locate requests</A></LI>
<LI>
<A HREF="TODO.html">Our TODO list</A></LI>
</UL>
A complete list of all modifications to TAO is available in the <A HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/ChangeLog">ChangeLog</A>.
<P>
<HR><!--#include virtual="orbcore.html" -->
<HR>
<H3>
<A NAME="idl"></A>IDL Compiler</H3>
Point of contact: <A HREF="mailto:gokhale@cs.wustl.edu">Aniruddha Gokhale</A>
<P>Current status: (As of July 31st, 1998.)
<UL>
<LI>
Anonymous arrays inside structs are supported. However, they are not yet
supported inside unions.</LI>
<LI>
Perfect Hashed Operation Lookup Strategy has been added to the IDL Compiler.
-P flag to the <tao_idl>enables the perfect hased lookup strategy.
This strategy uses <A HREF="http://www.cs.wustl.edu/~schmidt/gperf.ps.gz">GPERF</A>,
the GNU's Perfect Hash Function Generator written by Dr.Douglas C. Schmidt.
Right now, GPERF works only on Solaris. Any work on porting GPERF to other
platforms will be highly appreciated. </L1></LI>
<LI>
Support for Arrays is refined in terms of the code generated for parameters
inside stubs and skeletons.</LI>
<LI>
Significantly improved the support for unions. The default case is yet
to be handled.</LI>
<LI>
Added support for Arrays. Right now, support for typedefed arrays is in.
Still needs testing.</LI>
<LI>
Added support for TIE classes. If the interfaces are defined inside modules,
then the TIE class and its code gets generated inside a conditional macro.
For platforms that support namespaces, this macro will allow these TIE
classes else they get commented out. The reason to do this is because nested
templates have problems on most compilers.</LI>
<LI>
The <<= and >>= operators for user-defined types are now generated.</LI>
<LI>
Completely redesigned the IDL compiler using the Visitor patterns. Many
incomplete issues have been resolved. These include support for "sequence
of typecodes", passing object references as in, inout, and out parameters.
Code generation for sequences is also properly handled i.e., for a named
sequence such as "typedef sequence <char>CharSeq;", we now generate
a new class (and hence a type) called "class CharSeq". Arrays are still
being worked out and will be done soon. An important difference in the
generated code is that the skeletons now use a table driven approach very
similar to the stubs.</LI>
<LI>
Support for the "native" keyword added.</LI>
<LI>
Introduced tests for object references to TAO. Still incomplete.</LI>
<LI>
Param_Test example is able to test string sequences, fixed structs, variable
sized structs and nested structs</LI>
<LI>
Param_Test test suite can now test fixed structs and string sequences.This
needed bug fixes to TAO ORB core.</LI>
<LI>
A new test to test all the parameter passing modes for a number of data
types has been added. At this point in time, it tests primitive types and
strings. Other tests will be added. Bugs discovered thru these tests have
been fixed.</LI>
<LI>
Very preliminary support for arrays. Not working yet.</LI>
<LI>
Many bugs associated with stub generation fixed. This included support
for return values that are variable sized IDL types. Unions improved.</LI>
<LI>
Support for sequences of strings and object references added. However,
it is not tested yet so there may be some bugs. We should have these fixed
in a day or so.</LI>
<LI>
Support for handling exceptions added. TAO does not use direct C++ exceptions.
Instead it uses the CORBA::Environment based approach.</LI>
<LI>
Sequences as out parameters have been tested in the IDL_Cubit example.
A test suite is currently being built to test all the parameter passing
modes on a variety of IDL data types.</LI>
<LI>
Support for attributes completed. Not tested yet.</LI>
<LI>
The problem of incorrect code generation for typedefs defined in an imported
file is resolved.</LI>
<LI>
Problems when interfaces use single or multiple inheritance solved. The
problem was with the demultiplexing code, the generated operation tables,
and the dispatching mechanism. We are currently testing this with the Event
Channel code.</LI>
<LI>
The problems arising due to public virtual inheritance when casting from
an interface class to CORBA::Object_ptr has been solved. We do this casting
inside the stubs/skeletons rather than first converting an interface class
pointer to a void*, storing it in an Any, and casting it to CORBA::Object_ptr
in the encode/decode methods. The casting inside the stubs/skeletons work
because the compiler has knowledge of both types.</LI>
<LI>
The compiler generates correct code for COSS Naming service and it runs
properly. Correct code also gets generated for the Event Channel program</LI>
<LI>
Include files are handled properly. So are the definitions used inside
the include files that are used in the currently parsed files.</LI>
<LI>
IN, INOUT, and OUT object reference parameters are now supported properly.
We think the same approach should work for sequences, structs, and unions.</LI>
<LI>
Many IDL constructs supported including primitive types, typedefs, sequences,
structures, and unions.</LI>
<LI>
Generates C++ stubs and skeletons that use TAO's <A HREF="http://www.cs.wustl.edu/~schmidt/HICSS-97.ps.gz">interpretive
IIOP protocol engine</A>.</LI>
<LI>
Generated code closely follows the C++ Mapping specified in the POA Specification
(ORBOS/97-05-15).</LI>
<LI>
Support dynamic libraries on NT, i.e., marking classes for DLL export was
added. Two backend options control the name of the export macro, and the
name of an extra include file were the macro is defined; the options are
<TT>-Wp,export_macro=MACRO_NAME</TT> <TT>-Wp,export_include=INCLUDE_NAME</TT>.</LI>
<LI>
The IDL compiler generates now source code for sequences. The user has
now the option to use these generated sequence classes or to use, as up
to now, the template instatiation. If TAO_LACKS_TEMPLATE_SPECIALIZATION
is defined, then template instantiation will be used, else not. The reason
for this was, that some C++ compilers did not support template instantiation
properly and sequences were based on templates. The generated source code
is mainly contained in the generated header file directly in the class
declaration.</LI>
</UL>
Known bugs/unimplemented constructs:
<UL>
<LI>
Generation of Managed types must somehow be moved to the ORB Core</LI>
<LI>
We need support for ``TIEs'' (i.e., the object form of the Adapter pattern).</LI>
<LI>
TypeCode generation for multidimensional arrays and indirected typecodes
is still a problem.</LI>
<LI>
Unions with default cases yet to be handled</LI>
<LI>
Deal with names in the IDL definition that are C++ keywords.</LI>
<LI>
IDL is case-insensitive. However, it looks like our front-end is case-sensitive.
Thanks to Anil Gopinath (anil@ittc.ukans.edu) for pointing this out.</LI>
<LI>
tao_idl generates code for a *.idl file only inside the directory where
the *.idl resides. However, it may be required to generate code elsewhere
i.e., in the directory where the compiler was invoked. Thanks to Tom Richards
(tomr@MCMEnterprise.com) for this suggestion.</LI>
</UL>
Future work:
<UL>
<LI>
Need to relocate the various libraries used by the IDL compiler out of
the ACE directory. Having them here can cause problems when working with
multiple versions of TAO and a single version of ACE.</LI>
<LI>
Improve IDL compiler to generate compiled form of stubs/skeletons.</LI>
<LI>
Fix bugs in the SunSoft IDL front-end we've uncovered. These primarily
include support for Unions.</LI>
<LI>
Add command line options to TAO IDL. These options will decide what strategy
to use for operation name demultiplexing. Another option may decide whether
to use the interpretive IIOP engine or generate compiled stubs/skeletons.</LI>
<LI>
Use <A HREF="http://www.cs.utah.edu/projects/flux/flick/">Flick</A> (from
the University of Utah) to generate compiled stubs.</LI>
<P>Goal is to measure the code size of the interpretive stubs generated
by TAO IDL compiler <I>vs</I> code size of compiled stubs. Then compare
the performance of each. We want to prove the thesis that TAO IDL compiler
generated interpretive stubs have a small code size, yet are comparable
in performance (or slightly less) than compiled stubs. Hence, it will be
useful for small distributed equipment such as handsets, PDAs, etc.
<P>In doing the above, improvements to the IIOP protocol engine in terms
of size/performance/determinism will be made.
<LI>
Tweak the IDL compiler to generate code that's more easily integrated back
into the ORB Core, e.g., POA, etc. This will depend largely on our ability
to generalize the changes necessary to generated code.</LI>
</UL>
<LI>
The generated sequence classes should not be generated per sequence, but
per type and parent scope. Which means, that the overhead of having the
source code generated serveral times should be reduced. To do this, an
extra pass over the internal representation of the IDL file has to be done.
<HR></LI>
<H3>
<A NAME="poa"></A>Portable Object Adapter</H3>
Point of contact: <A HREF="mailto:irfan@cs.wustl.edu">Irfan Pyarali</A>
<P>Current Status:
<UL>
<LI>
TAO fully supports the POA spec. This section will carry updates as available.</LI>
</UL>
Known issues:
<DL>
<DT>
<I>Support for collocation is not complete.</I></DT>
<DD>
If an object which should be collocated is created via <TT>string_to_object</TT>,
it is created as a remote object rather than collocated.</DD>
</DL>
Critical work:
<UL>
<LI>
None.</LI>
</UL>
Future work:
<UL>
<LI>
Determine the degree to which we will support the full semantics of remote
objects on a collocated object. The spec mandates that collocated object
should behave <I>exactly</I> like remote objects, but that means that request
will have to be queued rather than calling a method directly, and this
could be hazardous to our quest for real-time ORB status.</LI>
<LI>
Provide extensions of the specification to ensure real-time delivery of
messages.</LI>
</UL>
<HR><!--#include virtual="ec.html" -->
<HR>
<H3>
<A NAME="nservices"></A>CORBA Naming Service</H3>
Point of contact: <A HREF="mailto:sergio@cs.wustl.edu">Sergio Flores-Gaitan</A>
and <A HREF="mailto:marina@cs.wustl.edu">Marina Spivak</A>
<P>Current status (as of Feb 27th):
<UL>
<LI>
The Naming Service implementation is complete.</LI>
</UL>
Future work:
<UL>
<LI>
Currently the bindings are stored as a table in memory. Future work will
include a persistent database to store the bindings.</LI>
<LI>
Replication of the bindings to other Naming Service's currently running.
It will probably be modeled after the LDAP Multi-Master Replication Protocol.
For more information on this replication protocol please read <A HREF="ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldap-mult-mast-rep-02.txt">LDAP
Multi-Master Replication Protocol</A></LI>
</UL>
For general documentation on the Naming Service please read <A HREF="ftp://www.omg.org/pub/docs/formal/97-07-12.pdf">The
Naming Service Specification</A>.
<P>
<HR>
<H3>
<A NAME="tservices"></A>CORBA Trading Service</H3>
Point of contact: <A HREF="mailto:sbw1@cs.wustl.edu">Seth Widoff</A>
<P>The TAO Trading Service is a transient implementation of the COS Trading
Service speficiation that meets the Linked Trader conformance criteria
--- it implements the <TT>Lookup</TT>, <TT>Register</TT>, <TT>Admin</TT>,
and <TT>Link</TT> interfaces, but not the <TT>Proxy</TT> interface. Notably,
the TAO trader supports the following features:
<UL>
<LI>
Multithreaded operation;</LI>
<LI>
Trader federations and distributed queries;</LI>
<LI>
Dynamic properties;</LI>
<LI>
Modifiable properties;</LI>
<LI>
All policies described in the specification;</LI>
<LI>
Preference sorting;</LI>
<LI>
Service type inheritance hierarchies and subtype searching.</LI>
</UL>
<A HREF="trader.html">Trading Service documentation</A> is also available.
<P>Future Work:
<UL>
<LI>
The Proxy Interface.</LI>
<LI>
Persistent storage of service types and offers.</LI>
</UL>
For general documentation of the Trading Service, please read <A HREF="http://www.omg.org/corba/sectrans.htm#trader">The
Trading Service Specification.</A>
<P>
<HR>
<H3>
<A NAME="pservices"></A>CORBA Property Service</H3>
Point of contact: <A HREF="mailto:alex@cs.wustl.edu">Alexander Babu Arulanthu</A>
<P>Current status (as of May 02, 1998)
<BR>
<BR>All the interfaces of this service have been implemented. Please
go through the test examples at $TAO/orbsvcs/tests/CosPropertyService.
Property Service is now used by the AVStreams that is currently being
developed for TAO. More testing is being done.
<P>For general documentation of the Property Service, please read <A HREF="http://www.omg.org/corba/sectrans.htm#prop">The
Property Service Specification.</A>
<P>
<HR>
<H3>
<A NAME="implrepo"></A>Implementation Repository</H3>
Point of contact: <A HREF="mailto:brunsch@cs.wustl.edu">Darrell Brunsch</A>
<P>Current status (as of July 23, 1998)
<P>Here is a brief list of my goals (and the dates completed). For more
information, please see the <A HREF="../implrepo.html">Implementation Repository
documentation</A>.
<UL>
<LI>
Create the base test client and server programs [7/17]</LI>
<LI>
Add an IR that forwards server requests [7/23]</LI>
<LI>
Have the server register its IOR with the IR</LI>
<LI>
Have the server exit after every call, so it is restarted each time</LI>
<LI>
Add the ping object to the server</LI>
<LI>
Add in shutdown calls to test ping objects</LI>
<LI>
Change IOR format</LI>
<LI>
Add in support for server names</LI>
<LI>
Make the IR forward any request</LI>
<LI>
Add another server</LI>
</UL>
Other goals:
<UL>
<LI>
Implement the IDL Interface for the IR</LI>
<LI>
Move this stuff into the POA</LI>
<LI>
Multiple Profiles</LI>
<LI>
POA extension</LI>
<LI>
Persistence</LI>
</UL>
Future Goals:
<UL>
<LI>
TAO client-side optimization with restarted servers</LI>
<LI>
Server security (checksums)</LI>
<LI>
Helper Application</LI>
<LI>
Federation of IRs</LI>
<LI>
DLLs</LI>
</UL>
<HR>
<H3>
<A NAME="cservices"></A>CORBA Concurrency Control Service</H3>
Point of contact: <A HREF="mailto:tworm@cs.wustl.edu">Torben Worm</A>
<P>Current status (as of May 3rd):
<UL>
<LI>
A simple version of the concurrency service has been implemented, i.e.
a version without transactions. It is currently being tested.</LI>
</UL>
Future Work:
<UL>
<LI>
Implementation of the Concurrency Control Service with transactions</LI>
</UL>
For general documentation of the Concurrency Control Service, please read
<A HREF="http://www.omg.org/corba/sectrans.htm#concur">The Concurrency
Control Service Specification.</A>
<P>
<HR>
<H3>
<A NAME="logging"></A>CORBA Logging Service</H3>
Point of contact: <A HREF="mailto:mjb2@cs.wustl.edu">Matt Braun</A>
<P>Current status (as of August 4'th):
<UL>
<LI>
The basic logging service has been implemented. It can log basic messages
from multiple clients. It is currently in the testing stage.</LI>
</UL>
Future work:
<UL>
<LI>
Add increased functionality. Requests and suggestions are welcome.</LI>
</UL>
<HR WIDTH="100%">
<H3>
<A NAME="av"></A>CORBA Audio/Video Control Service</H3>
Point of contact: <A HREF="mailto:sumedh@cs.wustl.edu">Sumedh Mungee</A>
and <A HREF="mailto:naga@cs.wustl.edu">Nagarajan Surendran</A>
<P>This is an implementation of the OMG spec addressing the <A HREF="http://www.cs.wustl.edu/~sumedh/research/corbaav.pdf">Control
and Management of Audio/Video Streams</A>.
<P>The audio/video streaming service has been implemented in the light
profile. An MPEG-1 application which streams mpeg-1 video and mpeg-1 audio
separately has been developed using the service. This application currently
works only for Unix platforms.
<P>Current Status:
<UL>
<LI>
Implemented the handshake mechanism between the consumer and supplier of
the stream.</LI>
<LI>
Implemented a simple version of the stream controller (StreamCtrl).</LI>
<LI>
Implemented the VDev and StreamEndPoint base class functionality.</LI>
<LI>
Implemented the MMDevice interface, which is a factory for StreamEndPoint
and VDev objects.</LI>
<LI>
Implemented a mpeg-1 streaming audio/video application using the a/v service.</LI>
</UL>
Work in progress:
<UL>
<LI>
Implementing the SFP protocol</LI>
<LI>
Integrating the mpeg-1 streaming application with the trading service.</LI>
</UL>
<HR>
<H3>
<A NAME="apps"></A>Test & Example Applications</H3>
Point of contact: <A HREF="mailto:naga@cs.wustl.edu">Nagarajan Surendran</A>
<P>Current Status:
<P>The TAO IDL_Cubit test application makes use of the Naming Service and
the server holds a TAO_Naming_Server component.Just running server and
client is enough to test the application.
<P>The various tests in the tests/POA test the different features of the
Portable Object Adapter interface like Explicit Activation, On Demand Activation,etc..
<P>Future work:
<P>Developing a one-buttoned test for all the different TAO tests similar
to the ACE-one buttoned test.
<P>MT_Cubit:
<P>Current status:
<P>The TAO MT_Cubit test application is meant to serve as a starting point
for real-time tests on the TAO system. It comprises the following parts:
<UL>
<LI>
<I>Server.</I> The server creates multiple CORBA objects (servants), each
with different real-time priorities. This priority is implemented by using
real-time thread support provided by the operating system. Thus, requests
sent to a high-priority servant are handled by a high-priority real-time
thread, and those sent to a lower priority servant are handled by correspondingly
lower priority threads.</LI>
<LI>
<I>Client.</I> The client component binds to the servants, and sends a
stream of CORBA requests to the servants. It measures the response time,
i.e. the time taken for the request to complete successfully. In particular,
it measures the time taken for requests sent to the high priority servant
to complete. The volume of lower priority requests is configurable. The
client is thus able to measure the performance of the high-priority servant
in the presence of competition from several lower-priority servants.</LI>
</UL>
Clearly, if the ORB endsystem handles the priorities of the various requests
correctly, increasing the volume of lower priority requests should not
affect the performance seen by the higher priority requests. The application
thus serves as a tool to measure and confirm this behavior.
<P>Future work:
<UL>
<LI>
Study the impacts of scheduling & concurrency strategies on performance.</LI>
<LI>
Evolve into a testbed for discovering sources of performance non-determinism
& priority inversion.</LI>
</UL>
<HR>
<H3>
<A NAME="ace"></A>ORB-related ACE Changes</H3>
Points of contact: <A HREF="mailto:nanbor@cs.wustl.edu">Nanbor Wang</A>
and <A HREF="mailto:irfan@cs.wustl.edu">Irfan Pyrarli</A>
<P>Recently Completed Work:
<UL>
<LI>
Added special declaration to OS.h for <TT>inet_ntoa</TT> and other functions
because VxWorks doesn't provide full argument prototypes for these library
functions.</LI>
<LI>
The current caching connector behaves properly in the face of a non-blocking
connect request. The "fix" is simply to not support non-blocking connects
through the cache. When the <TT>connect()</TT> fails with <TT>EWOULDBLOCK</TT>,
morph the error to -1 and clean up the request.</LI>
<LI>
Service handlers obtained from the caching connector are now cleaned up.
The application needs to be able to signal that it's not using it any longer,
and, when the application encounters an error, needs to effectively close
down that connection for good so that a new connection can be initiated.</LI>
<BR>Added the ability for a Svc_Handler to recycle itself. idle() can be
called when the Svc_Handler is done serving a particular connection and
can how be recycled. The Svc_Handler now also has a pointer to a recycler
that is responsible for managing the connections. The recycler is usually
a Cached_Connector.
<BR>Added new class ACE_Recycling_Strategy. It defines the interface (and
default implementation) for specifying a recycling strategy for a Svc_Handler.
This strategy acts as a consular to the Svc_Handler, preparing it for the
tough times ahead when the Svc_Handler will be recycled.
<BR>Added new class ACE_NOOP_Concurrency_Strategy. It implements a no-op
activation strategy in order to avoid calling open on a recycled svc_handler
multiple times.
<BR>ACE_Cached_Connect_Strategy now implements the ACE_Connection_Recycling_Strategy
interface. This allows Svc_Handlers to cache themselves with ACE_Cached_Connect_Strategy
when they become idle. It also allows them to purge themselves from the
connection cache when the Svc_Handlers close down.
<BR>Also added ~ACE_Cached_Connect_Strategy that will cleanup up the connection
cache.</UL>
Future work:
<BLOCKQUOTE><I>None currently scheduled.</I></BLOCKQUOTE>
<HR>
<H3>
<A NAME="dove"></A>The DOVE Demo</H3>
Point of contact: <A HREF="mailto:mk1@cec.wustl.edu">Michael Kircher</A>.
<P><A HREF="http://www.cs.wustl.edu/~schmidt/dove.html">DOVE</A> is
documented in detail <A
HREF="http://www.cs.wustl.edu/~schmidt/DOVE_and_LifeCycleService.ps.gz">online</A>.
This discussion focuses on the following goals:<P>
<UL>
<LI>
Have a DOVE Browser running using Java Beans as vizualization components.</LI>
<LI>
Have the Event Channel as DOVE Agent running with an Event Consumer in
the DOVE Browser.</LI>
<LI>
Having a DOVE Management Information Base (MIB), which dumps all events
transfered on the Event Channel into a file on persistent storage for later
reuse.</LI>
</UL>
The DOVE Browser uses independent visualization components (Java Beans)
and the Event Channel as DOVE Agent. Connections can be established between
monitored metrics and the visualization components.
<P>We have three major components: Observables (monitored metrics),
Observers (a Java Bean for displaying the metric) and a DataHandler
(for demultiplexing the monitored metrics to the appropriate
Observables). Each component inherits from a base class, so that a
certain behavior of the components can be assured for each
component. Relationships between components are based on these base
classes.
<P>The used Java Beans are required to conform to some standards, as
they have to support a function called "getProperty" which allows the
DOVE Browser to determine if the vizualization capabilities of a
specific Java Bean are sufficient to display the metric. A JavaBean is
for example a Java Panel which shows a Graph of the delivered
doubles. So all metrics can be displayed by this visualization
component which can be expressed by a single double.
<P>The DataHandler is connected to the Event Push Consumer (PUSH,
because we use the push concept of the Event Service). The Event Push
Consumer does not know what kind of data is transported. The only
component knowing all the details about the dependencies of the
metrics is the DataHandler. This separation allows easy extension and
change of the demo.
<P><A HREF="http://students.cec.wustl.edu/~mk1/dove.html">Object Diagrams</A>
are available about this new concept.
<P>Event Service events are used as communication between DOVE
Applications and the DOVE Browser. The DOVE MIB analyses the event
data field of all events and stores this information into a file. The
event data filed is of type CORBA::Any and the DOVE MIB has no notion
of what is conveyed in this field. So the DOVE MIB has to discover the
content via the embedded type code information. Future work includes:
<UL>
<LI>
Enhancing MIB functionality</LI>
<LI>
Monitoring the AV Streaming Service</LI>
</UL>
<HR>
<H3>
<A NAME="forwarding"></A>Location forwarding</H3>
Point of contact: <A HREF="mailto:irfan@cs.wustl.edu">Irfan Pyarali</A>,
<A HREF="mailto:mk1@mk1.wustl.edu">Michael Kircher</A>.
<P>For more information see <A HREF="../forwarding.html">Location forwarding</A>
<HR>
<H3>
<A NAME="leader"></A>Global resources and leader-follower model</H3>
Point of contact: <A HREF="mailto:irfan@cs.wustl.edu">Irfan Pyarali</A>,
<A HREF="mailto:mk1@mk1.wustl.edu">Michael Kircher</A>.
<P>For more information see <A HREF="../leader_follower.html">Leader-follower
model</A>
<HR>
<H3>
<A NAME="locate"></A>Implementation of locate request</H3>
Point of contact: <A HREF="mailto:irfan@cs.wustl.edu">Irfan Pyarali</A>,
<A HREF="mailto:mk1@mk1.wustl.edu">Michael Kircher</A>.
<P>For more information see <A HREF="../locate_request.html">Locate request</A>
<HR>
<P>Back to the TAO <A HREF="../index.html">documentation index</A>. <!--#include virtual="/~schmidt/cgi-sig.html" -->
</BODY>
</HTML>
|
