Release Information for The ACE ORB (TAO)

This document contains information on the following topics related to the current release of TAO:
ACE Related
Misc Entries
ORB Related
CORBA Services Related
A complete list of all modifications to TAO is available in the ChangeLog.

ACE Wrappers

Current status: (As of July 07, 2003.)

IDL Compiler

Point of contact: Jeff Parsons

Current status: (As of November 13, 2006.)

Known Issues:

Future work:

Pluggable Protocols

Point of contact: Ossama Othman

The goal of the pluggable protocol effort is to (1) identify logical communication layers in the ORB, (2) abstract out common features, (3) define general interfaces, and (4) provide necessary mechanisms for implementing different concrete ORB and transport protocols. TAO's pluggable protocol framework will allow disparate communication mechanisms to be supported transparently, each with its own set of requirements and strategies.

For example, if the ORB is communicating over a system bus, such as PCI or VME, and not all the features of GIOP/IIOP are necessary and a simpler, optimized ORB and transport protocol can be defined and implemented. Similarly, it should be straightforward to add support for new transport protocols that use native ATM or shared memory as the underlying communication mechanism. In all cases the ORB's interface to the application will remain compliant with the OMG CORBA standard.

There will be several stages of the development process: (1) basic pluggable transport protocols framework, (2) support for multiple profiles, (4) add example transport protocols, such as ATM and VME, and refine/optimize the transport protocols framework, and (4) add support for pluggable ORB protocols, e.g., replacements for GIOP. Each of these steps is outlined below:

Current Status: Known Issues: Critical Work: Future Work:

Portable Object Adapter (POA)

Point of contact: Irfan Pyarali

The POA associates servants with the ORB and demultiplexes incoming requests to servants.

Current Status:

Known issues:
Future work:
Recently completed work:

CORBA Naming Service and Interoperable Naming Service

Points of contact: Marina Spivak and Vishal Kachroo

OMG defined CORBA Naming Service (spec here) to provide a basic service location mechanism for CORBA systems. CosNaming manages a hierarchy of name-to-object-reference mappings. Anything, but typically the server process hosting an object, may bind an object reference with a name in the Naming Service by providing the name and object reference. Interested parties (typically clients) can then use the Naming Service to resolve a name to an object reference.

More recently, CORBA Naming Service was subsumed/extended by the CORBA Interoperable Naming Service, a.k.a. INS (spec here). INS inherits all the functionality from the original Naming Service specification in addition to addressing some its shortcomings. In particular, INS defines a standard way for clients and servers to locate the Naming Service itself. It also allows the ORB to be administratively configured for bootstrapping to services not set up with the orb at install time. This page provides a brief description of additional features INS provides, and how they are implemented in TAO.

Current status (as of 18 May 2001):

Recent work: Features: Future work:

CORBA Trading Service

Point of contact: Seth Widoff

The Trading Service is an implementation of the COS Trading Service speficiation that meets the Linked Trader conformance criteria --- it implements the Lookup, Register, Admin, and Link interfaces, but not the Proxy interface. Notably, the TAO trader supports the following features:

Trading Service documentation is also available.

Future Work:

CORBA Property Service

Point of contact: Alexander Babu Arulanthu

Current status (as of Mar 9th, 1999): All the interfaces of this service have been implemented. Please go through the test examples at $TAO/orbsvcs/tests/CosPropertyService. Property Service is has been used by the TAO's Audio Video Streaming Servicedeveloped for TAO. For general documentation of the Property Service, please read The Property Service Specification.

Recent Work:

CORBA Concurrency Service

Point of contact: Torben Worm

Current status (as of May 3rd): The Concurrency Service provides a mechanism that allows clients to acquire and release various types of locks in a distributed system.

Future Work:

CORBA Audio/Video Streaming Service

Point of contact: Yamuna Krishnamurthy

This is an implementation of the OMG spec addressing the Control and Management of Audio/Video Streams. For more documentation on TAO's A/V Service please have a look here.

Current Status:

(as of July 30 2002) Work in progress:

CORBA Time Service

Point of contact: Vishal Kachroo

The Time Service allows clients to connect to Time Service Clerks and obtain globally synchronized time. This time is calculated from the time obtained from one or more Time Servers running on multiple machines in the network. The service uses the TAO Implementation Repository to activate the time servers on demand.

Current status (as of 10th Jan 1999):

Future work:

CORBA Event Service

Last updated: Fri Mar 5 20:38:26 CST 1999

Point of contact: Pradeep Gore

The COS compliant Event Service implements the Event Service Specification: (.pdf), (.ps)
The different command line and service configurator options used for configuring the CORBA event services are located here. This implementation is based on the Real Time Event service.

Features in this release:

Known bugs:

CORBA Telecom Log Service

Last updated: Sun May 28 15:42:44 PDT 2006

Point of contact: J.T. Conklin

The CORBA Telecom Log Service was updated in TAO 1.5.

Features supported in the current version:

Future work and enhancements:

Notification Service

Last updated:Thu Nov 21 18:41:11 2002

Point of contact: Pradeep Gore

TAO's CORBA Notification Service implementation consists of the following (see the associated README's for more information):

Note that this implementation does not support Pull interfaces and Typed Event style communication.

Real-Time Notification Service

Last updated:Thu Jul 24 11:57:53 2003

Point of contact: Pradeep Gore

This is an extension to TAO's CORBA Notification Service with Real-Time CORBA support.

IDL Extensions:

Tests and Examples: The performance tests for RT Notification measure the throughput, latency and jitter for various test configurations using Periodic Suppliers: Test Framework:
The $TAO_ROOT/orbsvcs/tests/Notify/lib contains a scripting based test framework which can be used to quickly create test cases. The framemork and its options are described here. 

CORBA Security Service

Point of contact: Ossama Othman

Additional information is available here.

Security Service Overview

TAO's current Security Service support implements the core functionality of the CORBA Security Service v1.8.

In particular, it implements the most of the CORBA SecurityLevel1 API, in addition to some of SecurityLevel2. Of the transport protocols described in the above specification, only SSLIOP is supported. Documentation for TAO's SSLIOP pluggable transport is available here.

The 1.8 specification defines the Common Secure Interoperability version 1 (CSIv1) protocol that is currently implemented in TAO.

There are basically two ways to use security in TAO:

  1. Use TAO's SSLIOP pluggable transport in TAO alone. This allows one to secure application requests without modifying the application code. This is the easiest approach but is also the least flexible.
  2. Use the Security Service API implemented by TAO in conjunction with TAO's SSLIOP pluggable transport. This provides the benefits of secured application requests with the flexibility of disabling security in some requests, if so desired. This approach also allows one to choose at run-time which X.509 certificates will be associated with application requests, as opposed to setting configuring only one SSL certificate at application start-up-time. These things are basically configured using the SecurityLevel2 or SecurityLevel3 defined policies:

Implemented Features

IIOP over SSL integration via TAO's SSLIOP pluggable transport.

Current Status


TAO's Scheduling Service

Point of contact: Chris Gill and David Levine

Currently Implemented Features:

Future work:

TAO's support for FT services

Point of contact: Balachandran Natarajan

Current Status:

TAO supports the ORB level requirements to achieve Fault Tolerance for CORBA Objects. The details of the ORB level support is described in the FT chapter of the CORBA 3.0 specification. Specifically TAO implements the sections 23.2.2, 23.2.3, 23.2.6 thru 23.2.8 of the document.

Basic support for FT CORBA services has been added.

Future Work:

Load Balancer

Point of contact: Ossama Othman

Current Status:

TAO's Load Balancer currently implements the latest revision of the OMG Load Balancing and Monitoring proposed specification.

It provides many features and advantages over the previous prototype. Those features and advantages include:

The current proposed Load Balancing and Monitoring specification defines three built-in load balancing strategies. They are:
  1. RoundRobin (non-adaptive)
  2. Random (non-adaptive)
  3. LeastLoaded (adaptive)
TAO implements all of these and the following load balancing strategies:
  1. LoadAverage (adaptive)
  2. LoadMinimum (adaptive)

Known Issues:

Recent Work:

Future Work:

Multicast InterORB Protocol (MIOP)

Point of contact: Frank Hunleth

Current Status:

The final MIOP specification has recently been adopted by the OMG. TAO's MIOP support (located in $TAO_ROOT/orbsvcs/orbsvcs/PortableGroup) enables servants to receive requests sent to multicast addresses. This is performed by creating a GroupId that identifies the multicast group and associating it with one or more servants. Additionally, the Unreliable IP Multicast (UIPMC) pluggable protocol is used to send and receive multicast requests. Multicast endpoints can be created dynamically at runtime.

Known Issues:

Recent Work:

Future Work:

Test & Performance Tests

[Note: This section is not uptodate. Use with caution. February 2004.]
Point of contact: Nagarajan Surendran

Current Status:

The TAO IDL_Cubit test application makes use of the Naming Service and the server holds a TAO_Naming_Server component.Just running server and client is enough to test the application.

The various tests in the tests/POA test the different features of the Portable Object Adapter interface like Explicit Activation, On Demand Activation,etc..


Current status:

The TAO MT_Cubit test application is meant to serve as a starting point for real-time tests on the TAO system. It comprises the following parts:

Clearly, if the ORB endsystem handles the priorities of the various requests correctly, increasing the volume of lower priority requests should not affect the performance seen by the higher priority requests. The application thus serves as a tool to measure and confirm this behavior.

Future work:


Current status:

The TAO Pluggable test utilizes ACE Timeprobes to time the latency at various points in the ORB, especially that incurred by the Pluggable Protocols implementation. Comparisons can be made not only between different layers of the ORB, but also between different protocols as they become available.

Future work:

ORB-related ACE Changes

Points of contact: Nanbor Wang and Irfan Pyrarli

Recently Completed Work:

Future work:
None currently scheduled.

The DOVE Demo

Points of contact: Michael Kircher and Chris Gill.

DOVE is documented in detail online. This discussion focuses on the following goals:

The DOVE Browser uses independent visualization components (Java Beans) and the Event Channel as DOVE Agent. Connections can be established between monitored metrics and the visualization components.

We have three major components: Observables (monitored metrics), Observers (a Java Bean for displaying the metric) and a DataHandler (for demultiplexing the monitored metrics to the appropriate Observables). Each component inherits from a base class, so that a certain behavior of the components can be assured for each component. Relationships between components are based on these base classes.

The used Java Beans are required to conform to some standards, as they have to support a function called "getProperty" which allows the DOVE Browser to determine if the vizualization capabilities of a specific Java Bean are sufficient to display the metric. A JavaBean is for example a Java Panel which shows a Graph of the delivered doubles. So all metrics can be displayed by this visualization component which can be expressed by a single double.

The DataHandler is connected to the Event Push Consumer (PUSH, because we use the push concept of the Event Service). The Event Push Consumer does not know what kind of data is transported. The only component knowing all the details about the dependencies of the metrics is the DataHandler. This separation allows easy extension and change of the demo.

Object Diagrams are available about this new concept.

Event Service events are used as communication between DOVE Applications and the DOVE Browser. The DOVE MIB analyses the event data field of all events and stores this information into a file. The event data filed is of type CORBA::Any and the DOVE MIB has no notion of what is conveyed in this field. So the DOVE MIB has to discover the content via the embedded type code information. Future work includes:

For more information on the DOVE demo, please refer to: $TAO_ROOT/orbsvcs/tests/Simulator/README.

Location Forwarding

Point of contact: Irfan Pyarali, Michael Kircher.

For more information see Location forwarding

Global Resources and Leader-Follower Model

Point of contact: Irfan Pyarali, Michael Kircher.

For more information see Leader-follower model

Implementation of locate request

Point of contact: Irfan Pyarali, Michael Kircher.

For more information see Locate request

Asynchronous Method Invocation

Points of contact: Alexander Arulanthu , Michael Kircher and Carlos O'Ryan


Finished work: Future Work:

Custom Servant Dispatching

Points of contact: Tim Bradley

Current Status:

Known Issues:

Portable Interceptors

Point of contact: Ossama Othman.

For more information see Portable Interceptors

Local Interfaces

Point of contact: Nanbor Wang.

Local interfaces are first defined in the CORBA Component Model specification. For more information on using the local interfaces, please refers to Section 11.1.1 to 11.1.4 of the spec and our short guideline on implementing local objects.

SCIOP Support in TAO

Point of contact: Gautam H. Thaker, Lockheed Martin Advanced Technology Labs, Cherry Hill, NJ.

TAO has support for OMG's GIOP SCTP Protocol mapping spec, except that SCIOP protocol properties are not yet supported. Extensive information about SCTP and how it may be used from both ACE and TAO is available in several README files in $ACE_ROOT/performance-tests/SCTP/ directory. ACE+TAO's SCTP support can be used either with Linux's OpenSS7 SCTP implementation or with Linux's LKSCTP SCTP implementation.

A paper describing the ACE+TAO SCTP implementation and measured results are available online.

IPv6 Support in TAO

Point of contact: Martin Corino, Remedy IT.

TAO has support for IPv6 for IIOP under Windows and Linux. To use this, add ipv6 to your default.features file and regenerate all makefiles. When using the automated tests, add IPV6 to the configs.

Finished work:

  • Added IPv6 support to all IIOP related classes (parsers, connectors, acceptors)
  • Added IPv6 support to corbaloc and mcast URL parsers.
  • Implemented IPv6 support in the TAO_IOR_MCast utility class from TAO Svc Utils
  • The following gotchas are known:

  • In a localhost situation connecting a server listening at the IPv6 ANY address has the following problems: On Linux this does not work when the client tries to connect to a LinkLocal address of one the local NICs, on Windows this only works (locally) by using the 'localhost' address (either IPv4 or IPv6)
  • Usage of the '-ORBObjRefStyle url' switch poses problems in localhost situations on Windows since this switch causes 'object_to_string' to only return the first server endpoint from the IOR profile as a corbaloc URL. In IPv6 servers this will (almost) allways be an IPv4 interface address of one of the local NICs. This will than cause problems when the server is listening at the IPv6 ANY address as described above.
  • Future work:

  • IPv6 support for other protocols/strategies than IIOP (i.e. SHMIOP, UIOP, SCIOP, SSLIOP etc.; for this we excluded some regression tests in IPv6 builds for this reason)
  • IPv4 runtime dependencies in various CORBA services (f.i. Event service)

  • CORBA Standards Conformance

    Here is a summary of TAO's conformance issues with CORBA latest CORBA specifications (updated 9 August 2000):
    2.3.1 and 2.3 differ in very little, if at all, check:
    and search for the change bars, meanwhile this can help: Future Work (aka. known problems):

    Back to the TAO documentation index.

    Last modified: Thu May 4 13:08:35 UTC 2006