Release Information for The ACE ORB (TAO)

Information is available on the following topics related to the current release of TAO: A complete list of all modifications to TAO is available in the ChangeLog.


IDL Compiler

Point of contact: Jeff Parsons

Current status: (As of August 2, 1999.)


Known bugs/unimplemented constructs:

Future work:

Pluggable Protocols

Point of contact: Fred Kuhns

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 proccess: (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:

Real-Time CORBA

Point of contact: Fred Kuhns

The Real-Time CORBA specification (RT-CORBA) defines a framework for supporting end-to-end deterministic behavior for a fixed priority CORBA system. This specification builds on the CORBA Architecture Specification version 2.2 and the CORBA Messaging Specification. Primarily, RT-CORBA adds to the Policy framework defined in the Messaging specification and adds to GIOP/IIOP version 1.1 to support these extensions.

This effort will implement the RT-CORBA specification and required parts of the Messaging specification. Our implementation of RT-CORBA in TAO will occur in stages. Our initial focus will be the support of statically configured, real-time embedded systems where it is possible to eliminate many sources of unbounded priority inversion. This will be followed by a more general implementation which supports more dynamic environments and scheduling mechanisms.

Support for statically configured applications requires a framework which allows for explicit mappings between CORBA priorities, connections (client side), endpoints (server side), threads, objects and invocations. By supporting such mappings, applications will realize a greater degree of control over end-to-end priority mappings. Essentially, applications are able to assign priorities to connections between server and client, then using the existing Policy framework along with new Policy objects, requests are routed to the appropriate connections. By assigning equivalent thread and object priorities, applications are able to ensure end-to-end priority preservation.

As a part of this initial effort we are also adding support for both reliable and buffered oneway operations. Reliable oneway operations are specified in the messaging specification. Reliable oneways is a method for providing different levels of support for reliable message delivery. Traditional oneway semantics are unacceptable in many environments. For example, there is no guarantee that a particular invocation will actually be delivered. Additionally, location forwarding will not occur with traditional oneway invocations.

The Messaging specification has defined four alternative interpretations of the oneway interface. Two of these cases do provide for both location forwarding and positive acknowledgment from the server that a message was received. The SyncScopePolicy Policy from the Messaging Specification is used to specify the level of reliability required. The policy is set on the client side and uses a new flags field in the GIOP 1.2 header. The server checks this flag to determine if a reply is required for the oneway invocation. Four different levels synchronization are defined in the RT specification:

The underlying transport object will be enhanced to support different oneway buffering strategies. This feature can be used to optimize message throughput, possibly at the expense of latency. The One-Way Buffer will be flushed under 5 conditions as specified by the Buffering Constraint Policy:

Current Status:

Known issues: Critial 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:


Interface Repository

Point of contact: Jeff Parsons

The Interface Repository provides run-time information about IDL interfaces. Using this information, it is possible for a program to encounter an object whose interface was not known when the program was compiled, yet, be able to determine what operations are valid on the object and make invocations on it using the DII.

Current Status: TDB

Known Issues: TDB

Recent Work: TDB

Future Work: TDB




CORBA Naming Service and Interoperable Naming Service

Points of contact: Marina Spivak and Vishal Kachroo

The CORBA Naming Service supports a hierarchical mapping between sequences of strings and object references. The CORBA Interoperable Naming Service defines a standard way for clients and servers to locate the Naming Service. It allows the ORB to be administratively configured for bootstrapping to services not set up with the orb at install time.

Current status (as of 7th Apr 1999):

Recently completed work: Work in progress: 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: Nagarajan Surendran and 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 Sep 1st 1999)

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)
This implementation is based on the Real Time Event service.

Features in this release:

Known bugs:


CORBA Telecom Log Service

Last updated: Sun Oct 17 14:35:11 CDT 1999

Point of contact: Pradeep Gore

The CORBA Telecom Log Service prototype was released in TAO version 1.0.6.

Features supported in the first version:

Things to be done:

Future work and enhancements:


TAO's Scheduling Service

Point of contact: Chris Gill and David Levine

Currently Implemented Features:

Future work:

TAO's Logging Service

Point of contact: Matt Braun

Current status (as of August 4'th):

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

Status:

Finished work:

Future Work:


Portable Interceptors

Point of contact: Nanbor Wang, Kirthika Parameswaran.

For more information see Portable Interceptors


Back to the TAO documentation index.