Release Information for The ACE ORB (TAO)

This document contains information on the following topics related to the current release of TAO:

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 19, 2003.)

Known Issues:

Future work:

ORB & ORB Core

Point of contact: Balchandran Natarajan

Last Update: $Date: 2006/08/21 16:13:08 $

Current status:

Known issues:

Ongoing Work:

Future work:

Completed 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:

Objects-by-Value

Points of contact: Jeff Parsons Boris Kolpackov George Edwards

Last Update: 2004/08/24

Objects-by-Value (OBV) describes the new type, valuetype, introduced in CORBA 2.3
(Core: formal/02-12-06.pdf; Mapping to C++: formal/03-06-03.pdf).

The original TAO implementation was contributed by Torsten Kuepper, and has subsequently been enhanced and corrected by Jeff Parsons and George Edwards.

Valuetypes are similar to IDL structs extended with these features:

Valuetypes have the following uses:

Current status:

Known issues:

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. 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 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 protocol 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:

Implemented Features:

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

Current Status:

Schedule:

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.

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 specification.

It provides many features and advantages over the previous non-standards based prototype. Those features and advantages include:

The current 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:

CORBA Event Service

Point of contact: Pradeep Gore

The COS compliant Event Service implements the Event Service Specification. This implementation is based on the Real Time Event service.

Features in this release:

Known bugs:

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

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.

MT_Cubit 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:

Pluggable 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:

The DOVE Demo

Points of contact: Michael Kircher and Chris Gill.

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

Status:

We've implemented the callback model of the CORBA Messaging specification. To activate the AMI for TAO and the TAO IDL compiler define TAO_HAS_CORBA_MESSAGING, TAO_HAS_AMI_CALLBACK in your config.h file. The TAO IDL compiler can generate the AMI "callback" stubs, ReplyHandler und reply stubs using the -GC switch.

For an example see $TAO_ROOT/tests/AMI and $TAO_ROOT/examples/AMI.

Finished work:

Future Work:

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.

Future Work (aka. known problems):