| blob | b4d8c117dedad82a04588730e7141ba53020b649 |
2 <html>
3 <head>
7 </head>
9 <!-- -->
10 <center>
11 <hr></center>
13 <center>
14 <h3>
15 Release Information for The ACE ORB (TAO)</h3></center>
16 This document contains information on the following topics related to the
21 <tr>
24 <br>
25 <ul>
26 <li>
28 </ul>
29 </td>
33 <br>
34 <ul>
36 <li>
40 <li>
43 <li>
45 </ul>
46 </td>
48 </table>
51 <tr>
54 <br>
55 <ul>
56 <li>
59 <li>
62 <li>
65 <li>
68 <li>
71 <li>
74 <li>
77 <li>
80 <li>
83 <li>
85 <li>
90 <li>
93 <li>
96 <li>
99 <li>
103 <li>
106 <li>
109 <li>
113 <li>
116 <li>
119 <li>
122 <li>
124 </ul>
127 <br>
128 <ul>
129 <li>
131 <li>
133 <li> Event Service
134 <ul>
135 <li>
137 <li>
139 <li>
141 </ul>
143 <li>
146 <li>
150 <li>
152 <li>
153 Notification Service
154 <ul>
155 <li>
157 <li>
159 </ul>
160 <li>
162 <li>
164 <li>Scheduling Service
165 <ul>
166 <li>
168 <li>
170 </ul>
172 <li>
175 <li>
177 <li>
179 <li>
184 </ul>
185 </td>
188 </td>
189 </tr>
190 </table>
194 <tr>
197 </table>
200 A complete list of all modifications to TAO is available in the <a href="../../ChangeLogs">ChangeLogs</a>.
201 <p>
202 <hr>
203 <h3>
206 <ul>
207 <li>
208 The following changes are related to improving memory management of Event
209 Handlers when they interact with Reactors (and Timer Queues). When a handler
210 is registered with the Reactor, the Reactor increments the reference count
211 on the handler. The Reactor also increments this reference count when making
212 upcalls on the handler. The reference count is decremented when an upcall
213 completes or when the handler is removed from the Reactor.</li>
215 <p>This mechanism is similar to what happens between POAs and Servants
216 and it allows for the safe deletion of handlers. This mechanism is particularly
217 need for multi-threaded applications that can have multiple threads executing
218 upcalls on a handler that needs to be shutdown in a safe manner. The following
219 illustrates an example of how this mechanism works:
220 <ul>
221 <li>
222 When a handler is created, it reference count is one.</li>
224 <li>
225 After the handler is registered with the Reactor, it reference count becomes
226 two.</li>
228 <li>
229 At this point, the handler creator can let go of the handler reference,
230 bringing down the reference count to one.</li>
232 <li>
233 For each thread executing upcalls on the handler, the Reactor increments
234 the reference count by one. So if three threads were simultaneously making
235 upcalls on a handler, the reference count would be four.</li>
237 <li>
238 Assuming an external event (and thread) decides to close the handler. It
239 simply removes the handler from the Reactor. This decreases the reference
240 count to three.</li>
242 <li>
243 As each thread completes their upcall, the reference reduces.</li>
245 <li>
246 Once the final thread exits the upcall, the reference reaches zero, and
247 the handler is finally deleted.</li>
248 </ul>
249 This mechanism ensures that the handler is not deleted until the final
250 upcall thread exits the handler.
251 <p>Reference counting on handlers is optional and is disabled by default.
252 To enable reference counting on a handler, reset its reference counting
253 policy to "ENABLED".
254 <p>To facilitate reference counting of handlers, an ACE_Event_Handler_var
255 class was added. This class is akin to the PortableServer::ServantBase_var
256 class.
257 <p>Similar reference counting related changes were made to the Timer Queues
258 so that handlers can be used in a thread safe manner with the queues.
259 <p>The Connector implementation was completely revised to utilize the new
260 memory management mechanisms and remove existing concurrency bugs.
261 <p>Several new examples/tests were added: Reference_Counted_Event_Handler_Test,
262 MT_Reference_Counted_Event_Handler_Test, MT_Reference_Counted_Notify_Test,
263 Timer_Queue_Reference_Counting_Test, NonBlocking_Conn_Test, Reactor_Registration_Test,
264 WFMO_Reactor_Test, Timer_Cancellation_Test</ul>
266 <hr>
267 <h3>
271 <ul>
272 <li>
273 Generated code closely follows the C++ Mapping specified in the latest
276 <li>
277 IDL compiler is now able to generate code that support native C++ exceptions
278 on the stubs and skeletons. With this strict mapping, the CORBA::Environment
279 parameter is no longer generated. The default behavior is to generate code
280 without the extra parameter on plaforms with native exceptions and with
281 the extra parameter in platforms without native exceptions. Use the -Ge
282 flag to override the defaults.</li>
284 <li>
285 We are now able to handle shared case labels and default label in unions.
286 In addition, whenever appropriate, we are also able to generate the "default
289 <li>
290 We are now able to handle recursive types. We are also able to generate
291 optimized typecodes.</li>
293 <li>
294 Struct members of type strings and arrays of strings now use the managed
295 type instead of the _var type. This change was necessary to conform to
298 <li>
299 Fixed a large number of problems with anonymous arrays and sequences inside
300 structs and unions. The name of anonymous sequence needs to be fixed as
301 per latest C++ mapping spec.</li>
303 <li>
304 Compile problems with sequence of forward declared interfaces is fixed.
305 In addition, problems with sequence of CORBA::Objects is fixed. In this
306 specific case, we were not generating the _downcast and _upcast methods.</li>
308 <li>
309 Some more problems with the front-end have been fixed. In particular, oneway
311 mode is flagged as an error.</li>
313 <li>
314 For platforms that support namespaces, we now allow reopening modules.</li>
316 <li>
317 Support for generating compiled marshaling code is added. Use the -Gc option.
318 However, this needs thorough testing before we can claim success. Unions
319 are still a problme with compiled marshaling.</li>
321 <li>
322 The problem of "#include"ing the relative path of the header files rather
323 than the paths of their corresponding IDL files has been fixed. tao_idl
324 now generates #include path names that are derived from the IDL files that
325 are #include'd in the main idl file.</li>
327 <li>
328 Added options to IDL compiler to specify file name endings for the IDL-generated
329 stubs, skeletons and the various header files. Please refer to the <a href="../compiler.html">IDL
332 <li>
335 emulation through ACE_U_LongLong.</li>
337 <li>
338 Perfect Hashed Operation Lookup Strategy has been added to the IDL Compiler.
341 the GNU's Perfect Hash Function Generator written by Dr.Douglas C. Schmidt.
342 Right now, GPERF works only on Solaris. Any work on porting GPERF to other
343 platforms will be highly appreciated.</L1></li>
345 <li>
348 <li>
349 Completely redesigned the IDL compiler using the Visitor patterns. Many
350 incomplete issues have been resolved. These include support for "sequence
351 of typecodes", passing object references as in, inout, and out parameters.
352 Code generation for sequences is also properly handled i.e., for a named
354 a new class (and hence a type) called "class CharSeq". Arrays are still
355 being worked out and will be done soon. An important difference in the
356 generated code is that the skeletons now use a table driven approach very
357 similar to the stubs.</li>
359 <li>
362 <li>
363 The problem of incorrect code generation for typedefs defined in an imported
364 file is resolved.</li>
366 <li>
367 Problems when interfaces use single or multiple inheritance solved. The
368 problem was with the demultiplexing code, the generated operation tables,
369 and the dispatching mechanism. We are currently testing this with the Event
370 Channel code.</li>
372 <li>
373 The problems arising due to public virtual inheritance when casting from
374 an interface class to CORBA::Object_ptr has been solved. We do this casting
375 inside the stubs/skeletons rather than first converting an interface class
376 pointer to a void*, storing it in an Any, and casting it to CORBA::Object_ptr
377 in the encode/decode methods. The casting inside the stubs/skeletons work
378 because the compiler has knowledge of both types.</li>
380 <li>
381 Include files are handled properly. So are the definitions used inside
382 the include files that are used in the currently parsed files.</li>
384 <li>
385 Generates C++ stubs and skeletons that use TAO's
389 <li>
390 Support dynamic libraries on NT, i.e., marking classes for DLL export was
391 added. Two backend options control the name of the export macro, and the
392 name of an extra include file were the macro is defined; the options are
395 <li>
396 The IDL compiler generates now source code for sequences. The user has
397 now the option to use these generated sequence classes or to use, as up
398 to now, the template instatiation. If TAO_LACKS_TEMPLATE_SPECIALIZATION
399 is defined, then template instantiation will be used, else not. The reason
400 for this was, that some C++ compilers did not support template instantiation
401 properly and sequences were based on templates. The generated source code
402 is mainly contained in the generated header file directly in the class
403 declaration.</li>
405 <li>
406 The IDL Compiler generates templates for servant implementations. The options
407 are -GI [ h | s | b | e | c ]</li>
409 <li>
410 The IDL compiler generates source code for the management and (de)marshaling
411 of wide characters and wide strings, enabling the sending and receiving
412 of Unicode over the wire. However, wide character and wide string literals
413 are not yet portable to Unix platforms (see entry under Future Work below).</li>
415 <li>
416 Since the CORBA spec requires that all enums be 32 bits, and some compilers
417 will try to use less space if the enum values are small enough, the IDL
419 to every enum. This appended enum value is not part of the IDL compiler's
420 internal representation of the enum, so unions that use the enum as a discriminator
421 will not have incorrect _default() code generated for them.</li>
423 <li>
424 The IDL compiler generates a C++ ostream operator for IDL exceptions. So
425 far only the repository ID is output, but this may be enhanced when requirements
426 and/or desires become clearer.</li>
428 <li>
429 The IDL compiler has support for valuetypes (see release notes
430 for valuetypes for details). </li>
432 <li>
433 As part of the implementation of interceptors, the TAO IDL compiler now
434 generates interception points in the client and server, as well as the
435 prepare_header method in the stubs.</li>
437 <li>
438 Scoping and name resolution rules have changed in CORBA with version 2.3.
439 The IDL compiler now conforms to these new rules.</li>
441 <li>
442 IDL compiler now supports the CORBA AMI callback model, generating code
443 for reply handlers and reply stubs if the -GC command line option is used.
444 The TAO library must be compiled with TAO_HAS_CORBA_MESSAGING = 1. If this
445 is done, TAO_HAS_AMI_CALLBACK will automatically be defined to 1 as well.
448 <li>
449 New command line option -So added to suppress generation of ostream operators
450 for exceptions.</li>
452 <li>
453 New command line option -Sc added to suppress generation of tie classes
454 and *S_T.* files. The default is still to generate them.</li>
456 <li>
457 IDL compiler now handles escaped identifiers (CORBA 2.3.1). An identifier
458 appearing in an IDL file with a leading underscore will appear in generated
459 code without the underscore. This enables the use of identifiers in generated
460 code identical to IDL keywords, as specified in CORBA 2.3.1. If the resulting
461 identifier matches a C++ keyword, "_cxx_" will be prepended in generated
462 code as before.</li>
464 <li>
465 The -St option to suppress generation of typecodes now also suppresses
466 the generation of the Any insertion and extraction operators. The extraction
467 operators require the associated typecode, so the generated code for those
468 operators would not compile when the -St option was used.</li>
470 <li>
471 Option -Ge 2 added which generates 'throw' instead of ACE_THROW_SPEC, ACE_THROW,
472 and ACE_RETHROW. Since the expansion of ACE_THROW_RETURN is platform-dependent,
473 it was left as is. Same for TAO_INTERCEPTOR_THROW, since it sometimes expands
474 to ACE_THROW_RETURN. Of course ACE_HAS_EXCEPTIONS must be defined for this
475 option to work.</li>
477 <li>
478 Removed generation of ostream operators for user exceptions, along with
479 the command line option to suppress this generation. The ostream operator
480 defined in the base class CORBA::Exception works fine and produces the
481 same output.</li>
483 <li>
484 The TAO IDL compiler is no longer monolithic. It is composed of a top-level
485 executable, a front end library and a back end library. This will enable
486 different back ends to be plugged in for code generation in different languages,
487 and for IfR administration. Different back ends may require a few changes
488 to the executable (described below), but the front end library can remain
489 unchanged. The chain of dependencies is as follows:</li>
491 <blockquote>FE : ACE
492 <br>BE : FE
494 Executing the Makefile (or the TAO_IDL Compiler project in the MSVC 'tao_idl'
495 workspace) will build whatever is required in the proper order, as before.
496 Back end files, classes and functions required by the executable are as
497 follows:
498 <blockquote>be.h - file containing #includes of the major BE file headers.
499 <br>TAO_Codegen - class, holds output stream references for the various
500 generated files.
501 <br>TAO_CODEGEN - ACE_Singleton typedef of the above class.
502 <br>tao_cg - pointer to instance of TAO_CODEGEN.
503 <br>be_generator - class, inherits from AST_Generator in FE and generates
504 AST nodes.
505 <br>void BE_produce (void) - global function, starts AST traversal for
506 code generation.
507 <br>BE_GlobalData - class, holds default/command line arg settings specific
508 to BE.
510 All the code in the executable that may need to be modified for different
511 back ends in contained in the file drv_args.cpp. Code in this file processes
512 the command line arguments, outputs a usage message, and performs other
513 miscellaneous BE initialization.
514 <li>
515 The IDL compiler can how handle interfaces forward declared in one IDL
516 file and defined in another. It will handle interfaces that are mutually
517 dependent across two IDL files, as long as code generated from both IDL
518 files is included in the same C++ build.</li>
520 <li>
521 Generation of template tie class declarations has been moved from the *S.h
522 file to the *S_T.h file. The new SunCC 5.2 compiler does not require that
523 template source code be included in the header file, but it does require
524 that template declarations and implementations be in the same 'compilation
525 unit' that is, the same header/source file combination. Generated ifdef
526 guards prevent the compilation of tie class code if the target platform
527 does not support namespaces. For such platforms, TAO maps the IDL 'module'
528 keyword to a class instead of to 'namespace', and C++ does not allow template
529 class declarations to occur inside another class.</li>
531 <li>
532 IDL compiler can now process multiple IDL files per execution, on all platforms.
533 A separate process is spawned for each file. IDL files and command line
534 options may appear in any order on the command line. Any option not starting
535 with '-' will be treated as a filename.</li>
537 <li>
538 Support for value types has been expanded to include forward declared value
539 types, sequences of value types, and factory methods. Also, work to support
540 Anys and type codes for value types is in progress.</li>
542 <li>
543 Support for #pragma prefix has been revamped and improved to be compliant
544 (the prefix is now cleared when leaving the scope or the included IDL file
545 where it was defined), and support for #pragma version and #pragma ID has
546 been added.</li>
548 <li>
549 Support for forward declared structs and unions has been added. In compliance
550 with CORBA 2.6, such forward declarations must be fully defined in the
551 same compilation unit, and may be used only in sequence declarations, which
552 in turn may be used in the declaration of recursive structs and unions.
553 Use of a forward declared struct or union as an aggregate type member or
554 as an operation parameter will generat an error message.</li>
556 <li>
557 Support for enum constants has been added.</li>
559 <li>
560 The IDL compiler can now handle concatenation of string literals, for example</li>
564 <li>
565 Support for abstract interfaces has been added.</li>
567 <li>
568 Support for valuetypes has been expanded.</li>
570 <ul>
571 <li>
572 Forward declared valuetypes not defined in the same compilation unit</li>
574 <li>
575 Type codes for valuetypes</li>
577 <li>
578 Generation of Any insertion/extraction operators</li>
580 <li>
581 Abstract valuetypes</li>
583 <li>
584 Valuetype members of all IDL aggregate types</li>
586 <li>
587 Interface supports list</li>
588 </ul>
590 <li>
591 Support for the CCM extensions to IDL, which first appeared in CORBA 3.0
592 is complete, with the exception of support for the 'import' keyword.</li>
594 <li>
595 Generated code for constants defined in a module is now inlined
596 (value is assigned in the header file) by default, enabling such
597 constants to be referenced by name as array bounds, etc. either in
598 subsequent generated code or in application code. However, this inlining causes
599 a problem with some compilers when using pre-compiled headers, so the
600 option -Guc has been added to turn it off. NOTE: Constants
601 defined at global scope (always inlined) and constants defined inside an
602 interface or a valuetype (never inlined) are not affected by the option.
603 </li>
605 <li>
606 Generation of explicit template instantiations is now off by default. The
607 option -GT turns it on. If turned on, the generated explicit instantiations
608 are guarded by the same #ifdef preprocessor directives as before.
609 </li>
611 <li>
612 The mechanism for processing multiple IDL files in a single execution has
613 changed. Instead of spawning a separate process for each IDL file, the
614 IDL compiler now processes the files sequentially in a single process.
615 Note that, for each file, execution of the preprocessor spawns a new
616 process, as it always has.
617 </li>
619 <li>
620 Added command line option -Sm to suppress the action of CCM preprocessing
621 visitor, which is by default launched before the C++ generating visitors,
622 in order to add CCM equivalent IDL to the AST. There is a new tool in CIAO
623 which converts IDL files by replacing IDL3 constructs with equivalent IDL2
624 constructs, and if the IDL compiler is run on these files, we do not want
625 the CCM preprocessing to occur.
626 </li>
628 <li>
629 Changed the behavior of the -o option to create the specified directory
630 if it does not already exist. Only one level of directory can be created
631 with this option (any path prefix included must already exist).
632 If the specified directory already exists, no action is taken.
633 </li>
635 <li>
636 As part of the subsetting in TAO of Anys and TypeCodes, the generation of
637 these things in the IDL compiler has been further decoupled from other
638 code generation. Now the -GA option generates not only a *A.cpp file but
639 also a *A.h file, and in addition, the -oA option will create these files
640 in a directory different from that where the other generated files are
641 created.</li>
643 <li>
644 Generation of explicit template instantiations has been completely
645 removed, it is no longer available via the command line option -GT.</li>
647 <li>
648 Generation of Any insertion/extracion operators for local interfaces
649 has been enabled by default. An additional command line option -Sal
650 has also been added to suppress the generation of Any operators for
651 local interfaces only.</li>
653 <li>
654 Added new command line option -oS to specify output directory for
655 all skeleton files, including TIE class files, if generated. Overrides
656 -o option value, if any.</li>
658 <li>
659 Uninlined all generated TIE class code, since inlining could potentially
660 cause a problem for RTTI.</li>
662 <li>
664 an explicit export of each sequence's template base class. This is
665 occasionally necessary as a workaround for a bug in Visual Studio
667 used for the base class isn't automatically exported. See
671 </ul>
673 <h4>
674 Known Issues:</h4>
676 <ul>
677 <li>
678 With Microsoft Visual C++, verison 6.0 and earlier, a problem has been
679 discovered when the IDL compiler is built using the Release version of
680 the MSVC project. For the Release version, the Optimizations box in the
681 C/C++ tab has 'Maximize Speed' selected. This setting turned out to cause
682 a problem when</li>
684 <p>const char *foo = ......
685 <p>occurs in the source code. The variable foo is sometimes not allocated
686 or assigned properly, and if foo is part of generated code, it will then
687 display as garbage or as an empty string (or substring). Two workarounds
688 have been found. One is to change the declaration of foo to be
689 <p>static const char *foo = ....
690 <p>and this has been done in all cases we could find in the IDL compiler
691 source code. Another way to avoid the problem is to change the Release
692 project Optimization setting to 'Minimize Size'. Reportedly the problem
693 has been fixed in MSVC version 7.0.
695 </ul>
697 <h4>
698 Future work:</h4>
700 <ul>
701 <li>
703 specification. Originally implemented solely for use in holding exceptions
705 work is now ongoing to extend TAO's OBV implementation until it includes
706 the complete CORBA value type specification. Some of the items yet to be
707 implemented include:</li>
709 <ul>
710 <li>
711 Boxed value types</li>
713 <li>
714 Custom marshaling</li>
716 <li>
717 Truncation</li>
719 <li>
720 Marshaling of complex state (graphs with cycles)</li>
722 </ul>
723 For a complete description of value type semantics, see chapter 5 in the
724 CORBA specification.
725 <li>
726 The generated sequence classes should not be generated per sequence, but
727 per type and parent scope. Which means, that the overhead of having the
728 source code generated several times should be reduced. To do this, an
729 extra pass over the internal representation of the IDL file has to be done.</li>
731 <li>
732 Updated and portable support for wide characters and wide strings. The
733 original implementation supports Unicode only. At the time, the CORBA specification
734 required wide characters, whether standalone or in a wide string, to be
735 marshaled as 16-bit quantities. This is the same size as the native wchar_t
736 type on Win32 platforms. However, the wchar_t type on UNIX and related
737 platforms is 32 bits in size. In addition, the General Inter-ORB Protocol
738 (GIOP) version 1.2 has changed the CDR transfer syntax for wide characters.
739 In the new version, a wide character is marshaled as a single byte indicating
740 the size of the wide character representation, followed by the specified
741 nunber of bytes. The IDL compiler's handling of wide characters needs to
742 be updated, both to handle the GIOP 1.2 CDR transfer syntax, and to be
743 portable under previous versions of GIOP. For more information about GIOP
744 CDR transfer syntax, see section 15.3 in the CORBA specification. and for
745 information about the marshaling of IDL character types specifically, see
748 </ul>
751 <hr>
752 <h3>
757 define general interfaces, and (4) provide necessary mechanisms for implementing
758 different concrete ORB and transport protocols. TAO's pluggable protocol
759 framework will allow disparate communication mechanisms to be supported
760 transparently, each with its own set of requirements and strategies.
761 <p>For example, if the ORB is communicating over a system bus, such as
762 PCI or VME, and not all the features of GIOP/IIOP are necessary and a simpler,
763 optimized ORB and transport protocol can be defined and implemented. Similarly,
764 it should be straightforward to add support for new transport protocols
765 that use native ATM or shared memory as the underlying communication mechanism.
766 In all cases the ORB's interface to the application will remain compliant
767 with the OMG CORBA standard.
770 example transport protocols, such as ATM and VME, and refine/optimize the
771 transport protocols framework, and (4) add support for pluggable ORB protocols,
772 e.g., replacements for GIOP. Each of these steps is outlined below:
773 <ul>
774 <li>
776 Bridge classes that decouple the transport-specific details from the rest
777 of TAO's ORB Core. This allows us to isolate the details of how messages
778 are communicated at the transport layer in a few classes. This design resulted
779 in the restructuring of the ORB Core and how requests are handled. For
780 instance, there is now the concept of communication layers: Objects (e.g.,
781 references, method invocations, etc.), ORB Messaging, Transport, and Network.
782 The Object layer is just the usual stubs and skeletons.</li>
784 <p>The common interfaces have been defined in the new abstract classes
785 that form the core of TAO's pluggable protocol framework, e.g.,
790 transport protocols are the
793 which are essentially Abstract Factories that produce the right types of
794 connector, acceptors, and transports.
795 <li>
797 This is important since there may be several different ways to access an
798 object. Each profile for an object may encode information pertaining to
799 QoS, network and transport protocols, addresses or routes.</li>
801 <li>
803 protocols are distributed with TAO:</li>
805 <ol>
806 <li>
807 UIOP: GIOP over local IPC (UNIX domain sockets)</li>
809 <li>
810 SHMIOP: GIOP over shared memory</li>
812 <li>
813 SSLIOP: GIOP over SSL (Secure Socket Layer)</li>
815 <li>
816 SCIOP: GIOP over SCTP</LI>
818 <li>
819 COIOP: GIOP collocated only. Will only work in a collocated environment, no remote calls are possible</li>
821 <li>
822 DIOP: GIOP over UDP/IP unicast</li>
824 <li>
825 MIOP: GIOP over UDP/IP multicast</li>
826 </ol>
827 Other interesting transport protocols could be for ATM, Buses (VME or PCI),
828 TP4, and GSMP. TAO users have also created their own pluggable transport
829 protocols, such as a ScramNet pluggable protocol.
830 <li>
832 besides GIOP. In particular, we will explore lightweight protocols using
833 shared memory and system buses like PCI or VME.</li>
834 </ul>
835 Current Status:
836 <ul>
837 <li>
838 The basic framework to support pluggable transport protocols has been completed.
844 using the new framework.</li>
846 <li>
847 Multiple endpoint support in the ORB has been added. A list of TAO_Acceptors
848 is kept in the Acceptor Registry. When the ORB needs to create an IOR it
849 iterates over all the acceptors to do so. Using either multiple <tt><a href="../ORBEndpoint.html">-ORBEndpoint</a></tt>
850 options or several endpoints separated by semi-colons ';', the user can
851 specify what addresses the ORB should use. Each endpoint is specified in
853 to support different protocols.</li>
855 <li>
856 If the user does not specify a list of endpoints then the ORB creates a
857 default endpoint for each protocol configured, unless the pluggable protocol
858 explicitly prevents that in an effort to prevent resource leaks.</li>
860 <li>
861 Added support for multiple Connectors in the ORB, the ORB finds the correct
862 connector based on the tag for the profile.</li>
864 <li>
865 Added support for multiple profiles in the IORs, when the ORB demarshals
866 an IOR it queries the Connector Registry to create the right kind of profile
867 for the known protocols. If one of the protocols is unknown we create a
868 special profile class that can only be used for marshaling and demarshaling,
869 not communication.</li>
871 <li>
872 Enabled the UIOP protocol. This protocol uses local IPC (aka UNIX domain
873 sockets) as the transport mechanism. The protocol is loaded by default.</li>
875 <li>
876 Enabled the SHMIOP protocol. This protocol uses shared memory as the transport
877 mechanism. The protocol is loaded by default.</li>
879 <li>
880 An IIOP over SSL pluggable transport called "SSLIOP" has been implemented.
881 It provides secure communication between hosts that support IIOP over SSL,
882 and is meant to be a drop-in replacement for the IIOP pluggable transport.
883 TAO's SSLIOP pluggable transport implementation supports both the standard
884 IIOP transport protocol and the secure IIOP over SSL transport protocol.</li>
886 <p>No changes were made to the core TAO sources to provide to this SSL
887 support, nor does TAO contain any security related hooks. TAO's SSLIOP
888 implementation is completely self-contained. This ensures that the core
889 TAO sources remains free of export restrictions.
890 <li>
891 Protocols can be dynamically loaded into the ORB: The default resource
892 factory reads the protocol "names" from its list of arguments. These protocol
893 names are used to load an abstract factory via the service configurator.
894 This factory can create acceptors or connectors on demand. By default only
895 IIOP is loaded.</li>
897 <li>
898 The service configurator is now used to load protocol factories.</li>
900 <li>
903 supersedes them, and provides the same functionality in a protocol-neutral
907 <li>
910 this option will be removed from future releases.</li>
912 <li>
913 The URL style object reference format has been updated to conform with
915 is:</li>
947 prevent ambiguities of where the rendezvous point ends and where the key
949 URL format may also be used.
950 <p>It should be noted that these formats have been superseded by the new
953 <li>
955 that the ORB has permission to read and write to. However, UIOP rendezvous
956 points have the same restrictions that local IPC has. The following are
957 some guidelines that will help ensure successful use TAO's UIOP pluggable
958 transport protocol:</li>
960 <blockquote>
961 <li>
962 To guarantee portability, local IPC rendezvous points (including the path
963 and filename) should not be longer than 99 characters long. Some platforms
964 may support longer rendezvous points, usually 108 characters including
965 the null terminator, but Posix.1g only requires that local IPC rendezvous
967 the null terminator.</li>
969 <P>If an endpoint is longer than what the platform supports then
970 it will be truncated so that it fits, and a warning will be issued.
971 <li>
976 working directory. If the client is not started in the directory where
978 able to communicate with the server since its point of communication, the
979 rendezvous point, was not found. On the other hand, if an absolute path
980 was used, the client would know exactly where to find the rendezvous point.</li>
982 <p>It is up to the user to make sure that a given UIOP endpoint is accessible
983 by both the server and the client.
984 <li>
985 It is important to be consistent in the use of absolute paths and relative
986 paths for rendezvous points. The two types of paths should not be used
990 it won't be used since the endpoint and preconnect are interpreted as different
992 On the other hand, if both the endpoint and the preconnect are the same
993 string then a preconnection will be established and used successfully.</li>
995 </blockquote>
997 a syntax similar to that of the URL style object reference shown above.
998 The only difference is that the object key delimiter and the object key
999 string are not specified.
1000 <li>
1001 Added documentation that describes how to implement pluggable transport
1002 protocols for TAO. The document is available <a href="../pluggable_protocols/index.html">here</a>.</li>
1004 <li>
1005 TAO's IIOP pluggable protocol now supports automatic creation of profiles
1006 for endpoints created on a host with multiple network interfaces. It should
1007 no longer be necessary to manually specify an endpoint for each network
1008 interface.</li>
1010 <p>This means that server IORs will contain profiles for all of the default
1011 endpoints created on each network interface the server is listening on,
1012 if no explicit endpoints were specified.</ul>
1013 Known Issues:
1014 <ul>
1015 <li>
1016 </li>
1017 </ul>
1018 Critical Work:
1019 <ul>
1020 <li>
1021 None.</li>
1023 </ul>
1024 Future Work:
1025 <ul>
1026 <li>
1027 Complete support for multiple ORB messaging protocols.</li>
1029 <li>
1030 Long term work will include adding support for pluggable ORB protocols,
1031 as well as transport protocols. This way we can develop optimal messaging
1032 and transport protocols for a given platform.</li>
1033 </ul>
1035 <hr>
1036 <h3>
1039 <p>The POA associates servants with the ORB and demultiplexes incoming
1040 requests to servants.
1041 <p>Current Status:
1042 <ul>
1043 <li>
1044 TAO supports the POA spec. This section will carry updates as available.</li>
1045 </ul>
1046 Known issues:
1047 <br>Future work:
1048 <br>Recently completed work:
1049 <ul>
1050 <li>
1051 ORB::shutdown now properly deactives all the POA Managers.</li>
1053 <li>
1054 POA Managers in TAO were previously ignored in the request processing path
1055 on the server. This is now fixed such that their state is checked before
1057 is the request dispatched to the servant. Otherwise, the request is rejected.
1060 them before falling into the event loop.</li>
1062 <li>
1063 TAO's POA now properly supports both the threading policies: SINGLE_THREAD_MODEL
1064 and ORB_CTRL_MODEL.</li>
1066 <li>
1067 The synchronization in the POA is now very optimal. For example, the locks
1068 are not held across the invocation on the servant. The locks are also not
1069 held across the invocation on the AdapterActivator and ServantManagers.
1070 This allows us to use regular locks instead of recursive locks inside the
1071 POA. This also allows multiple threads to dispatch requests on the same
1072 POA simultaneous.</li>
1074 <li>
1075 Before 1.4.6 TAO supports reference counting between POA and servants, including
1076 the new RefCountServantBase and ServantBase_var classes. RefCountServantBase
1077 is a reference counted base class that was added to the CORBA specification
1078 to avoid race conditions for servant deletion in threaded servers. <a href="ftp://ftp.omg.org/pub/docs/orbos/98-07-12.pdf">ftp://ftp.omg.org/pub/docs/orbos/98-07-12.pdf</a>
1079 contains the relevant text. Check <a href="../poa_migration.html#Reference counting Servants">here</a>
1080 on some hints to avoid trouble. From TAO 1.4.6 reference counting is always
1081 enabled for servants and RefCountServantBase is a noop struct you don't
1082 need anymore.</li>
1084 <li>
1085 The POA now supports active demultiplexing of servants in the SYSTEM_ID
1086 and the USER_ID policy. This should make the POA faster and more predictable
1087 since there is no hashing involved and the index of the slot where the
1088 servant is registered is in the Object Key.</li>
1090 <li>
1091 Previously, the complete POA name was used as the POA identity. This scheme
1092 was inefficient in many ways including: (a) the complete POA name can be
1093 significantly large in size, and therefore, ineffient to pass with every
1094 method call from the client to the server; (b) it is varible in size, and
1095 therefore, does not lend itself to smart and effective parsing; (c) the
1096 searching based on the complete POA name is very ineffient.</li>
1098 <p>The new solution is to use an active demux table, and flatten the POA
1099 hierarchy. This will help in the searching since active demuxing is fast
1100 and predictable. This will also help in the parsing since the demux key
1101 will be fixed size.
1102 <p>Note that for persistent ids, we have to pass the complete POA name
1103 in addition to the demux key in order to handle POA creation on demand.
1104 <li>
1105 There were some POA objects in a typical server that are not freed up properly,
1106 resulting in a memory leak. This has now been fixed.</li>
1108 <li>
1109 Timestamps in persistent IORs were not required and have been removed.</li>
1111 <li>
1112 POA exceptions are not not system exceptions and have been removed from
1113 the list of system exceptions.</li>
1115 <li>
1116 Vastly improved the ability of the POA to deal with user exceptions, memory
1117 allocation failures, and constructor failures.</li>
1119 <li>
1120 We now support a minimum POA for the minimum CORBA specification. Recently,
1121 this feature was enchanced such that the minimum CORBA footprint was further
1122 reduced. In addition, minimum POA can be enabled/disable irrespective of
1123 the minimum CORBA setting.</li>
1125 <li>
1126 We have decided not to support active demuxing for method name lookup.
1127 The benefit of this optimization was questionable since the current perfect
1128 hashing scheme provide very good and predictable behavior.</li>
1130 <p>Also, note that this optimization will require many changes. We would
1131 have to use the help of the IDL compiler to modify the object key that
1132 is passed for every method call differently. Note that this scheme doesn't
1133 work in the case of multiple inheritance or when the client stubs are not
1134 TAO.
1135 <li>
1136 Improved the parsing of object keys belonging to the RootPOA. Since this
1137 is the default POA and is commonly used, we have given it a reserved byte
1138 in the object key in order to quickly identify it. With the reserved bit,
1139 the active demux key for the RootPOA is not used, and no map lookups are
1140 required.</li>
1142 <li>
1143 POA name separator was changed from '/' to '\0'. Since POA names are strings,
1144 this makes a better choice since there is no chance of a conflict with
1145 the string specified by the user.</li>
1147 <li>
1148 We have support for reactivating servants with system generated ids.</li>
1150 <li>
1151 The TAO specific synchronization POA policy has been removed.</li>
1153 <li>
1154 New examples have been added to show how servants can be dynamically loaded
1155 from DLLs on demand.</li>
1157 <li>
1158 Support for collocation should be much better now because the POA can tell
1159 if we created the object reference.</li>
1161 <li>
1162 After Nanbor's recent changes for collocation, we support the full semantics
1163 of remote objects on a collocated object. The spec mandates that collocated
1165 going through the POA, running the Servant Managers, running the interceptors,
1166 and expecting the reference counting behavior provided by the POA. Note
1167 that the old scheme of direct call through to the servant is also still
1168 available.</li>
1170 </ul>
1172 <hr>
1174 <h3>
1178 <p>OMG defined CORBA Naming Service (spec <a href="ftp://ftp.omg.org/pub/docs/formal/97-07-12.pdf">here</a>)
1179 to provide a basic service location mechanism for CORBA systems. CosNaming
1180 manages a hierarchy of name-to-object-reference mappings. Anything, but
1181 typically the server process hosting an object, may bind an object reference
1182 with a name in the Naming Service by providing the name and object reference.
1183 Interested parties (typically clients) can then use the Naming Service
1184 to resolve a name to an object reference.
1185 <p>More recently, CORBA Naming Service was subsumed/extended by the CORBA
1186 Interoperable Naming Service, a.k.a. INS (spec <a href="ftp://ftp.omg.org/pub/docs/orbos/98-10-11.pdf">here</a>).
1187 INS inherits all the functionality from the original Naming Service specification
1188 in addition to addressing some its shortcomings. In particular, INS defines
1189 a standard way for clients and servers to locate the Naming Service itself.
1190 It also allows the ORB to be administratively configured for bootstrapping
1192 page</a> provides a brief description of additional features INS provides,
1193 and how they are implemented in TAO.
1195 <ul>
1196 <li>
1199 </ul>
1200 Recent work:
1201 <ul>
1202 <li>
1203 Changed default for multicast discovery to</li>
1204 </ul>
1205 Features:
1206 <ul>
1207 <li>
1208 Added support for Persistence (using memory-mapped files). Persistence
1209 feature is optional, and is controlled by the command line argument.</li>
1211 <li>
1212 Updated the implementation of the Naming Service to use new ACE exception
1213 macros.</li>
1215 <li>
1216 Added support for the InterOperable Naming Service, which enables the ORB
1218 allow the ORB to be configured to return arbitrary object references from
1220 for non-locality-constrained objects. Two options -ORBInitRef and -ORBDefaultInitRef
1221 have been added to the orb for bootstrapping to arbitrary services.</li>
1223 <li>
1224 Added support for the Naming service to act like an agent: to understand
1225 IIOP request messages from clients and respond with reply messages with
1227 can be configured through ORB options to register arbitrary services given
1228 the URL-format IOR for the service. The <tt>resolve_initial_references
1231 <ol>
1232 <li>
1235 <li>
1238 <li>
1239 Multicast discovery</li>
1240 </ol>
1242 <li>
1243 Added a test for the InterOperable Naming Service that works in conjunction
1244 with the current TAO examples.</li>
1246 <li>
1247 Implementation of the CORBA INS spec is completed. The following features
1248 are now supported:</li>
1250 <ul>
1251 <li>
1252 corbaname format</li>
1254 <li>
1255 NamingServiceExt interface</li>
1256 </ul>
1257 </ul>
1258 Future work:
1259 <ul>
1260 <li>
1261 Support for a load balancing feature similar to the one present in ORBIX.
1262 It will be possible to bind a group of objects under a single name, and
1263 when a client attempts to resolve the name in question, a preset policy
1264 (e.g., random, round robin, etc.) will determine which one of the object
1265 references from the group will be returned.</li>
1267 <li>
1268 Support for the Naming Service to handle the IIOP LocateRequest messages
1269 and respond with LocateReply messages with a
1271 status.</li>
1272 </ul>
1274 <hr>
1275 <h3>
1278 <p>The <a href="http://www.omg.org/technology/documents/formal/trading_object_service.htm">Trading
1279 Service</a> is an implementation of the COS Trading Service speficiation
1280 that meets the Linked Trader conformance criteria --- it implements the
1285 features:
1286 <ul>
1287 <li>
1288 Multithreaded operation;</li>
1290 <li>
1291 Trader federations and distributed queries;</li>
1293 <li>
1294 Dynamic properties;</li>
1296 <li>
1297 Modifiable properties;</li>
1299 <li>
1300 All policies described in the specification;</li>
1302 <li>
1303 Preference sorting;</li>
1305 <li>
1306 Service type inheritance hierarchies and subtype searching.</li>
1307 </ul>
1309 <p>Future Work:
1310 <ul>
1311 <li>
1312 The Proxy Interface.</li>
1314 <li>
1315 Persistent storage of service types and offers.</li>
1316 </ul>
1318 <hr>
1319 <h3>
1323 have been implemented. Please go through the test examples at $TAO/orbsvcs/tests/CosPropertyService.
1325 Streaming Service</a>developed for TAO. For general documentation of the
1326 Property Service, please read <a href="http://www.omg.org/technology/documents/formal/property_service.htm">The
1327 Property Service Specification.</a>
1328 <p>Recent Work:
1329 <ul>
1330 <li>
1331 Changed the PropertyException from Exception to struct, according to the
1332 OMG's changes.</li>
1334 <li>
1335 Changed the implementation to allocate storage for the Sequence out parameters,
1337 </ul>
1339 <hr>
1340 <h3>
1343 <p>Current status (as of May 3rd): The <a href="http://www.omg.org/technology/documents/formal/concurrency_service.htm">Concurrency
1344 Service</a> provides a mechanism that allows clients to acquire and release
1345 various types of locks in a distributed system.
1346 <ul>
1347 <li>
1348 A simple version of the Concurrency Service has been implemented, i.e.
1349 a version without transactions. It is currently being tested.</li>
1350 </ul>
1351 Future Work:
1352 <ul>
1353 <li>
1354 Implementation of the Concurrency Service with transactions</li>
1355 </ul>
1358 <h3>
1361 <p>This is an implementation of the OMG spec addressing the <a href="http://www.omg.org/technology/documents/formal/audio.htm">Control
1362 and Management of Audio/Video Streams</a>. For more documentation on TAO's
1364 <h4>
1365 Current Status:</h4>
1366 (as of July 30 2002)
1367 <ul>
1368 <li>
1369 The audio/video streaming service has been implemented in the full profile.
1370 The current implementation support all the flow related components like
1371 flowEndpoint,FDev,FlowConnection,..,etc.</li>
1373 <li>
1374 Point-to_Point and Point-to-MultiPoint streams have been implemented.</li>
1376 <li>
1377 A Pluggable protocols framework has been implemented to flexibly add new
1378 flow protocols like SFP, RTP and new transports like ATM. The current implementation
1379 has protoocol implementations for SFP, RTP over UDP and Multicast UDP.
1380 Please look at <tt><a href="../../orbsvcs/orbsvcs/AV/AV_Pluggable_Framework.html">orbsvcs/orbsvcs/AV/AV_Pluggable_Framework.html</a></tt>for
1381 more documentation about the implementation.</li>
1383 <li>
1384 QoS_UDP pluggable protocol added which implements RSVP QoS support for
1385 UDP streams.</li>
1387 <li>
1388 Diffserv support added to the UDP pluggable protocol by <a href="mailto:crodrigu@bbn.com">Craig
1391 <li>
1392 RTP/UDP support enhancements and RTCP control protocol support added by
1395 </ul>
1396 Work in progress:
1397 <ul>
1398 <li>
1400 UAV software.</a></li>
1401 </ul>
1403 <hr>
1407 allows clients to connect to Time Service Clerks and obtain globally synchronized
1408 time. This time is calculated from the time obtained from one or more Time
1409 Servers running on multiple machines in the network. The service uses the
1410 TAO Implementation Repository to activate the time servers on demand.
1412 <ul>
1413 <li>
1414 Implementation of a Distributed CORBA Time Service is complete.</li>
1415 </ul>
1416 Future work:
1417 <ul>
1418 <li>
1419 Currently the average of the time obtained from the various servers is
1420 considered the global notion of time. A better distributed time synchronization
1421 algorithm can be used in the future.</li>
1423 <li>
1424 Implementation of the Timer Event Service.</li>
1425 </ul>
1428 <h3>
1431 <h4>
1434 <p>The COS compliant Event Service implements the Event Service Specification:
1437 <br>The different command line and service configurator options used
1438 for configuring the CORBA event services are located <A
1440 the Real Time Event service.
1441 <h3>
1442 Features in this release:</h3>
1444 <ul>There is a new implementation of the COS Event Service available. This
1445 new implementation supports both the Push and Pull styles for event communication,
1446 and it does not require the Real-time Event Service to work.
1447 <p>A new testsuite for the COS Event Service has been started, they are
1449 <p>A new example for the COS Event Service is provided in <tt>$TAO_ROOT/orbsvcs/examples/CosEC/Simple/</tt>
1450 <p>A new binary to run the native COS Event Service was added, it is compiled
1452 <li>
1454 how to create and use the event channel.</li>
1456 <li>
1458 creates a COS compliant event channel and registers it with the naming
1461 <br>Please read the associated README for more details.
1462 <li>
1464 test demonstrates how multiple CosEC's connect to one RtEC and how multiple
1465 consumers and producers exchange events in this configuration.</li>
1466 </ul>
1468 <h3>
1469 Known bugs:</h3>
1471 <ul>
1472 <li>
1474 the tests are done, the control doesn't return to the shell, you have to
1475 say CTRL-C to get back to the prompt.</li>
1476 </ul>
1479 <h3>
1482 <h4>
1487 <h3>
1488 Features supported in the current version:</h3>
1490 <ul>
1491 <li>
1495 <li>
1499 <li>
1500 Support for the <tt>DsNotifyLogAdmin </tt>module, which uses the <a href="#notify">Notification
1503 <li>
1507 <li>
1509 has been added.</li>
1511 <li>
1515 <ul>
1516 <li>
1519 <li>
1522 <li>
1525 <li>
1528 <li>
1529 Each service registers with the Naming Service as
1533 <li>
1534 Each service registers with the Interoperable Naming Service as
1538 <li>
1539 The Log Service uses a dynamically loaded "plug-in" Strategy for storing and
1540 querying log records. The default Strategy stores Log records in memory and
1541 supports the Extended Trader Constraint Language (ETCL) Query Language.</li>
1543 <li>
1544 There are now examples that demonstrate simple usage of the Log Services.
1546 sub-directories.</li>
1549 tests most of the features of the basic logging service.</li>
1550 </ul>
1552 <h3>
1553 Future work and enhancements:</h3>
1555 <ul>
1556 <li>
1557 Provide Strategies that support persistent storage of log records.</li>
1559 <li>
1560 Change default Strategy to use Red-Black trees to optimize lookup on
1561 frequently used query keys - namely record id's and time.</li>
1562 </ul>
1565 <h3>
1568 <h4>
1572 Service </a>implementation consists of the following (see the associated
1573 README's for more information):
1574 <ul>
1575 <li>
1576 The implementation of the interfaces in the Notification Service spec is
1580 <li>
1581 The service driver is implemented in <tt><a href="../../orbsvcs/Notify_Service">$TAO_ROOT/orbsvcs/Notify_Service</a></tt>.</li>
1583 <br>The various options of the Notify_Service are described <a href="notify.html#notify_Service">here
1584 </a>.
1585 <li>
1586 The example in <tt><a href="../../orbsvcs/examples/Notify/Filter">$TAO_ROOT/orbsvcs/examples/Notify/Filter</a></tt>
1587 shows a basic example of using filters.</li>
1589 <li>
1590 The example in <tt><a href="../../orbsvcs/examples/Notify/Subscribe">$TAO_ROOT/orbsvcs/examples/Notify/Subscribe</a></tt>shows
1591 a basic example of how to use subscriptions.</li>
1593 <li>
1594 Feature unit tests are under <tt><a href="../../orbsvcs/tests/Notify">$TAO_ROOT/orbsvcs/tests/Notify</a></tt></li>
1596 <li>
1598 the features implemented.</li>
1599 </ul>
1600 <i>Note that this implementation does not support Pull interfaces and Typed
1601 Event style communication.</i>
1602 <p>
1604 <h3>
1607 <h4>
1610 <p>This is an extension to TAO's CORBA Notification Service with Real-Time
1611 CORBA support.
1613 <ul>
1614 <li>
1615 <b>Interface Extensions:</b> The <a href="../../orbsvcs/orbsvcs/NotifyExt.idl">$TAO_ROOT/orbsvcs/orbsvcs/NotifyExt.idl</a>
1616 extends the ConsumerAdmin and SupplierAdmin interfaces. The <tt>obtain_notification_push_supplier_with_qos</tt>
1618 used to specify QoS parameters.</li>
1620 <li>
1623 <ul>
1624 <li>
1625 ThreadPoolParams: This specifies the parameters for creating a threadpool
1626 in an RT POA.</li>
1628 <li>
1629 ThreadPoolLanesParams: This specifies the parameters for creating a threadpool
1630 with lanes in an RT POA.</li>
1631 </ul>
1632 </ul>
1634 <ul>
1635 <li>
1637 </a></tt>example
1638 shows how to use RTCORBA Lanes in RT Notification.</li>
1640 <li>
1641 The <tt><a href="../../orbsvcs/examples/Notify/ThreadPool">$TAO_ROOT/orbsvcs/examples/Notify/ThreadPool</a></tt>
1642 example shows how to use RTCORBA ThreadPools in RT Notification.</li>
1643 </ul>
1644 The performance tests for RT Notification measure the throughput, latency
1645 and jitter for various test configurations using Periodic Suppliers:
1646 <ul>
1647 <li>
1648 <tt><a href="../../orbsvcs/tests/Notify/performance-tests/scripts/1_Path_Period_0_Lanes">$TAO_ROOT/tests/Notify/performance-tests/scripts/1_Path_Period_0_Lanes</a></tt></li>
1650 <br>This configuration measures performance for a single data path when
1651 the load is increased. The Supplier sends events in a single burst.
1652 <li>
1653 <tt><a href="../../orbsvcs/tests/Notify/performance-tests/scripts/3_Path_Period_10ms_Lanes">$TAO_ROOT/tests/Notify/performance-tests/scripts/3_Path_Period_10ms_Lanes</a></tt></li>
1656 and low priorities when the Load is increased. The Suppliers send events
1657 at 100Hz.
1658 <li>
1659 <tt><a href="../../orbsvcs/tests/Notify/performance-tests/scripts/Paths_vs_Throughput">$TAO_ROOT/tests/Notify/performance-tests/scripts/Paths_vs_Throughput</a></tt></li>
1662 paths. we measure the performance of the high priority path as a function
1663 of the number of low priority paths.
1664 <li>
1665 <tt><a href="../../orbsvcs/tests/Notify/performance-tests/scripts/Max_Throughput">$TAO_ROOT/tests/Notify/performance-tests/scripts/Max_Throughput</a></tt></li>
1667 <br>This Configuration measures the performance obtained for a data path
1668 using a Structured Event payload:
1669 <ul>
1670 <li>
1671 directly between a Supplier and Consumer in separate processes.</li>
1673 <li>
1674 directly between a colocated Supplier and Consumer.</li>
1676 <li>
1679 <li>
1680 between a a Supplier and Consumer using the Notification Service.</li>
1681 </ul>
1682 </ul>
1684 <br>The <tt><a href="../../orbsvcs/tests/Notify/lib">$TAO_ROOT/orbsvcs/tests/Notify/lib</a></tt>
1685 contains a scripting based test framework which can be used to quickly
1686 create test cases. The framemork and its options are described <a href="notify.html#test_framework">here. </a><!-- BEGIN: CORBA Security Service Release Notes -->
1688 <h3>
1691 <p>Additional information is available
1696 TAO's current Security Service support implements the core
1697 functionality of the <a href="http://www.omg.org/cgi-bin/apps/doc?formal/02-03-11.pdf">CORBA Security Service v1.8</a>.
1698 <p>
1699 In particular, it implements the most of the CORBA <a href="../../orbsvcs/orbsvcs/SecurityLevel1.idl">SecurityLevel1 API</a>,
1700 in addition to some of <a
1702 Of the transport protocols described in the above specification, only
1703 SSLIOP is supported. Documentation for TAO's SSLIOP pluggable
1706 <p>
1707 The 1.8 specification defines the Common Secure Interoperability version
1708 1 (CSIv1) protocol that is currently implemented in TAO.
1710 <p>
1711 There are basically two ways to use security in TAO:
1712 <ol>
1713 <li>
1714 Use TAO's SSLIOP pluggable transport in TAO alone. This allows one
1715 to secure application requests without modifying the application code.
1716 This is the easiest approach but is also the least flexible.
1717 </li>
1718 <li>
1719 Use the Security Service API implemented by TAO in conjunction with
1720 TAO's SSLIOP pluggable transport. This provides the benefits of
1721 secured application requests with the flexibility of disabling
1722 security in some requests, if so desired. This approach also allows
1723 one to choose at run-time which X.509 certificates will be associated
1724 with application requests, as opposed to setting configuring only one
1725 SSL certificate at application start-up-time. These things are
1726 basically configured using the SecurityLevel2 or SecurityLevel3
1727 defined policies:
1729 <blockquote><code>
1730 SecurityLevel2::QOPPolicy<br>
1731 SecurityLevel2::EstablishTrustPolicy<br>
1732 SecurityLevel3::ContextEstablishmentPolicy<br>
1733 </blockquote></code>
1734 </li>
1735 </ol>
1739 pluggable transport</a>.
1740 <ul>
1741 <li>
1743 the SSL session state for the current execution context. This is useful
1744 for obtaining the SSL peer certificate chain associated with the current
1745 request, for example.</li>
1747 <li>
1748 TAO's SSLIOP pluggable transport now registers a secure invocation server
1749 request interceptor. It enforces secure invocation by rejecting requests
1750 coming in on the insecure port if the server is configured to do so (default
1751 behavior).</li>
1753 <li>
1756 <li>
1758 policy is used to set the desired invocation Quality-of-Protection (QoP).
1762 meaning that this policy can be set on a per-ORB, per-thread or per-object
1763 basis.</li>
1765 <p>This policy makes it possible to, for example, make both secure and
1766 insecure invocations within the same client process.
1767 <li>
1768 TAO's SSLIOP pluggable transport implementation is now thread-safe.</li>
1770 <li>
1772 This policy is used to set the desired invocation level of establishment
1774 in conjunction with the standard policy manipulation CORBA features (e.g.
1777 per-thread or per-object basis.</li>
1779 <p>This policy makes it possible to, for example, make authenticated and
1780 non-authenticated invocations within the same client process.
1781 <li>
1784 implementation is now available.</li>
1785 <li>
1786 Implemented basic (stateless) CSIv2 support. Advanced CSIv2
1787 features, such as identity assertion, are currently under
1788 development.
1790 </ul>
1791 </ul>
1793 <ul>
1794 <li>
1795 Began implementation of the interfaces in the
1797 ability to replace key security components in the ORB with
1798 another implementation with ease. Thus, the security
1799 components in the ORB become highly extensible.</li>
1800 <li>
1805 <li>
1806 Advanced CSIv2 features, such as identity assertion, are
1807 currently under testing.</li>
1808 </ul>
1810 <ul>
1811 <li>
1814 <ul>
1815 <li>
1816 Complete integration of the Common Secure Interoperability
1820 href="http://www.omg.org/technology/documents/formal/atlas.htm">Authorization Token Layer Acquisition Service (ATLAS)</a>.
1821 <p>
1822 CSIv2 and ATLAS address many of the shortcomings of the
1823 current CSIv1-based Security Service. Overviews of each are
1824 available on the <a href="http://www.omg.org/technology/documents/formal/omg_security.htm">OMG Security</a> web page.
1825 <blockquote><em>
1826 Note that CSIv2 as defined by the CORBA 3.0.x specification
1827 has no API so TAO's implementation will use a slightly
1828 <a
1829 href="http://adiron.com/ORBAsec/3.5.0/docs/SL3/#SecurityLevel3API">modified API</a> currently used by several ORBs defined by Adiron LLC.
1830 </em></blockquote>
1832 </li>
1833 </ul>
1834 <!--
1835 <LI>
1836 <FONT COLOR=BLUE>November 2002</FONT>
1837 <UL>
1838 <LI>
1839 Request authentication via
1840 <A HREF="http://web.mit.edu/kerberos/www/">Kerberos</A>, as
1841 detailed in the CORBA Security Service specification. This
1842 requires the Common Secure Interoperability protocol (CSIv2),
1843 but initial experiments will be performed via TAO's existing
1844 SSLIOP pluggable transport.
1845 </LI>
1846 <LI>
1847 Partial implementation of the <CODE>SecurityLevel2</CODE>
1848 interfaces. This includes the <CODE>Credential</CODE> and
1849 <CODE>Current</CODE> objects.
1850 </LI>
1851 <LI>
1852 Partial implementation of the <CODE>SecurityAdmin</CODE>
1853 interfaces.
1854 </LI>
1855 <LI>
1856 Begin implementation of <CODE>SecurityAudit</CODE> objects.
1857 As a side benefit, this project will allow us to research how
1858 to secure existing services such as
1859 <A HREF="ec.html">TAO's Real-Time Event Service</A>.
1860 </LI>
1861 </UL
1862 </LI>
1863 <li>
1864 <font color="#0000FF">December 2002</font></li>
1866 <ul>
1867 <li>
1868 Begin implementation of the <i>Resource Access Decision (RAD) Facility</i>
1869 specification for TAO.</li>
1870 </ul>
1872 <li>
1873 <font color="#0000FF">February 2003</font></li>
1875 <ul>
1876 <li>
1877 Begin implementation of the <i>Security Domain Membership Management (SDMM)</i>
1878 specification for TAO. It is needed to support security domains.</li>
1879 </ul>
1881 <li>
1882 <font color="#0000FF">April 2003</font></li>
1884 <ul>
1885 <li>
1886 SSLIOP and SECIOP performance enhancements.</li>
1887 </ul>
1888 -->
1889 </ul>
1890 <!-- END: CORBA Security Service Release Notes -->
1892 <!--#include virtual="ec.html" -->
1893 <p>
1894 <hr>
1895 <h3>
1899 Levine</a>
1900 <p>Currently Implemented Features:
1901 <ul>
1902 <li>
1903 The scheduling service can be built to use either a null implementation
1904 or a strategized implementation of the configuration scheduler.</li>
1906 <li>
1907 The null scheduler implementation, which is built by default, allows the
1908 configuration scheduler to be used with applications that require a scheduling
1909 service interface, but do not (at least in the current stage of their development,
1910 in certain configurations, etc.) make use of the real-time scheduling features
1911 it provides.</li>
1913 <li>
1914 The strategized scheduler implementation can be built by #defining TAO_USES_STRATEGY_SCHEDULER,
1915 and the appropriate scheduling strategy macro (TAO_USES_RMS_SCHEDULING,
1916 TAO_USES_EDF_SCHEDULING, TAO_USES_MUF_SCHEDULING, or TAO_USES_MUF_SCHEDULING)
1917 in $ACE_ROOT/ace/config.h. This allows the configuration scheduler to be
1918 used with applications that require a specific scheduling strategy. Each
1919 scheduling strategy will produce a set of static scheduling priorities,
1920 which it will assign to operations based on their RT_Infos. For each static
1921 priority, a strategy will also determine the run-time (dynamic) scheduling
1922 strategy to use for that priority level.</li>
1923 </ul>
1924 Future work:
1925 <ul>
1926 <li>
1927 Implement heap-based dispatching queues.</li>
1929 <li>
1930 Add support for additional configurability, especially in the type of dispatching
1931 strategy (list vs. heap) that will be used to dispatch operations at a
1932 given static priority level.</li>
1934 <li>
1935 Benchmark the various alternative strategies to obtain performance profiles
1936 across different operation loads and OS platforms.</li>
1938 <li>
1939 Add increased functionality. Requests and suggestions are welcome.</li>
1940 </ul>
1942 <hr>
1943 <h3>
1946 Natarajan</a>
1947 <h4>
1948 Current Status:</h4>
1949 TAO supports the ORB level requirements to achieve Fault Tolerance for
1950 CORBA Objects. The details of the ORB level support is described in the
1951 FT chapter of the
1956 <p>
1958 </p>
1960 <h4>
1961 Future Work:</h4>
1963 <ul>
1964 <li>
1966 </ul>
1968 <hr>
1969 <h3>
1972 <h4>
1973 Current Status:</h4>
1974 TAO's
1977 Balancing and Monitoring</i> proposed specification.
1978 <p>It provides many features and advantages over the previous prototype.
1979 Those features and advantages include:
1980 <ul>
1981 <li>
1982 Multiple object group support</li>
1984 <li>
1985 Extensible load balancing strategies through IDL interfaces</li>
1987 <li>
1988 Extensible load monitoring</li>
1990 <li>
1993 <li>
1994 Support for infrastructure and application controlled object group membership</li>
1996 <li>
1997 Improved server-side transparency</li>
1998 </ul>
2000 defines three built-in load balancing strategies. They are:
2001 <ol>
2002 <li>
2005 <li>
2008 <li>
2011 </ol>
2012 TAO implements all of these and the following load balancing strategies:
2013 <ol>
2014 <li>
2017 <li>
2020 </ol>
2021 <h4>
2022 Known Issues:</h4>
2024 <ul>
2025 <li>
2026 CPU load monitoring is not working in Windows.
2027 </li>
2028 </ul>
2030 <h4>
2031 Recent Work:</h4>
2033 <ul>
2034 <li>
2037 <li>
2040 <li>
2041 Implemented a CPU load utilization monitor in Linux.
2042 </li>
2043 </ul>
2045 <h4>
2046 Future Work:</h4>
2048 <ul>
2049 <li>
2050 Implement cooperative (distributed) load balancing support</li>
2052 <li>
2053 Integrate multicast support</li>
2054 <li>
2055 Implement a middleware load balancing performance measurement toolkit</li>
2056 <li>
2057 Implement self adaptive load balancing strategies</li>
2059 </ul>
2061 <hr>
2062 <h3>
2065 <h4>
2066 Current Status:</h4>
2068 specification</a> has recently been adopted by the OMG. TAO's MIOP support
2069 (located in $TAO_ROOT/orbsvcs/orbsvcs/PortableGroup) enables servants to
2070 receive requests sent to multicast addresses. This is performed by creating
2071 a GroupId that identifies the multicast group and associating it with one
2072 or more servants. Additionally, the Unreliable IP Multicast (UIPMC) pluggable
2073 protocol is used to send and receive multicast requests. Multicast endpoints
2074 can be created dynamically at runtime.
2075 <h4>
2076 Known Issues:</h4>
2078 <ul>
2079 <li>
2080 MIOP packet reassembly is not performed yet, so the maximum request size
2082 </ul>
2084 <h4>
2085 Recent Work:</h4>
2087 <ul>
2088 <li>
2089 Initial check in of MIOP implementation.</li>
2090 </ul>
2092 <h4>
2093 Future Work:</h4>
2095 <ul>
2096 <li>
2097 Allow group references to be disassociated when no longer needed.</li>
2099 <li>
2100 Implement MIOP packet reassembly.</li>
2102 <li>
2103 Implement a Multicast Group Manager (MGM).</li>
2105 <li>
2106 Implement a Multicast Gateway (MG).</li>
2107 </ul>
2109 <hr>
2110 <h3>
2112 [Note: This section is not uptodate. Use with caution. February 2004.]
2113 <br>
2115 <p>Current Status:
2116 <p>The TAO IDL_Cubit test application makes use of the Naming Service and
2117 the server holds a TAO_Naming_Server component.Just running server and
2118 client is enough to test the application.
2119 <p>The various tests in the tests/POA test the different features of the
2120 Portable Object Adapter interface like Explicit Activation, On Demand Activation,etc..
2121 <p>MT_Cubit:
2122 <p>Current status:
2123 <p>The TAO MT_Cubit test application is meant to serve as a starting point
2124 for real-time tests on the TAO system. It comprises the following parts:
2125 <ul>
2126 <li>
2128 with different real-time priorities. This priority is implemented by using
2129 real-time thread support provided by the operating system. Thus, requests
2130 sent to a high-priority servant are handled by a high-priority real-time
2131 thread, and those sent to a lower priority servant are handled by correspondingly
2132 lower priority threads.</li>
2134 <li>
2136 stream of CORBA requests to the servants. It measures the response time,
2137 i.e. the time taken for the request to complete successfully. In particular,
2138 it measures the time taken for requests sent to the high priority servant
2139 to complete. The volume of lower priority requests is configurable. The
2140 client is thus able to measure the performance of the high-priority servant
2141 in the presence of competition from several lower-priority servants.</li>
2142 </ul>
2143 Clearly, if the ORB endsystem handles the priorities of the various requests
2144 correctly, increasing the volume of lower priority requests should not
2145 affect the performance seen by the higher priority requests. The application
2146 thus serves as a tool to measure and confirm this behavior.
2147 <p>Future work:
2148 <ul>
2149 <li>
2152 <li>
2153 Evolve into a testbed for discovering sources of performance non-determinism
2155 </ul>
2156 Pluggable:
2157 <p>Current status:
2158 <p>The TAO Pluggable test utilizes ACE Timeprobes to time the latency at
2159 various points in the ORB, especially that incurred by the Pluggable Protocols
2160 implementation. Comparisons can be made not only between different layers
2161 of the ORB, but also between different protocols as they become available.
2162 <p>Future work:
2163 <ul>
2164 <li>
2165 Add options to redirect the output to a file.</li>
2167 <li>
2168 Script or otherwise automate the piping of the output to a spreadsheet.</li>
2169 </ul>
2171 <hr>
2172 <h3>
2176 <p>Recently Completed Work:
2177 <ul>
2178 <li>
2180 because VxWorks doesn't provide full argument prototypes for these library
2181 functions.</li>
2183 <li>
2184 The current caching connector behaves properly in the face of a non-blocking
2185 connect request. The "fix" is simply to not support non-blocking connects
2189 <li>
2190 Service handlers obtained from the caching connector are now cleaned up.
2191 The application needs to be able to signal that it's not using it any longer,
2192 and, when the application encounters an error, needs to effectively close
2193 down that connection for good so that a new connection can be initiated.</li>
2195 <br>Added the ability for a Svc_Handler to recycle itself. idle() can be
2196 called when the Svc_Handler is done serving a particular connection and
2197 can how be recycled. The Svc_Handler now also has a pointer to a recycler
2198 that is responsible for managing the connections. The recycler is usually
2199 a Cached_Connector.
2200 <br>Added new class ACE_Recycling_Strategy. It defines the interface (and
2201 default implementation) for specifying a recycling strategy for a Svc_Handler.
2202 This strategy acts as a consular to the Svc_Handler, preparing it for the
2203 tough times ahead when the Svc_Handler will be recycled.
2204 <br>Added new class ACE_NOOP_Concurrency_Strategy. It implements a no-op
2205 activation strategy in order to avoid calling open on a recycled svc_handler
2206 multiple times.
2207 <br>ACE_Cached_Connect_Strategy now implements the ACE_Connection_Recycling_Strategy
2208 interface. This allows Svc_Handlers to cache themselves with ACE_Cached_Connect_Strategy
2209 when they become idle. It also allows them to purge themselves from the
2210 connection cache when the Svc_Handlers close down.
2211 <br>Also added ~ACE_Cached_Connect_Strategy that will cleanup up the connection
2212 cache.</ul>
2213 Future work:
2216 <hr>
2217 <h3>
2223 This discussion focuses on the following goals:
2224 <ul>
2225 <li>
2226 Have a DOVE Browser running using Java Beans as vizualization components.</li>
2228 <li>
2229 Have the Event Channel as DOVE Agent running with an Event Consumer in
2230 the DOVE Browser.</li>
2232 <li>
2233 Having a DOVE Management Information Base (MIB), which dumps all events
2234 transfered on the Event Channel into a file on persistent storage for later
2235 reuse.</li>
2236 </ul>
2237 The DOVE Browser uses independent visualization components (Java Beans)
2238 and the Event Channel as DOVE Agent. Connections can be established between
2239 monitored metrics and the visualization components.
2240 <p>We have three major components: Observables (monitored metrics), Observers
2241 (a Java Bean for displaying the metric) and a DataHandler (for demultiplexing
2242 the monitored metrics to the appropriate Observables). Each component inherits
2243 from a base class, so that a certain behavior of the components can be
2244 assured for each component. Relationships between components are based
2245 on these base classes.
2246 <p>The used Java Beans are required to conform to some standards, as they
2247 have to support a function called "getProperty" which allows the DOVE Browser
2248 to determine if the vizualization capabilities of a specific Java Bean
2249 are sufficient to display the metric. A JavaBean is for example a Java
2250 Panel which shows a Graph of the delivered doubles. So all metrics can
2251 be displayed by this visualization component which can be expressed by
2252 a single double.
2253 <p>The DataHandler is connected to the Event Push Consumer (PUSH, because
2254 we use the push concept of the Event Service). The Event Push Consumer
2255 does not know what kind of data is transported. The only component knowing
2256 all the details about the dependencies of the metrics is the DataHandler.
2257 This separation allows easy extension and change of the demo.
2259 are available about this new concept.
2260 <p>Event Service events are used as communication between DOVE Applications
2261 and the DOVE Browser. The DOVE MIB analyses the event data field of all
2262 events and stores this information into a file. The event data filed is
2263 of type CORBA::Any and the DOVE MIB has no notion of what is conveyed in
2264 this field. So the DOVE MIB has to discover the content via the embedded
2265 type code information. Future work includes:
2266 <ul>
2267 <li>
2268 Enhancing MIB functionality</li>
2270 <li>
2271 Monitoring the AV Streaming Service</li>
2272 </ul>
2273 For more information on the DOVE demo, please refer to: $TAO_ROOT/orbsvcs/tests/Simulator/README.
2274 <p>
2275 <hr>
2276 <h3>
2280 Kircher</a>.
2282 <p>
2283 <hr>
2284 <h3>
2288 Kircher</a>.
2290 model</a>
2291 <p>
2292 <hr>
2293 <h3>
2297 Kircher</a>.
2299 <p>
2300 <hr>
2301 <h3>
2305 and
2307 <p>Status:
2308 <ul>We've implemented the callback model of the
2310 Messaging specification</a>. To activate the AMI for TAO and the TAO IDL
2313 in your config.h file. The TAO IDL compiler can generate the AMI "callback"
2316 Finished work:
2317 <ul>
2318 <li>
2319 Redesign of the IDL compiler to make an additional pass over the AbstractSyntaxTree
2320 and generate the implied-IDL code in memory. This reduced the amount of
2321 AMI specific IDL compiler code dramatically.</li>
2323 <li>
2324 Support for exceptions</li>
2326 <li>
2327 Support for attributes</li>
2329 <li>
2330 Support for buffering and batching AMI calls. See <a href="../../examples/Buffered_AMI">Buffered
2333 <li>
2334 Support for deferred synchronous invocations.
2336 Parsons</a></li>
2338 <li>
2339 Support for timeouts in combination with AMI calls, response handler gets
2340 CORBA::TIMEOUT exception on timeout</li>
2341 <li>
2344 </ul>
2345 Future Work:
2346 <ul>
2347 <li>
2348 Implementation of the poller model.</li>
2349 </ul>
2350 <hr>
2351 <h3>
2354 <h4>
2355 Current Status:</h4>
2356 <ul>This Custom Servant Dispatching (CSD) feature provides user applications with the ability to implement and "plug-in" custom strategies to handle the dispatching of requests to servants.
2357 <p>A concrete CSD Strategy implementation has also been added to serve as a "reference implementation". This is being called the CSD Thread Pool Strategy (TP_Strategy). The TP_Strategy provides a means to decouple the threads (ORB threads) that receive requests from the underlying transport from the thread that will ultimately dispatch the request to the target servant object. The TP_Strategy implements a "request queue" as the integral part of the mechanism that allows an ORB thread to "hand-off" a request to one of the TP_Strategy object's worker threads. The TP_Strategy reference implementation is provided as an example of how concrete CSD Strategy could be implemented.
2358 <p>Two approaches are supported for applying CSD strategy to an application.
2359 <ol>
2360 <li>Explicitly calling CSD interfaces.
2361 <p>Here is an example application code showing how a TP_Strategy object can be created and applied to a POA:
2363 <pre>
2365 PortableServer::POA_var poa = ...; // create the poa.
2367 // Create a new TP_Strategy object and save it into a "smart pointer" variable.
2368 TAO::CSD::TP_Strategy_Handle csd_strategy = new TAO::CSD::TP_Strategy();
2370 // Set the number of threads before calling apply_to().
2373 // Set the servant serialization flag before calling apply_to().
2374 csd_strategy->set_servant_serialization (false);
2376 // Tell the strategy to apply itself to the poa.
2377 if (csd_strategy->apply_to(poa.in()) == false)
2378 {
2379 ACE_ERROR((LM_ERROR, "Failed to apply CSD strategy to the poa.\n"));
2380 return -1;
2381 }
2382 </pre>
2383 <li>Service Configurator
2385 <p>The format of the CSD specific parameters for creating the TP_Strategy service object is:
2388 <p>The last portion of the parameter is the servant serialization flag. It's only needed when the servant serialization needs be turned off, otherwise the servant serialization is always on. When servant serialization is on (the default), the TP_Strategy will serialize requests to any particular servant. Requests to different servant objects can occur in parallel, but requests to any particular servant will be dispatched serially (ie, one at a time).
2390 <p>Here is an example of the svc.conf file.
2392 <pre>
2393 dynamic TAO_CSD_TP_Strategy_Factory Service_Object *
2394 TAO_CSD_ThreadPool:_make_TAO_CSD_TP_Strategy_Factory() "-CSDtp RootPOA:2"
2395 </pre>
2396 </ol>
2397 </ul>
2398 <h4>
2399 Known Issues:</h4>
2400 <ul>
2401 <li>
2402 This feature is not currently tested for VxWorks.
2403 </li>
2404 <li>
2405 This feature does not support the operation of the various server side 'Current' implementations (e.g. PICurrent, POACurrent, etc.). It should not be used by applications that require these to function correctly. See issues <a href="http://bugzilla.dre.vanderbilt.edu/show_bug.cgi?id=3087">3087</a> and <a href="http://bugzilla.dre.vanderbilt.edu/show_bug.cgi?id=3327">3327</a>.
2406 </li>
2407 </ul>
2408 <hr>
2409 <h3>
2413 <br>
2414 <hr>
2415 <h3>
2418 <p>Local interfaces are first defined in the CORBA Component Model specification.
2419 For more information on using the local interfaces, please refers to Section
2423 local objects.
2424 <br>
2427 <hr>
2428 <h3>
2430 Point of contact: <a href="mailto:gthaker@atl.lmco.com">Gautam H. Thaker</a>, Lockheed Martin Advanced Technology Labs, Cherry Hill, NJ.
2435 that SCIOP protocol properties are not yet supported. Extensive
2436 information about SCTP and how it may be used from both ACE and TAO is
2437 available in several README files in $ACE_ROOT/performance-tests/SCTP/
2438 directory. ACE+TAO's SCTP support can be used either with Linux's
2439 OpenSS7 SCTP implementation or with Linux's LKSCTP SCTP
2440 implementation. <p> A paper describing the ACE+TAO SCTP
2441 implementation and measured results are available <a
2442 href=http://www.atl.external.lmco.com/projects/QoS/documents/DOA2003_97_Thaker.pdf>
2445 <hr>
2446 <h3>
2451 <p>TAO has support for IPv6 for IIOP under Windows and Linux.
2453 file and regenerate all makefiles. When using the automated tests, add IPV6
2454 to the configs.
2455 <p>
2456 Finished work:
2457 <li>Added IPv6 support to all IIOP related classes (parsers, connectors,
2458 acceptors)</li>
2460 <li>Implemented IPv6 support in the TAO_IOR_MCast utility class from TAO Svc
2461 Utils</li>
2462 <p>
2464 The following gotchas are known:
2465 <li>In a localhost situation connecting a server listening at the IPv6 ANY address
2466 has the following problems:
2467 On Linux this does not work when the client tries to connect to a
2468 LinkLocal address of one the local NICs,
2469 on Windows this only works (locally) by using the 'localhost' address (either
2470 IPv4 or IPv6)
2471 </li>
2472 <li>Usage of the '-ORBObjRefStyle url' switch poses problems in localhost situations
2473 on Windows since this switch causes 'object_to_string' to only return the first server
2474 endpoint from the IOR profile as a corbaloc URL. In IPv6 servers this will (almost) allways be an IPv4 interface address of one
2475 of the local NICs. This will than cause problems when the server is listening at
2476 the IPv6 ANY address as described above.
2477 </li>
2479 <p>
2480 Future work:
2481 <li>IPv6 support for other protocols/strategies than IIOP (i.e. SHMIOP, UIOP,
2482 SCIOP, SSLIOP etc.; for this we excluded some regression tests in IPv6 builds for this
2483 reason)</li>
2485 <li>IPv4 runtime dependencies in various CORBA services (f.i. Event service)
2486 </li>
2489 <P>
2493 <hr>
2494 <h3>
2496 Here is a summary of TAO's conformance issues with CORBA latest CORBA specifications
2499 <br><a href="ftp://ftp.omg.org/pub/docs/formal/99-10-07.pdf">ftp://ftp.omg.org/pub/docs/formal/99-10-07.pdf</a>
2500 <br>and search for the change bars, meanwhile this can help:
2501 <ul>
2502 <li>
2503 The full OBV (valueboxes, valuetypes in all sorts of things, value graphs,
2504 Anys and value types, abstract interfaces, etc. etc.)</li>
2506 <li>
2507 The IfR database cannot be populated (so it is less than fully operational
2508 ;-))</li>
2510 <li>
2511 Fixed data types (who cares)</li>
2513 <li>
2516 <li>
2517 The old ServantManager interfaces (POA stuff)</li>
2519 <li>
2520 Domain Managers (useful for security, but otherwise nobody seems to care)</li>
2522 <li>
2523 I think our interpretation of codesets is compliant (we only support one
2524 codeset), but would have to check.</li>
2525 </ul>
2526 Future Work (aka. known problems):
2527 <ul>
2528 <li>
2529 Supposedly, any constructed types that contains local types become local
2530 automatically. TAO_IDL currently doesn't handle the array type very well
2531 if one is defined outside the scope of a local interface.</li>
2533 <li>
2534 Need to test local object support more systematically and comprehensively.
2535 (Does TAO throw a MARSHAL exception when trying to marshal a local type?)</li>
2536 </ul>
2538 <hr>
2539 <p>Back to the TAO <a href="../index.html">documentation index</a>.<!--#include virtual="/~schmidt/cgi-sig.html" -->
2540 </body>
2541 </html>