| blob | d078fd545027f331dd9961001dca9ddba0d27bc9 |
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 </L1></li>
344 <li>
347 <li>
348 Completely redesigned the IDL compiler using the Visitor patterns. Many
349 incomplete issues have been resolved. These include support for "sequence
350 of typecodes", passing object references as in, inout, and out parameters.
351 Code generation for sequences is also properly handled i.e., for a named
353 a new class (and hence a type) called "class CharSeq". Arrays are still
354 being worked out and will be done soon. An important difference in the
355 generated code is that the skeletons now use a table driven approach very
356 similar to the stubs.</li>
358 <li>
361 <li>
362 The problem of incorrect code generation for typedefs defined in an imported
363 file is resolved.</li>
365 <li>
366 Problems when interfaces use single or multiple inheritance solved. The
367 problem was with the demultiplexing code, the generated operation tables,
368 and the dispatching mechanism. We are currently testing this with the Event
369 Channel code.</li>
371 <li>
372 The problems arising due to public virtual inheritance when casting from
373 an interface class to CORBA::Object_ptr has been solved. We do this casting
374 inside the stubs/skeletons rather than first converting an interface class
375 pointer to a void*, storing it in an Any, and casting it to CORBA::Object_ptr
376 in the encode/decode methods. The casting inside the stubs/skeletons work
377 because the compiler has knowledge of both types.</li>
379 <li>
380 Include files are handled properly. So are the definitions used inside
381 the include files that are used in the currently parsed files.</li>
383 <li>
384 Generates C++ stubs and skeletons that use TAO's
388 <li>
389 Support dynamic libraries on NT, i.e., marking classes for DLL export was
390 added. Two backend options control the name of the export macro, and the
391 name of an extra include file were the macro is defined; the options are
394 <li>
395 The IDL compiler generates now source code for sequences. The user has
396 now the option to use these generated sequence classes or to use, as up
397 to now, the template instatiation. If TAO_LACKS_TEMPLATE_SPECIALIZATION
398 is defined, then template instantiation will be used, else not. The reason
399 for this was, that some C++ compilers did not support template instantiation
400 properly and sequences were based on templates. The generated source code
401 is mainly contained in the generated header file directly in the class
402 declaration.</li>
404 <li>
405 The IDL Compiler generates templates for servant implementations. The options
406 are -GI [ h | s | b | e | c ]</li>
408 <li>
409 The IDL compiler generates source code for the management and (de)marshaling
410 of wide characters and wide strings, enabling the sending and receiving
411 of Unicode over the wire. However, wide character and wide string literals
412 are not yet portable to Unix platforms (see entry under Future Work below).</li>
414 <li>
415 Since the CORBA spec requires that all enums be 32 bits, and some compilers
416 will try to use less space if the enum values are small enough, the IDL
418 to every enum. This appended enum value is not part of the IDL compiler's
419 internal representation of the enum, so unions that use the enum as a discriminator
420 will not have incorrect _default() code generated for them.</li>
422 <li>
423 The IDL compiler generates a C++ ostream operator for IDL exceptions. So
424 far only the repository ID is output, but this may be enhanced when requirements
425 and/or desires become clearer.</li>
427 <li>
428 The IDL compiler has support for valuetypes (see release notes
429 for valuetypes for details). </li>
431 <li>
432 As part of the implementation of interceptors, the TAO IDL compiler now
433 generates interception points in the client and server, as well as the
434 prepare_header method in the stubs.</li>
436 <li>
437 Scoping and name resolution rules have changed in CORBA with version 2.3.
438 The IDL compiler now conforms to these new rules.</li>
440 <li>
441 IDL compiler now supports the CORBA AMI callback model, generating code
442 for reply handlers and reply stubs if the -GC command line option is used.
443 The TAO library must be compiled with TAO_HAS_CORBA_MESSAGING = 1. If this
444 is done, TAO_HAS_AMI_CALLBACK will automatically be defined to 1 as well.
447 <li>
448 New command line option -So added to suppress generation of ostream operators
449 for exceptions.</li>
451 <li>
452 New command line option -Sc added to suppress generation of tie classes
453 and *S_T.* files. The default is still to generate them.</li>
455 <li>
456 IDL compiler now handles escaped identifiers (CORBA 2.3.1). An identifier
457 appearing in an IDL file with a leading underscore will appear in generated
458 code without the underscore. This enables the use of identifiers in generated
459 code identical to IDL keywords, as specified in CORBA 2.3.1. If the resulting
460 identifier matches a C++ keyword, "_cxx_" will be prepended in generated
461 code as before.</li>
463 <li>
464 The -St option to suppress generation of typecodes now also suppresses
465 the generation of the Any insertion and extraction operators. The extraction
466 operators require the associated typecode, so the generated code for those
467 operators would not compile when the -St option was used.</li>
469 <li>
470 Option -Ge 2 added which generates 'throw' instead of ACE_THROW_SPEC, ACE_THROW,
471 and ACE_RETHROW. Since the expansion of ACE_THROW_RETURN is platform-dependent,
472 it was left as is. Same for TAO_INTERCEPTOR_THROW, since it sometimes expands
473 to ACE_THROW_RETURN. Of course ACE_HAS_EXCEPTIONS must be defined for this
474 option to work.</li>
476 <li>
477 Removed generation of ostream operators for user exceptions, along with
478 the command line option to suppress this generation. The ostream operator
479 defined in the base class CORBA::Exception works fine and produces the
480 same output.</li>
482 <li>
483 The TAO IDL compiler is no longer monolithic. It is composed of a top-level
484 executable, a front end library and a back end library. This will enable
485 different back ends to be plugged in for code generation in different languages,
486 and for IfR administration. Different back ends may require a few changes
487 to the executable (described below), but the front end library can remain
488 unchanged. The chain of dependencies is as follows:</li>
490 <blockquote>FE : ACE
491 <br>BE : FE
493 Executing the Makefile (or the TAO_IDL Compiler project in the MSVC 'tao_idl'
494 workspace) will build whatever is required in the proper order, as before.
495 Back end files, classes and functions required by the executable are as
496 follows:
497 <blockquote>be.h - file containing #includes of the major BE file headers.
498 <br>TAO_Codegen - class, holds output stream references for the various
499 generated files.
500 <br>TAO_CODEGEN - ACE_Singleton typedef of the above class.
501 <br>tao_cg - pointer to instance of TAO_CODEGEN.
502 <br>be_generator - class, inherits from AST_Generator in FE and generates
503 AST nodes.
504 <br>void BE_produce (void) - global function, starts AST traversal for
505 code generation.
506 <br>BE_GlobalData - class, holds default/command line arg settings specific
507 to BE.
509 All the code in the executable that may need to be modified for different
510 back ends in contained in the file drv_args.cpp. Code in this file processes
511 the command line arguments, outputs a usage message, and performs other
512 miscellaneous BE initialization.
513 <li>
514 The IDL compiler can how handle interfaces forward declared in one IDL
515 file and defined in another. It will handle interfaces that are mutually
516 dependent across two IDL files, as long as code generated from both IDL
517 files is included in the same C++ build.</li>
519 <li>
520 Generation of template tie class declarations has been moved from the *S.h
521 file to the *S_T.h file. The new SunCC 5.2 compiler does not require that
522 template source code be included in the header file, but it does require
523 that template declarations and implementations be in the same 'compilation
524 unit' that is, the same header/source file combination. Generated ifdef
525 guards prevent the compilation of tie class code if the target platform
526 does not support namespaces. For such platforms, TAO maps the IDL 'module'
527 keyword to a class instead of to 'namespace', and C++ does not allow template
528 class declarations to occur inside another class.</li>
530 <li>
531 IDL compiler can now process multiple IDL files per execution, on all platforms.
532 A separate process is spawned for each file. IDL files and command line
533 options may appear in any order on the command line. Any option not starting
534 with '-' will be treated as a filename.</li>
536 <li>
537 Support for value types has been expanded to include forward declared value
538 types, sequences of value types, and factory methods. Also, work to support
539 Anys and type codes for value types is in progress.</li>
541 <li>
542 Support for #pragma prefix has been revamped and improved to be compliant
543 (the prefix is now cleared when leaving the scope or the included IDL file
544 where it was defined), and support for #pragma version and #pragma ID has
545 been added.</li>
547 <li>
548 Support for forward declared structs and unions has been added. In compliance
549 with CORBA 2.6, such forward declarations must be fully defined in the
550 same compilation unit, and may be used only in sequence declarations, which
551 in turn may be used in the declaration of recursive structs and unions.
552 Use of a forward declared struct or union as an aggregate type member or
553 as an operation parameter will generat an error message.</li>
555 <li>
556 Support for enum constants has been added.</li>
558 <li>
559 The IDL compiler can now handle concatenation of string literals, for example</li>
563 <li>
564 Support for abstract interfaces has been added.</li>
566 <li>
567 Support for valuetypes has been expanded.</li>
569 <ul>
570 <li>
571 Forward declared valuetypes not defined in the same compilation unit</li>
573 <li>
574 Type codes for valuetypes</li>
576 <li>
577 Generation of Any insertion/extraction operators</li>
579 <li>
580 Abstract valuetypes</li>
582 <li>
583 Valuetype members of all IDL aggregate types</li>
585 <li>
586 Interface supports list</li>
587 </ul>
589 <li>
590 Support for the CCM extensions to IDL, which first appeared in CORBA 3.0
591 is complete, with the exception of support for the 'import' keyword.</li>
593 <li>
594 Generated code for constants defined in a module is now inlined
595 (value is assigned in the header file) by default, enabling such
596 constants to be referenced by name as array bounds, etc. either in
597 subsequent generated code or in application code. However, this inlining causes
598 a problem with some compilers when using pre-compiled headers, so the
599 option -Guc has been added to turn it off. NOTE: Constants
600 defined at global scope (always inlined) and constants defined inside an
601 interface or a valuetype (never inlined) are not affected by the option.
602 </li>
604 <li>
605 Generation of explicit template instantiations is now off by default. The
606 option -GT turns it on. If turned on, the generated explicit instantiations
607 are guarded by the same #ifdef preprocessor directives as before.
608 </li>
610 <li>
611 The mechanism for processing multiple IDL files in a single execution has
612 changed. Instead of spawning a separate process for each IDL file, the
613 IDL compiler now processes the files sequentially in a single process.
614 Note that, for each file, execution of the preprocessor spawns a new
615 process, as it always has.
616 </li>
618 <li>
619 Added command line option -Sm to suppress the action of CCM preprocessing
620 visitor, which is by default launched before the C++ generating visitors,
621 in order to add CCM equivalent IDL to the AST. There is a new tool in CIAO
622 which converts IDL files by replacing IDL3 constructs with equivalent IDL2
623 constructs, and if the IDL compiler is run on these files, we do not want
624 the CCM preprocessing to occur.
625 </li>
627 <li>
628 Changed the behavior of the -o option to create the specified directory
629 if it does not already exist. Only one level of directory can be created
630 with this option (any path prefix included must already exist).
631 If the specified directory already exists, no action is taken.
632 </li>
634 <li>
635 As part of the subsetting in TAO of Anys and TypeCodes, the generation of
636 these things in the IDL compiler has been further decoupled from other
637 code generation. Now the -GA option generates not only a *A.cpp file but
638 also a *A.h file, and in addition, the -oA option will create these files
639 in a directory different from that where the other generated files are
640 created.</li>
642 <li>
643 Generation of explicit template instantiations has been completely
644 removed, it is no longer available via the command line option -GT.</li>
646 <li>
647 Generation of Any insertion/extracion operators for local interfaces
648 has been enabled by default. An additional command line option -Sal
649 has also been added to suppress the generation of Any operators for
650 local interfaces only.</li>
652 <li>
653 Added new command line option -oS to specify output directory for
654 all skeleton files, including TIE class files, if generated. Overrides
655 -o option value, if any.</li>
657 <li>
658 Uninlined all generated TIE class code, since inlining could potentially
659 cause a problem for RTTI.</li>
661 <li>
663 an explicit export of each sequence's template base class. This is
664 occasionally necessary as a workaround for a bug in Visual Studio
666 used for the base class isn't automatically exported. See
670 </ul>
672 <h4>
673 Known Issues:</h4>
675 <ul>
676 <li>
677 With Microsoft Visual C++, verison 6.0 and earlier, a problem has been
678 discovered when the IDL compiler is built using the Release version of
679 the MSVC project. For the Release version, the Optimizations box in the
680 C/C++ tab has 'Maximize Speed' selected. This setting turned out to cause
681 a problem when</li>
683 <p>const char *foo = ......
684 <p>occurs in the source code. The variable foo is sometimes not allocated
685 or assigned properly, and if foo is part of generated code, it will then
686 display as garbage or as an empty string (or substring). Two workarounds
687 have been found. One is to change the declaration of foo to be
688 <p>static const char *foo = ....
689 <p>and this has been done in all cases we could find in the IDL compiler
690 source code. Another way to avoid the problem is to change the Release
691 project Optimization setting to 'Minimize Size'. Reportedly the problem
692 has been fixed in MSVC version 7.0.
694 </ul>
696 <h4>
697 Future work:</h4>
699 <ul>
700 <li>
702 specification. Originally implemented solely for use in holding exceptions
704 work is now ongoing to extend TAO's OBV implementation until it includes
705 the complete CORBA value type specification. Some of the items yet to be
706 implemented include:</li>
708 <ul>
709 <li>
710 Boxed value types</li>
712 <li>
713 Custom marshaling</li>
715 <li>
716 Truncation</li>
718 <li>
719 Marshaling of complex state (graphs with cycles)</li>
721 </ul>
722 For a complete description of value type semantics, see chapter 5 in the
723 CORBA specification.
724 <li>
725 The generated sequence classes should not be generated per sequence, but
726 per type and parent scope. Which means, that the overhead of having the
727 source code generated several times should be reduced. To do this, an
728 extra pass over the internal representation of the IDL file has to be done.</li>
730 <li>
731 Updated and portable support for wide characters and wide strings. The
732 original implementation supports Unicode only. At the time, the CORBA specification
733 required wide characters, whether standalone or in a wide string, to be
734 marshaled as 16-bit quantities. This is the same size as the native wchar_t
735 type on Win32 platforms. However, the wchar_t type on UNIX and related
736 platforms is 32 bits in size. In addition, the General Inter-ORB Protocol
737 (GIOP) version 1.2 has changed the CDR transfer syntax for wide characters.
738 In the new version, a wide character is marshaled as a single byte indicating
739 the size of the wide character representation, followed by the specified
740 nunber of bytes. The IDL compiler's handling of wide characters needs to
741 be updated, both to handle the GIOP 1.2 CDR transfer syntax, and to be
742 portable under previous versions of GIOP. For more information about GIOP
743 CDR transfer syntax, see section 15.3 in the CORBA specification. and for
744 information about the marshaling of IDL character types specifically, see
747 </ul>
750 <hr>
751 <h3>
756 define general interfaces, and (4) provide necessary mechanisms for implementing
757 different concrete ORB and transport protocols. TAO's pluggable protocol
758 framework will allow disparate communication mechanisms to be supported
759 transparently, each with its own set of requirements and strategies.
760 <p>For example, if the ORB is communicating over a system bus, such as
761 PCI or VME, and not all the features of GIOP/IIOP are necessary and a simpler,
762 optimized ORB and transport protocol can be defined and implemented. Similarly,
763 it should be straightforward to add support for new transport protocols
764 that use native ATM or shared memory as the underlying communication mechanism.
765 In all cases the ORB's interface to the application will remain compliant
766 with the OMG CORBA standard.
769 example transport protocols, such as ATM and VME, and refine/optimize the
770 transport protocols framework, and (4) add support for pluggable ORB protocols,
771 e.g., replacements for GIOP. Each of these steps is outlined below:
772 <ul>
773 <li>
775 Bridge classes that decouple the transport-specific details from the rest
776 of TAO's ORB Core. This allows us to isolate the details of how messages
777 are communicated at the transport layer in a few classes. This design resulted
778 in the restructuring of the ORB Core and how requests are handled. For
779 instance, there is now the concept of communication layers: Objects (e.g.,
780 references, method invocations, etc.), ORB Messaging, Transport, and Network.
781 The Object layer is just the usual stubs and skeletons.</li>
783 <p>The common interfaces have been defined in the new abstract classes
784 that form the core of TAO's pluggable protocol framework, e.g.,
789 transport protocols are the
792 which are essentially Abstract Factories that produce the right types of
793 connector, acceptors, and transports.
794 <li>
796 This is important since there may be several different ways to access an
797 object. Each profile for an object may encode information pertaining to
798 QoS, network and transport protocols, addresses or routes.</li>
800 <li>
802 protocols are distributed with TAO:</li>
804 <ol>
805 <li>
806 UIOP: GIOP over local IPC (UNIX domain sockets)</li>
808 <li>
809 SHMIOP: GIOP over shared memory</li>
811 <li>
812 SSLIOP: GIOP over SSL (Secure Socket Layer)</li>
814 <li>
815 SCIOP: GIOP over SCTP</LI>
817 <li>
818 COIOP: GIOP collocated only. Will only work in a collocated environment, no remote calls are possible</li>
820 <li>
821 DIOP: GIOP over UDP/IP unicast</li>
823 <li>
824 MIOP: GIOP over UDP/IP multicast</li>
825 </ol>
826 Other interesting transport protocols could be for ATM, Buses (VME or PCI),
827 TP4, and GSMP. TAO users have also created their own pluggable transport
828 protocols, such as a ScramNet pluggable protocol.
829 <li>
831 besides GIOP. In particular, we will explore lightweight protocols using
832 shared memory and system buses like PCI or VME.</li>
833 </ul>
834 Current Status:
835 <ul>
836 <li>
837 The basic framework to support pluggable transport protocols has been completed.
843 using the new framework.</li>
845 <li>
846 Multiple endpoint support in the ORB has been added. A list of TAO_Acceptors
847 is kept in the Acceptor Registry. When the ORB needs to create an IOR it
848 iterates over all the acceptors to do so. Using either multiple <tt><a href="../ORBEndpoint.html">-ORBEndpoint</a></tt>
849 options or several endpoints separated by semi-colons ';', the user can
850 specify what addresses the ORB should use. Each endpoint is specified in
852 to support different protocols.</li>
854 <li>
855 If the user does not specify a list of endpoints then the ORB creates a
856 default endpoint for each protocol configured, unless the pluggable protocol
857 explicitly prevents that in an effort to prevent resource leaks.</li>
859 <li>
860 Added support for multiple Connectors in the ORB, the ORB finds the correct
861 connector based on the tag for the profile.</li>
863 <li>
864 Added support for multiple profiles in the IORs, when the ORB demarshals
865 an IOR it queries the Connector Registry to create the right kind of profile
866 for the known protocols. If one of the protocols is unknown we create a
867 special profile class that can only be used for marshaling and demarshaling,
868 not communication.</li>
870 <li>
871 Enabled the UIOP protocol. This protocol uses local IPC (aka UNIX domain
872 sockets) as the transport mechanism. The protocol is loaded by default.</li>
874 <li>
875 Enabled the SHMIOP protocol. This protocol uses shared memory as the transport
876 mechanism. The protocol is loaded by default.</li>
878 <li>
879 An IIOP over SSL pluggable transport called "SSLIOP" has been implemented.
880 It provides secure communication between hosts that support IIOP over SSL,
881 and is meant to be a drop-in replacement for the IIOP pluggable transport.
882 TAO's SSLIOP pluggable transport implementation supports both the standard
883 IIOP transport protocol and the secure IIOP over SSL transport protocol.</li>
885 <p>No changes were made to the core TAO sources to provide to this SSL
886 support, nor does TAO contain any security related hooks. TAO's SSLIOP
887 implementation is completely self-contained. This ensures that the core
888 TAO sources remains free of export restrictions.
889 <li>
890 Protocols can be dynamically loaded into the ORB: The default resource
891 factory reads the protocol "names" from its list of arguments. These protocol
892 names are used to load an abstract factory via the service configurator.
893 This factory can create acceptors or connectors on demand. By default only
894 IIOP is loaded.</li>
896 <li>
897 The service configurator is now used to load protocol factories.</li>
899 <li>
902 supersedes them, and provides the same functionality in a protocol-neutral
906 <li>
909 this option will be removed from future releases.</li>
911 <li>
912 The URL style object reference format has been updated to conform with
914 is:</li>
946 prevent ambiguities of where the rendezvous point ends and where the key
948 URL format may also be used.
949 <p>It should be noted that these formats have been superseded by the new
952 <li>
954 that the ORB has permission to read and write to. However, UIOP rendezvous
955 points have the same restrictions that local IPC has. The following are
956 some guidelines that will help ensure successful use TAO's UIOP pluggable
957 transport protocol:</li>
959 <blockquote>
960 <li>
961 To guarantee portability, local IPC rendezvous points (including the path
962 and filename) should not be longer than 99 characters long. Some platforms
963 may support longer rendezvous points, usually 108 characters including
964 the null terminator, but Posix.1g only requires that local IPC rendezvous
966 the null terminator.</li>
968 <P>If an endpoint is longer than what the platform supports then
969 it will be truncated so that it fits, and a warning will be issued.
970 <li>
975 working directory. If the client is not started in the directory where
977 able to communicate with the server since its point of communication, the
978 rendezvous point, was not found. On the other hand, if an absolute path
979 was used, the client would know exactly where to find the rendezvous point.</li>
981 <p>It is up to the user to make sure that a given UIOP endpoint is accessible
982 by both the server and the client.
983 <li>
984 It is important to be consistent in the use of absolute paths and relative
985 paths for rendezvous points. The two types of paths should not be used
989 it won't be used since the endpoint and preconnect are interpreted as different
991 On the other hand, if both the endpoint and the preconnect are the same
992 string then a preconnection will be established and used successfully.</li>
994 </blockquote>
996 a syntax similar to that of the URL style object reference shown above.
997 The only difference is that the object key delimiter and the object key
998 string are not specified.
999 <li>
1000 Added documentation that describes how to implement pluggable transport
1001 protocols for TAO. The document is available <a href="../pluggable_protocols/index.html">here</a>.</li>
1003 <li>
1004 TAO's IIOP pluggable protocol now supports automatic creation of profiles
1005 for endpoints created on a host with multiple network interfaces. It should
1006 no longer be necessary to manually specify an endpoint for each network
1007 interface.</li>
1009 <p>This means that server IORs will contain profiles for all of the default
1010 endpoints created on each network interface the server is listening on,
1011 if no explicit endpoints were specified.</ul>
1012 Known Issues:
1013 <ul>
1014 <li>
1015 </li>
1016 </ul>
1017 Critical Work:
1018 <ul>
1019 <li>
1020 None.</li>
1022 </ul>
1023 Future Work:
1024 <ul>
1025 <li>
1026 Complete support for multiple ORB messaging protocols.</li>
1028 <li>
1029 Long term work will include adding support for pluggable ORB protocols,
1030 as well as transport protocols. This way we can develop optimal messaging
1031 and transport protocols for a given platform.</li>
1032 </ul>
1034 <hr>
1035 <h3>
1038 <p>The POA associates servants with the ORB and demultiplexes incoming
1039 requests to servants.
1040 <p>Current Status:
1041 <ul>
1042 <li>
1043 TAO supports the POA spec. This section will carry updates as available.</li>
1044 </ul>
1045 Known issues:
1046 <br>Future work:
1047 <br>Recently completed work:
1048 <ul>
1049 <li>
1050 ORB::shutdown now properly deactives all the POA Managers.</li>
1052 <li>
1053 POA Managers in TAO were previously ignored in the request processing path
1054 on the server. This is now fixed such that their state is checked before
1056 is the request dispatched to the servant. Otherwise, the request is rejected.
1059 them before falling into the event loop.</li>
1061 <li>
1062 TAO's POA now properly supports both the threading policies: SINGLE_THREAD_MODEL
1063 and ORB_CTRL_MODEL.</li>
1065 <li>
1066 The synchronization in the POA is now very optimal. For example, the locks
1067 are not held across the invocation on the servant. The locks are also not
1068 held across the invocation on the AdapterActivator and ServantManagers.
1069 This allows us to use regular locks instead of recursive locks inside the
1070 POA. This also allows multiple threads to dispatch requests on the same
1071 POA simultaneous.</li>
1073 <li>
1074 Before 1.4.6 TAO supports reference counting between POA and servants, including
1075 the new RefCountServantBase and ServantBase_var classes. RefCountServantBase
1076 is a reference counted base class that was added to the CORBA specification
1077 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>
1078 contains the relevant text. Check <a href="../poa_migration.html#Reference counting Servants">here</a>
1079 on some hints to avoid trouble. From TAO 1.4.6 reference counting is always
1080 enabled for servants and RefCountServantBase is a noop struct you don't
1081 need anymore.</li>
1083 <li>
1084 The POA now supports active demultiplexing of servants in the SYSTEM_ID
1085 and the USER_ID policy. This should make the POA faster and more predictable
1086 since there is no hashing involved and the index of the slot where the
1087 servant is registered is in the Object Key.</li>
1089 <li>
1090 Previously, the complete POA name was used as the POA identity. This scheme
1091 was inefficient in many ways including: (a) the complete POA name can be
1092 significantly large in size, and therefore, ineffient to pass with every
1093 method call from the client to the server; (b) it is varible in size, and
1094 therefore, does not lend itself to smart and effective parsing; (c) the
1095 searching based on the complete POA name is very ineffient.</li>
1097 <p>The new solution is to use an active demux table, and flatten the POA
1098 hierarchy. This will help in the searching since active demuxing is fast
1099 and predictable. This will also help in the parsing since the demux key
1100 will be fixed size.
1101 <p>Note that for persistent ids, we have to pass the complete POA name
1102 in addition to the demux key in order to handle POA creation on demand.
1103 <li>
1104 There were some POA objects in a typical server that are not freed up properly,
1105 resulting in a memory leak. This has now been fixed.</li>
1107 <li>
1108 Timestamps in persistent IORs were not required and have been removed.</li>
1110 <li>
1111 POA exceptions are not not system exceptions and have been removed from
1112 the list of system exceptions.</li>
1114 <li>
1115 Vastly improved the ability of the POA to deal with user exceptions, memory
1116 allocation failures, and constructor failures.</li>
1118 <li>
1119 We now support a minimum POA for the minimum CORBA specification. Recently,
1120 this feature was enchanced such that the minimum CORBA footprint was further
1121 reduced. In addition, minimum POA can be enabled/disable irrespective of
1122 the minimum CORBA setting.</li>
1124 <li>
1125 We have decided not to support active demuxing for method name lookup.
1126 The benefit of this optimization was questionable since the current perfect
1127 hashing scheme provide very good and predictable behavior.</li>
1129 <p>Also, note that this optimization will require many changes. We would
1130 have to use the help of the IDL compiler to modify the object key that
1131 is passed for every method call differently. Note that this scheme doesn't
1132 work in the case of multiple inheritance or when the client stubs are not
1133 TAO.
1134 <li>
1135 Improved the parsing of object keys belonging to the RootPOA. Since this
1136 is the default POA and is commonly used, we have given it a reserved byte
1137 in the object key in order to quickly identify it. With the reserved bit,
1138 the active demux key for the RootPOA is not used, and no map lookups are
1139 required.</li>
1141 <li>
1142 POA name separator was changed from '/' to '\0'. Since POA names are strings,
1143 this makes a better choice since there is no chance of a conflict with
1144 the string specified by the user.</li>
1146 <li>
1147 We have support for reactivating servants with system generated ids.</li>
1149 <li>
1150 The TAO specific synchronization POA policy has been removed.</li>
1152 <li>
1153 New examples have been added to show how servants can be dynamically loaded
1154 from DLLs on demand.</li>
1156 <li>
1157 Support for collocation should be much better now because the POA can tell
1158 if we created the object reference.</li>
1160 <li>
1161 After Nanbor's recent changes for collocation, we support the full semantics
1162 of remote objects on a collocated object. The spec mandates that collocated
1164 going through the POA, running the Servant Managers, running the interceptors,
1165 and expecting the reference counting behavior provided by the POA. Note
1166 that the old scheme of direct call through to the servant is also still
1167 available.</li>
1169 </ul>
1171 <hr>
1173 <h3>
1177 <p>OMG defined CORBA Naming Service (spec <a href="ftp://ftp.omg.org/pub/docs/formal/97-07-12.pdf">here</a>)
1178 to provide a basic service location mechanism for CORBA systems. CosNaming
1179 manages a hierarchy of name-to-object-reference mappings. Anything, but
1180 typically the server process hosting an object, may bind an object reference
1181 with a name in the Naming Service by providing the name and object reference.
1182 Interested parties (typically clients) can then use the Naming Service
1183 to resolve a name to an object reference.
1184 <p>More recently, CORBA Naming Service was subsumed/extended by the CORBA
1185 Interoperable Naming Service, a.k.a. INS (spec <a href="ftp://ftp.omg.org/pub/docs/orbos/98-10-11.pdf">here</a>).
1186 INS inherits all the functionality from the original Naming Service specification
1187 in addition to addressing some its shortcomings. In particular, INS defines
1188 a standard way for clients and servers to locate the Naming Service itself.
1189 It also allows the ORB to be administratively configured for bootstrapping
1191 page</a> provides a brief description of additional features INS provides,
1192 and how they are implemented in TAO.
1194 <ul>
1195 <li>
1198 </ul>
1199 Recent work:
1200 <ul>
1201 <li>
1202 Changed default for multicast discovery to</li>
1203 </ul>
1204 Features:
1205 <ul>
1206 <li>
1207 Added support for Persistence (using memory-mapped files). Persistence
1208 feature is optional, and is controlled by the command line argument.</li>
1210 <li>
1211 Updated the implementation of the Naming Service to use new ACE exception
1212 macros.</li>
1214 <li>
1215 Added support for the InterOperable Naming Service, which enables the ORB
1217 allow the ORB to be configured to return arbitrary object references from
1219 for non-locality-constrained objects. Two options -ORBInitRef and -ORBDefaultInitRef
1220 have been added to the orb for bootstrapping to arbitrary services.</li>
1222 <li>
1223 Added support for the Naming service to act like an agent: to understand
1224 IIOP request messages from clients and respond with reply messages with
1226 can be configured through ORB options to register arbitrary services given
1227 the URL-format IOR for the service. The <tt>resolve_initial_references
1230 <ol>
1231 <li>
1234 <li>
1237 <li>
1238 Multicast discovery</li>
1239 </ol>
1241 <li>
1242 Added a test for the InterOperable Naming Service that works in conjunction
1243 with the current TAO examples.</li>
1245 <li>
1246 Implementation of the CORBA INS spec is completed. The following features
1247 are now supported:</li>
1249 <ul>
1250 <li>
1251 corbaname format</li>
1253 <li>
1254 NamingServiceExt interface</li>
1255 </ul>
1256 </ul>
1257 Future work:
1258 <ul>
1259 <li>
1260 Support for a load balancing feature similar to the one present in ORBIX.
1261 It will be possible to bind a group of objects under a single name, and
1262 when a client attempts to resolve the name in question, a preset policy
1263 (e.g., random, round robin, etc.) will determine which one of the object
1264 references from the group will be returned.</li>
1266 <li>
1267 Support for the Naming Service to handle the IIOP LocateRequest messages
1268 and respond with LocateReply messages with a
1270 status.</li>
1271 </ul>
1273 <hr>
1274 <h3>
1277 <p>The <a href="http://www.omg.org/technology/documents/formal/trading_object_service.htm">Trading
1278 Service</a> is an implementation of the COS Trading Service speficiation
1279 that meets the Linked Trader conformance criteria --- it implements the
1284 features:
1285 <ul>
1286 <li>
1287 Multithreaded operation;</li>
1289 <li>
1290 Trader federations and distributed queries;</li>
1292 <li>
1293 Dynamic properties;</li>
1295 <li>
1296 Modifiable properties;</li>
1298 <li>
1299 All policies described in the specification;</li>
1301 <li>
1302 Preference sorting;</li>
1304 <li>
1305 Service type inheritance hierarchies and subtype searching.</li>
1306 </ul>
1308 <p>Future Work:
1309 <ul>
1310 <li>
1311 The Proxy Interface.</li>
1313 <li>
1314 Persistent storage of service types and offers.</li>
1315 </ul>
1317 <hr>
1318 <h3>
1322 have been implemented. Please go through the test examples at $TAO/orbsvcs/tests/CosPropertyService.
1324 Streaming Service</a>developed for TAO. For general documentation of the
1325 Property Service, please read <a href="http://www.omg.org/technology/documents/formal/property_service.htm">The
1326 Property Service Specification.</a>
1327 <p>Recent Work:
1328 <ul>
1329 <li>
1330 Changed the PropertyException from Exception to struct, according to the
1331 OMG's changes.</li>
1333 <li>
1334 Changed the implementation to allocate storage for the Sequence out parameters,
1336 </ul>
1338 <hr>
1339 <h3>
1342 <p>Current status (as of May 3rd): The <a href="http://www.omg.org/technology/documents/formal/concurrency_service.htm">Concurrency
1343 Service</a> provides a mechanism that allows clients to acquire and release
1344 various types of locks in a distributed system.
1345 <ul>
1346 <li>
1347 A simple version of the Concurrency Service has been implemented, i.e.
1348 a version without transactions. It is currently being tested.</li>
1349 </ul>
1350 Future Work:
1351 <ul>
1352 <li>
1353 Implementation of the Concurrency Service with transactions</li>
1354 </ul>
1357 <h3>
1360 <p>This is an implementation of the OMG spec addressing the <a href="http://www.omg.org/technology/documents/formal/audio.htm">Control
1361 and Management of Audio/Video Streams</a>. For more documentation on TAO's
1363 <h4>
1364 Current Status:</h4>
1365 (as of July 30 2002)
1366 <ul>
1367 <li>
1368 The audio/video streaming service has been implemented in the full profile.
1369 The current implementation support all the flow related components like
1370 flowEndpoint,FDev,FlowConnection,..,etc.</li>
1372 <li>
1373 Point-to_Point and Point-to-MultiPoint streams have been implemented.</li>
1375 <li>
1376 A Pluggable protocols framework has been implemented to flexibly add new
1377 flow protocols like SFP, RTP and new transports like ATM. The current implementation
1378 has protoocol implementations for SFP, RTP over UDP and Multicast UDP.
1379 Please look at <tt><a href="../../orbsvcs/orbsvcs/AV/AV_Pluggable_Framework.html">orbsvcs/orbsvcs/AV/AV_Pluggable_Framework.html</a></tt>for
1380 more documentation about the implementation.</li>
1382 <li>
1383 QoS_UDP pluggable protocol added which implements RSVP QoS support for
1384 UDP streams.</li>
1386 <li>
1387 Diffserv support added to the UDP pluggable protocol by <a href="mailto:crodrigu@bbn.com">Craig
1390 <li>
1391 RTP/UDP support enhancements and RTCP control protocol support added by
1394 </ul>
1395 Work in progress:
1396 <ul>
1397 <li>
1399 UAV software.</a></li>
1400 </ul>
1402 <hr>
1406 allows clients to connect to Time Service Clerks and obtain globally synchronized
1407 time. This time is calculated from the time obtained from one or more Time
1408 Servers running on multiple machines in the network. The service uses the
1409 TAO Implementation Repository to activate the time servers on demand.
1411 <ul>
1412 <li>
1413 Implementation of a Distributed CORBA Time Service is complete.</li>
1414 </ul>
1415 Future work:
1416 <ul>
1417 <li>
1418 Currently the average of the time obtained from the various servers is
1419 considered the global notion of time. A better distributed time synchronization
1420 algorithm can be used in the future.</li>
1422 <li>
1423 Implementation of the Timer Event Service.</li>
1424 </ul>
1427 <h3>
1430 <h4>
1433 <p>The COS compliant Event Service implements the Event Service Specification:
1436 <br>The different command line and service configurator options used
1437 for configuring the CORBA event services are located <A
1439 the Real Time Event service.
1440 <h3>
1441 Features in this release:</h3>
1443 <ul>There is a new implementation of the COS Event Service available. This
1444 new implementation supports both the Push and Pull styles for event communication,
1445 and it does not require the Real-time Event Service to work.
1446 <p>A new testsuite for the COS Event Service has been started, they are
1448 <p>A new example for the COS Event Service is provided in <tt>$TAO_ROOT/orbsvcs/examples/CosEC/Simple/</tt>
1449 <p>A new binary to run the native COS Event Service was added, it is compiled
1451 <li>
1453 how to create and use the event channel.</li>
1455 <li>
1457 creates a COS compliant event channel and registers it with the naming
1460 <br>Please read the associated README for more details.
1461 <li>
1463 test demonstrates how multiple CosEC's connect to one RtEC and how multiple
1464 consumers and producers exchange events in this configuration.</li>
1465 </ul>
1467 <h3>
1468 Known bugs:</h3>
1470 <ul>
1471 <li>
1473 the tests are done, the control doesn't return to the shell, you have to
1474 say CTRL-C to get back to the prompt.</li>
1475 </ul>
1478 <h3>
1481 <h4>
1486 <h3>
1487 Features supported in the current version:</h3>
1489 <ul>
1490 <li>
1494 <li>
1498 <li>
1499 Support for the <tt>DsNotifyLogAdmin </tt>module, which uses the <a href="#notify">Notification
1502 <li>
1506 <li>
1508 has been added.</li>
1510 <li>
1514 <ul>
1515 <li>
1518 <li>
1521 <li>
1524 <li>
1527 <li>
1528 Each service registers with the Naming Service as
1532 <li>
1533 Each service registers with the Interoperable Naming Service as
1537 <li>
1538 The Log Service uses a dynamically loaded "plug-in" Strategy for storing and
1539 querying log records. The default Strategy stores Log records in memory and
1540 supports the Extended Trader Constraint Language (ETCL) Query Language.</li>
1542 <li>
1543 There are now examples that demonstrate simple usage of the Log Services.
1545 sub-directories.</li>
1548 tests most of the features of the basic logging service.</li>
1549 </ul>
1551 <h3>
1552 Future work and enhancements:</h3>
1554 <ul>
1555 <li>
1556 Provide Strategies that support persistent storage of log records.</li>
1558 <li>
1559 Change default Strategy to use Red-Black trees to optimize lookup on
1560 frequently used query keys - namely record id's and time.</li>
1561 </ul>
1564 <h3>
1567 <h4>
1571 Service </a>implementation consists of the following (see the associated
1572 README's for more information):
1573 <ul>
1574 <li>
1575 The implementation of the interfaces in the Notification Service spec is
1579 <li>
1580 The service driver is implemented in <tt><a href="../../orbsvcs/Notify_Service">$TAO_ROOT/orbsvcs/Notify_Service</a></tt>.</li>
1582 <br>The various options of the Notify_Service are described <a href="notify.html#notify_Service">here
1583 </a>.
1584 <li>
1585 The example in <tt><a href="../../orbsvcs/examples/Notify/Filter">$TAO_ROOT/orbsvcs/examples/Notify/Filter</a></tt>
1586 shows a basic example of using filters.</li>
1588 <li>
1589 The example in <tt><a href="../../orbsvcs/examples/Notify/Subscribe">$TAO_ROOT/orbsvcs/examples/Notify/Subscribe</a></tt>shows
1590 a basic example of how to use subscriptions.</li>
1592 <li>
1593 Feature unit tests are under <tt><a href="../../orbsvcs/tests/Notify">$TAO_ROOT/orbsvcs/tests/Notify</a></tt></li>
1595 <li>
1597 the features implemented.</li>
1598 </ul>
1599 <i>Note that this implementation does not support Pull interfaces and Typed
1600 Event style communication.</i>
1601 <p>
1603 <h3>
1606 <h4>
1609 <p>This is an extension to TAO's CORBA Notification Service with Real-Time
1610 CORBA support.
1612 <ul>
1613 <li>
1614 <b>Interface Extensions:</b> The <a href="../../orbsvcs/orbsvcs/NotifyExt.idl">$TAO_ROOT/orbsvcs/orbsvcs/NotifyExt.idl</a>
1615 extends the ConsumerAdmin and SupplierAdmin interfaces. The <tt>obtain_notification_push_supplier_with_qos</tt>
1617 used to specify QoS parameters.</li>
1619 <li>
1622 <ul>
1623 <li>
1624 ThreadPoolParams: This specifies the parameters for creating a threadpool
1625 in an RT POA.</li>
1627 <li>
1628 ThreadPoolLanesParams: This specifies the parameters for creating a threadpool
1629 with lanes in an RT POA.</li>
1630 </ul>
1631 </ul>
1633 <ul>
1634 <li>
1636 </a></tt>example
1637 shows how to use RTCORBA Lanes in RT Notification.</li>
1639 <li>
1640 The <tt><a href="../../orbsvcs/examples/Notify/ThreadPool">$TAO_ROOT/orbsvcs/examples/Notify/ThreadPool</a></tt>
1641 example shows how to use RTCORBA ThreadPools in RT Notification.</li>
1642 </ul>
1643 The performance tests for RT Notification measure the throughput, latency
1644 and jitter for various test configurations using Periodic Suppliers:
1645 <ul>
1646 <li>
1647 <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>
1649 <br>This configuration measures performance for a single data path when
1650 the load is increased. The Supplier sends events in a single burst.
1651 <li>
1652 <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>
1655 and low priorities when the Load is increased. The Suppliers send events
1656 at 100Hz.
1657 <li>
1658 <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>
1661 paths. we measure the performance of the high priority path as a function
1662 of the number of low priority paths.
1663 <li>
1664 <tt><a href="../../orbsvcs/tests/Notify/performance-tests/scripts/Max_Throughput">$TAO_ROOT/tests/Notify/performance-tests/scripts/Max_Throughput</a></tt></li>
1666 <br>This Configuration measures the performance obtained for a data path
1667 using a Structured Event payload:
1668 <ul>
1669 <li>
1670 directly between a Supplier and Consumer in separate processes.</li>
1672 <li>
1673 directly between a colocated Supplier and Consumer.</li>
1675 <li>
1678 <li>
1679 between a a Supplier and Consumer using the Notification Service.</li>
1680 </ul>
1681 </ul>
1683 <br>The <tt><a href="../../orbsvcs/tests/Notify/lib">$TAO_ROOT/orbsvcs/tests/Notify/lib</a></tt>
1684 contains a scripting based test framework which can be used to quickly
1685 create test cases. The framemork and its options are described <a href="notify.html#test_framework">here. </a><!-- BEGIN: CORBA Security Service Release Notes -->
1687 <h3>
1690 <p>Additional information is available
1695 TAO's current Security Service support implements the core
1696 functionality of the <a href="http://www.omg.org/cgi-bin/apps/doc?formal/02-03-11.pdf">CORBA Security Service v1.8</a>.
1697 <p>
1698 In particular, it implements the most of the CORBA <a href="../../orbsvcs/orbsvcs/SecurityLevel1.idl">SecurityLevel1 API</a>,
1699 in addition to some of <a
1701 Of the transport protocols described in the above specification, only
1702 SSLIOP is supported. Documentation for TAO's SSLIOP pluggable
1705 <p>
1706 The 1.8 specification defines the Common Secure Interoperability version
1707 1 (CSIv1) protocol that is currently implemented in TAO.
1709 <p>
1710 There are basically two ways to use security in TAO:
1711 <ol>
1712 <li>
1713 Use TAO's SSLIOP pluggable transport in TAO alone. This allows one
1714 to secure application requests without modifying the application code.
1715 This is the easiest approach but is also the least flexible.
1716 </li>
1717 <li>
1718 Use the Security Service API implemented by TAO in conjunction with
1719 TAO's SSLIOP pluggable transport. This provides the benefits of
1720 secured application requests with the flexibility of disabling
1721 security in some requests, if so desired. This approach also allows
1722 one to choose at run-time which X.509 certificates will be associated
1723 with application requests, as opposed to setting configuring only one
1724 SSL certificate at application start-up-time. These things are
1725 basically configured using the SecurityLevel2 or SecurityLevel3
1726 defined policies:
1728 <blockquote><code>
1729 SecurityLevel2::QOPPolicy<br>
1730 SecurityLevel2::EstablishTrustPolicy<br>
1731 SecurityLevel3::ContextEstablishmentPolicy<br>
1732 </blockquote></code>
1733 </li>
1734 </ol>
1738 pluggable transport</a>.
1739 <ul>
1740 <li>
1742 the SSL session state for the current execution context. This is useful
1743 for obtaining the SSL peer certificate chain associated with the current
1744 request, for example.</li>
1746 <li>
1747 TAO's SSLIOP pluggable transport now registers a secure invocation server
1748 request interceptor. It enforces secure invocation by rejecting requests
1749 coming in on the insecure port if the server is configured to do so (default
1750 behavior).</li>
1752 <li>
1755 <li>
1757 policy is used to set the desired invocation Quality-of-Protection (QoP).
1761 meaning that this policy can be set on a per-ORB, per-thread or per-object
1762 basis.</li>
1764 <p>This policy makes it possible to, for example, make both secure and
1765 insecure invocations within the same client process.
1766 <li>
1767 TAO's SSLIOP pluggable transport implementation is now thread-safe.</li>
1769 <li>
1771 This policy is used to set the desired invocation level of establishment
1773 in conjunction with the standard policy manipulation CORBA features (e.g.
1776 per-thread or per-object basis.</li>
1778 <p>This policy makes it possible to, for example, make authenticated and
1779 non-authenticated invocations within the same client process.
1780 <li>
1783 implementation is now available.</li>
1784 <li>
1785 Implemented basic (stateless) CSIv2 support. Advanced CSIv2
1786 features, such as identity assertion, are currently under
1787 development.
1789 </ul>
1790 </ul>
1792 <ul>
1793 <li>
1794 Began implementation of the interfaces in the
1796 ability to replace key security components in the ORB with
1797 another implementation with ease. Thus, the security
1798 components in the ORB become highly extensible.</li>
1799 <li>
1804 <li>
1805 Advanced CSIv2 features, such as identity assertion, are
1806 currently under testing.</li>
1807 </ul>
1809 <ul>
1810 <li>
1813 <ul>
1814 <li>
1815 Complete integration of the Common Secure Interoperability
1819 href="http://www.omg.org/technology/documents/formal/atlas.htm">Authorization Token Layer Acquisition Service (ATLAS)</a>.
1820 <p>
1821 CSIv2 and ATLAS address many of the shortcomings of the
1822 current CSIv1-based Security Service. Overviews of each are
1823 available on the <a href="http://www.omg.org/technology/documents/formal/omg_security.htm">OMG Security</a> web page.
1824 <blockquote><em>
1825 Note that CSIv2 as defined by the CORBA 3.0.x specification
1826 has no API so TAO's implementation will use a slightly
1827 <a
1828 href="http://adiron.com/ORBAsec/3.5.0/docs/SL3/#SecurityLevel3API">modified API</a> currently used by several ORBs defined by Adiron LLC.
1829 </em></blockquote>
1831 </li>
1832 </ul>
1833 <!--
1834 <LI>
1835 <FONT COLOR=BLUE>November 2002</FONT>
1836 <UL>
1837 <LI>
1838 Request authentication via
1839 <A HREF="http://web.mit.edu/kerberos/www/">Kerberos</A>, as
1840 detailed in the CORBA Security Service specification. This
1841 requires the Common Secure Interoperability protocol (CSIv2),
1842 but initial experiments will be performed via TAO's existing
1843 SSLIOP pluggable transport.
1844 </LI>
1845 <LI>
1846 Partial implementation of the <CODE>SecurityLevel2</CODE>
1847 interfaces. This includes the <CODE>Credential</CODE> and
1848 <CODE>Current</CODE> objects.
1849 </LI>
1850 <LI>
1851 Partial implementation of the <CODE>SecurityAdmin</CODE>
1852 interfaces.
1853 </LI>
1854 <LI>
1855 Begin implementation of <CODE>SecurityAudit</CODE> objects.
1856 As a side benefit, this project will allow us to research how
1857 to secure existing services such as
1858 <A HREF="ec.html">TAO's Real-Time Event Service</A>.
1859 </LI>
1860 </UL
1861 </LI>
1862 <li>
1863 <font color="#0000FF">December 2002</font></li>
1865 <ul>
1866 <li>
1867 Begin implementation of the <i>Resource Access Decision (RAD) Facility</i>
1868 specification for TAO.</li>
1869 </ul>
1871 <li>
1872 <font color="#0000FF">February 2003</font></li>
1874 <ul>
1875 <li>
1876 Begin implementation of the <i>Security Domain Membership Management (SDMM)</i>
1877 specification for TAO. It is needed to support security domains.</li>
1878 </ul>
1880 <li>
1881 <font color="#0000FF">April 2003</font></li>
1883 <ul>
1884 <li>
1885 SSLIOP and SECIOP performance enhancements.</li>
1886 </ul>
1887 -->
1888 </ul>
1889 <!-- END: CORBA Security Service Release Notes -->
1891 <!--#include virtual="ec.html" -->
1892 <p>
1893 <hr>
1894 <h3>
1898 Levine</a>
1899 <p>Currently Implemented Features:
1900 <ul>
1901 <li>
1902 The scheduling service can be built to use either a null implementation
1903 or a strategized implementation of the configuration scheduler.</li>
1905 <li>
1906 The null scheduler implementation, which is built by default, allows the
1907 configuration scheduler to be used with applications that require a scheduling
1908 service interface, but do not (at least in the current stage of their development,
1909 in certain configurations, etc.) make use of the real-time scheduling features
1910 it provides.</li>
1912 <li>
1913 The strategized scheduler implementation can be built by #defining TAO_USES_STRATEGY_SCHEDULER,
1914 and the appropriate scheduling strategy macro (TAO_USES_RMS_SCHEDULING,
1915 TAO_USES_EDF_SCHEDULING, TAO_USES_MUF_SCHEDULING, or TAO_USES_MUF_SCHEDULING)
1916 in $ACE_ROOT/ace/config.h. This allows the configuration scheduler to be
1917 used with applications that require a specific scheduling strategy. Each
1918 scheduling strategy will produce a set of static scheduling priorities,
1919 which it will assign to operations based on their RT_Infos. For each static
1920 priority, a strategy will also determine the run-time (dynamic) scheduling
1921 strategy to use for that priority level.</li>
1922 </ul>
1923 Future work:
1924 <ul>
1925 <li>
1926 Implement heap-based dispatching queues.</li>
1928 <li>
1929 Add support for additional configurability, especially in the type of dispatching
1930 strategy (list vs. heap) that will be used to dispatch operations at a
1931 given static priority level.</li>
1933 <li>
1934 Benchmark the various alternative strategies to obtain performance profiles
1935 across different operation loads and OS platforms.</li>
1937 <li>
1938 Add increased functionality. Requests and suggestions are welcome.</li>
1939 </ul>
1941 <hr>
1942 <h3>
1945 Natarajan</a>
1946 <h4>
1947 Current Status:</h4>
1948 TAO supports the ORB level requirements to achieve Fault Tolerance for
1949 CORBA Objects. The details of the ORB level support is described in the
1950 FT chapter of the
1955 <p>
1957 </p>
1959 <h4>
1960 Future Work:</h4>
1962 <ul>
1963 <li>
1965 </ul>
1967 <hr>
1968 <h3>
1971 <h4>
1972 Current Status:</h4>
1973 TAO's
1976 Balancing and Monitoring</i> proposed specification.
1977 <p>It provides many features and advantages over the previous prototype.
1978 Those features and advantages include:
1979 <ul>
1980 <li>
1981 Multiple object group support</li>
1983 <li>
1984 Extensible load balancing strategies through IDL interfaces</li>
1986 <li>
1987 Extensible load monitoring</li>
1989 <li>
1992 <li>
1993 Support for infrastructure and application controlled object group membership</li>
1995 <li>
1996 Improved server-side transparency</li>
1997 </ul>
1999 defines three built-in load balancing strategies. They are:
2000 <ol>
2001 <li>
2004 <li>
2007 <li>
2010 </ol>
2011 TAO implements all of these and the following load balancing strategies:
2012 <ol>
2013 <li>
2016 <li>
2019 </ol>
2020 <h4>
2021 Known Issues:</h4>
2023 <ul>
2024 <li>
2025 CPU load monitoring is not working in Windows.
2026 </li>
2027 </ul>
2029 <h4>
2030 Recent Work:</h4>
2032 <ul>
2033 <li>
2036 <li>
2039 <li>
2040 Implemented a CPU load utilization monitor in Linux.
2041 </li>
2042 </ul>
2044 <h4>
2045 Future Work:</h4>
2047 <ul>
2048 <li>
2049 Implement cooperative (distributed) load balancing support</li>
2051 <li>
2052 Integrate multicast support</li>
2053 <li>
2054 Implement a middleware load balancing performance measurement toolkit</li>
2055 <li>
2056 Implement self adaptive load balancing strategies</li>
2058 </ul>
2060 <hr>
2061 <h3>
2064 <h4>
2065 Current Status:</h4>
2067 specification</a> has recently been adopted by the OMG. TAO's MIOP support
2068 (located in $TAO_ROOT/orbsvcs/orbsvcs/PortableGroup) enables servants to
2069 receive requests sent to multicast addresses. This is performed by creating
2070 a GroupId that identifies the multicast group and associating it with one
2071 or more servants. Additionally, the Unreliable IP Multicast (UIPMC) pluggable
2072 protocol is used to send and receive multicast requests. Multicast endpoints
2073 can be created dynamically at runtime.
2074 <h4>
2075 Known Issues:</h4>
2077 <ul>
2078 <li>
2079 MIOP packet reassembly is not performed yet, so the maximum request size
2081 </ul>
2083 <h4>
2084 Recent Work:</h4>
2086 <ul>
2087 <li>
2088 Initial check in of MIOP implementation.</li>
2089 </ul>
2091 <h4>
2092 Future Work:</h4>
2094 <ul>
2095 <li>
2096 Allow group references to be disassociated when no longer needed.</li>
2098 <li>
2099 Implement MIOP packet reassembly.</li>
2101 <li>
2102 Implement a Multicast Group Manager (MGM).</li>
2104 <li>
2105 Implement a Multicast Gateway (MG).</li>
2106 </ul>
2108 <hr>
2109 <h3>
2111 [Note: This section is not uptodate. Use with caution. February 2004.]
2112 <br>
2114 <p>Current Status:
2115 <p>The TAO IDL_Cubit test application makes use of the Naming Service and
2116 the server holds a TAO_Naming_Server component.Just running server and
2117 client is enough to test the application.
2118 <p>The various tests in the tests/POA test the different features of the
2119 Portable Object Adapter interface like Explicit Activation, On Demand Activation,etc..
2120 <p>MT_Cubit:
2121 <p>Current status:
2122 <p>The TAO MT_Cubit test application is meant to serve as a starting point
2123 for real-time tests on the TAO system. It comprises the following parts:
2124 <ul>
2125 <li>
2127 with different real-time priorities. This priority is implemented by using
2128 real-time thread support provided by the operating system. Thus, requests
2129 sent to a high-priority servant are handled by a high-priority real-time
2130 thread, and those sent to a lower priority servant are handled by correspondingly
2131 lower priority threads.</li>
2133 <li>
2135 stream of CORBA requests to the servants. It measures the response time,
2136 i.e. the time taken for the request to complete successfully. In particular,
2137 it measures the time taken for requests sent to the high priority servant
2138 to complete. The volume of lower priority requests is configurable. The
2139 client is thus able to measure the performance of the high-priority servant
2140 in the presence of competition from several lower-priority servants.</li>
2141 </ul>
2142 Clearly, if the ORB endsystem handles the priorities of the various requests
2143 correctly, increasing the volume of lower priority requests should not
2144 affect the performance seen by the higher priority requests. The application
2145 thus serves as a tool to measure and confirm this behavior.
2146 <p>Future work:
2147 <ul>
2148 <li>
2151 <li>
2152 Evolve into a testbed for discovering sources of performance non-determinism
2154 </ul>
2155 Pluggable:
2156 <p>Current status:
2157 <p>The TAO Pluggable test utilizes ACE Timeprobes to time the latency at
2158 various points in the ORB, especially that incurred by the Pluggable Protocols
2159 implementation. Comparisons can be made not only between different layers
2160 of the ORB, but also between different protocols as they become available.
2161 <p>Future work:
2162 <ul>
2163 <li>
2164 Add options to redirect the output to a file.</li>
2166 <li>
2167 Script or otherwise automate the piping of the output to a spreadsheet.</li>
2168 </ul>
2170 <hr>
2171 <h3>
2175 <p>Recently Completed Work:
2176 <ul>
2177 <li>
2179 because VxWorks doesn't provide full argument prototypes for these library
2180 functions.</li>
2182 <li>
2183 The current caching connector behaves properly in the face of a non-blocking
2184 connect request. The "fix" is simply to not support non-blocking connects
2188 <li>
2189 Service handlers obtained from the caching connector are now cleaned up.
2190 The application needs to be able to signal that it's not using it any longer,
2191 and, when the application encounters an error, needs to effectively close
2192 down that connection for good so that a new connection can be initiated.</li>
2194 <br>Added the ability for a Svc_Handler to recycle itself. idle() can be
2195 called when the Svc_Handler is done serving a particular connection and
2196 can how be recycled. The Svc_Handler now also has a pointer to a recycler
2197 that is responsible for managing the connections. The recycler is usually
2198 a Cached_Connector.
2199 <br>Added new class ACE_Recycling_Strategy. It defines the interface (and
2200 default implementation) for specifying a recycling strategy for a Svc_Handler.
2201 This strategy acts as a consular to the Svc_Handler, preparing it for the
2202 tough times ahead when the Svc_Handler will be recycled.
2203 <br>Added new class ACE_NOOP_Concurrency_Strategy. It implements a no-op
2204 activation strategy in order to avoid calling open on a recycled svc_handler
2205 multiple times.
2206 <br>ACE_Cached_Connect_Strategy now implements the ACE_Connection_Recycling_Strategy
2207 interface. This allows Svc_Handlers to cache themselves with ACE_Cached_Connect_Strategy
2208 when they become idle. It also allows them to purge themselves from the
2209 connection cache when the Svc_Handlers close down.
2210 <br>Also added ~ACE_Cached_Connect_Strategy that will cleanup up the connection
2211 cache.</ul>
2212 Future work:
2215 <hr>
2216 <h3>
2222 This discussion focuses on the following goals:
2223 <ul>
2224 <li>
2225 Have a DOVE Browser running using Java Beans as vizualization components.</li>
2227 <li>
2228 Have the Event Channel as DOVE Agent running with an Event Consumer in
2229 the DOVE Browser.</li>
2231 <li>
2232 Having a DOVE Management Information Base (MIB), which dumps all events
2233 transfered on the Event Channel into a file on persistent storage for later
2234 reuse.</li>
2235 </ul>
2236 The DOVE Browser uses independent visualization components (Java Beans)
2237 and the Event Channel as DOVE Agent. Connections can be established between
2238 monitored metrics and the visualization components.
2239 <p>We have three major components: Observables (monitored metrics), Observers
2240 (a Java Bean for displaying the metric) and a DataHandler (for demultiplexing
2241 the monitored metrics to the appropriate Observables). Each component inherits
2242 from a base class, so that a certain behavior of the components can be
2243 assured for each component. Relationships between components are based
2244 on these base classes.
2245 <p>The used Java Beans are required to conform to some standards, as they
2246 have to support a function called "getProperty" which allows the DOVE Browser
2247 to determine if the vizualization capabilities of a specific Java Bean
2248 are sufficient to display the metric. A JavaBean is for example a Java
2249 Panel which shows a Graph of the delivered doubles. So all metrics can
2250 be displayed by this visualization component which can be expressed by
2251 a single double.
2252 <p>The DataHandler is connected to the Event Push Consumer (PUSH, because
2253 we use the push concept of the Event Service). The Event Push Consumer
2254 does not know what kind of data is transported. The only component knowing
2255 all the details about the dependencies of the metrics is the DataHandler.
2256 This separation allows easy extension and change of the demo.
2258 are available about this new concept.
2259 <p>Event Service events are used as communication between DOVE Applications
2260 and the DOVE Browser. The DOVE MIB analyses the event data field of all
2261 events and stores this information into a file. The event data filed is
2262 of type CORBA::Any and the DOVE MIB has no notion of what is conveyed in
2263 this field. So the DOVE MIB has to discover the content via the embedded
2264 type code information. Future work includes:
2265 <ul>
2266 <li>
2267 Enhancing MIB functionality</li>
2269 <li>
2270 Monitoring the AV Streaming Service</li>
2271 </ul>
2272 For more information on the DOVE demo, please refer to: $TAO_ROOT/orbsvcs/tests/Simulator/README.
2273 <p>
2274 <hr>
2275 <h3>
2279 Kircher</a>.
2281 <p>
2282 <hr>
2283 <h3>
2287 Kircher</a>.
2289 model</a>
2290 <p>
2291 <hr>
2292 <h3>
2296 Kircher</a>.
2298 <p>
2299 <hr>
2300 <h3>
2304 and
2306 <p>Status:
2307 <ul>We've implemented the callback model of the
2309 Messaging specification</a>. To activate the AMI for TAO and the TAO IDL
2312 in your config.h file. The TAO IDL compiler can generate the AMI "callback"
2315 Finished work:
2316 <ul>
2317 <li>
2318 Redesign of the IDL compiler to make an additional pass over the AbstractSyntaxTree
2319 and generate the implied-IDL code in memory. This reduced the amount of
2320 AMI specific IDL compiler code dramatically.</li>
2322 <li>
2323 Support for exceptions</li>
2325 <li>
2326 Support for attributes</li>
2328 <li>
2329 Support for buffering and batching AMI calls. See <a href="../../examples/Buffered_AMI">Buffered
2332 <li>
2333 Support for deferred synchronous invocations.
2335 Parsons</a></li>
2337 <li>
2338 Support for timeouts in combination with AMI calls, response handler gets
2339 CORBA::TIMEOUT exception on timeout</li>
2340 <li>
2343 </ul>
2344 Future Work:
2345 <ul>
2346 <li>
2347 Implementation of the poller model.</li>
2348 </ul>
2349 <hr>
2350 <h3>
2353 <h4>
2354 Current Status:</h4>
2355 <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.
2356 <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.
2357 <p>Two approaches are supported for applying CSD strategy to an application.
2358 <ol>
2359 <li>Explicitly calling CSD interfaces.
2360 <p>Here is an example application code showing how a TP_Strategy object can be created and applied to a POA:
2362 <pre>
2364 PortableServer::POA_var poa = ...; // create the poa.
2366 // Create a new TP_Strategy object and save it into a "smart pointer" variable.
2367 TAO::CSD::TP_Strategy_Handle csd_strategy = new TAO::CSD::TP_Strategy();
2369 // Set the number of threads before calling apply_to().
2372 // Set the servant serialization flag before calling apply_to().
2373 csd_strategy->set_servant_serialization (false);
2375 // Tell the strategy to apply itself to the poa.
2376 if (csd_strategy->apply_to(poa.in()) == false)
2377 {
2378 ACE_ERROR((LM_ERROR, "Failed to apply CSD strategy to the poa.\n"));
2379 return -1;
2380 }
2381 </pre>
2382 <li>Service Configurator
2384 <p>The format of the CSD specific parameters for creating the TP_Strategy service object is:
2387 <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).
2389 <p>Here is an example of the svc.conf file.
2391 <pre>
2392 dynamic TAO_CSD_TP_Strategy_Factory Service_Object *
2393 TAO_CSD_ThreadPool:_make_TAO_CSD_TP_Strategy_Factory() "-CSDtp RootPOA:2"
2394 </pre>
2395 </ol>
2396 </ul>
2397 <h4>
2398 Known Issues:</h4>
2399 <ul>
2400 <li>
2401 This feature is not currently tested for VxWorks.
2402 </li>
2403 <li>
2404 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>.
2405 </li>
2406 </ul>
2407 <hr>
2408 <h3>
2412 <br>
2413 <hr>
2414 <h3>
2417 <p>Local interfaces are first defined in the CORBA Component Model specification.
2418 For more information on using the local interfaces, please refers to Section
2422 local objects.
2423 <br>
2426 <hr>
2427 <h3>
2429 Point of contact: <a href="mailto:gthaker@atl.lmco.com">Gautam H. Thaker</a>, Lockheed Martin Advanced Technology Labs, Cherry Hill, NJ.
2434 that SCIOP protocol properties are not yet supported. Extensive
2435 information about SCTP and how it may be used from both ACE and TAO is
2436 available in several README files in $ACE_ROOT/performance-tests/SCTP/
2437 directory. ACE+TAO's SCTP support can be used either with Linux's
2438 OpenSS7 SCTP implementation or with Linux's LKSCTP SCTP
2439 implementation. <p> A paper describing the ACE+TAO SCTP
2440 implementation and measured results are available <a
2441 href=http://www.atl.external.lmco.com/projects/QoS/documents/DOA2003_97_Thaker.pdf>
2444 <hr>
2445 <h3>
2450 <p>TAO has support for IPv6 for IIOP under Windows and Linux.
2452 file and regenerate all makefiles. When using the automated tests, add IPV6
2453 to the configs.
2454 <p>
2455 Finished work:
2456 <li>Added IPv6 support to all IIOP related classes (parsers, connectors,
2457 acceptors)</li>
2459 <li>Implemented IPv6 support in the TAO_IOR_MCast utility class from TAO Svc
2460 Utils</li>
2461 <p>
2463 The following gotchas are known:
2464 <li>In a localhost situation connecting a server listening at the IPv6 ANY address
2465 has the following problems:
2466 On Linux this does not work when the client tries to connect to a
2467 LinkLocal address of one the local NICs,
2468 on Windows this only works (locally) by using the 'localhost' address (either
2469 IPv4 or IPv6)
2470 </li>
2471 <li>Usage of the '-ORBObjRefStyle url' switch poses problems in localhost situations
2472 on Windows since this switch causes 'object_to_string' to only return the first server
2473 endpoint from the IOR profile as a corbaloc URL. In IPv6 servers this will (almost) allways be an IPv4 interface address of one
2474 of the local NICs. This will than cause problems when the server is listening at
2475 the IPv6 ANY address as described above.
2476 </li>
2478 <p>
2479 Future work:
2480 <li>IPv6 support for other protocols/strategies than IIOP (i.e. SHMIOP, UIOP,
2481 SCIOP, SSLIOP etc.; for this we excluded some regression tests in IPv6 builds for this
2482 reason)</li>
2484 <li>IPv4 runtime dependencies in various CORBA services (f.i. Event service)
2485 </li>
2488 <P>
2492 <hr>
2493 <h3>
2495 Here is a summary of TAO's conformance issues with CORBA latest CORBA specifications
2498 <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>
2499 <br>and search for the change bars, meanwhile this can help:
2500 <ul>
2501 <li>
2502 The full OBV (valueboxes, valuetypes in all sorts of things, value graphs,
2503 Anys and value types, abstract interfaces, etc. etc.)</li>
2505 <li>
2506 The IfR database cannot be populated (so it is less than fully operational
2507 ;-))</li>
2509 <li>
2510 Fixed data types (who cares)</li>
2512 <li>
2515 <li>
2516 The old ServantManager interfaces (POA stuff)</li>
2518 <li>
2519 Domain Managers (useful for security, but otherwise nobody seems to care)</li>
2521 <li>
2522 I think our interpretation of codesets is compliant (we only support one
2523 codeset), but would have to check.</li>
2524 </ul>
2525 Future Work (aka. known problems):
2526 <ul>
2527 <li>
2528 Supposedly, any constructed types that contains local types become local
2529 automatically. TAO_IDL currently doesn't handle the array type very well
2530 if one is defined outside the scope of a local interface.</li>
2532 <li>
2533 Need to test local object support more systematically and comprehensively.
2534 (Does TAO throw a MARSHAL exception when trying to marshal a local type?)</li>
2535 </ul>
2537 <hr>
2538 <p>Back to the TAO <a href="../index.html">documentation index</a>.<!--#include virtual="/~schmidt/cgi-sig.html" -->
2539 </body>
2540 </html>