Overview of TAO

The 2.2a version of the ACE ORB (TAO), pronounced "dow", is a CORBA V3.0 compliant, C++, object request broker. It is a second generation ORB developed with a highly extensible architecture as a result of its use of what might be termed a pattern framework, more commonly known as the ACE library. (ACE is an acronym for ADAPTIVE Communication Environment, ADAPTIVE is another acronym and stands for A Dynamically Assembled Protocol, Transformation And Validation Environment!). A more detailed discussion of this design approach can be found here. Although designed to meet the demanding requirements of hard real time systems, TAO can be easily used "out of the box" for general purpose CORBA middleware applications. Its design to meet exacting real time needs, which can be described as Quality of Service (QoS) requirements, has resulted in superior predictability, complete end to end determinism, high performance, and a scaleable implementation.

TAO supports IIOP 1.2 enabling a high degree of interoperability with other conforming ORBs. By means of TAO's support for pluggable protocols new transport technologies can be introduced without disruption to higher level code and systems. Networking technology migrations are made easier.

Client:  This program entity performs application tasks by obtaining object references to servants and invoking operations on the servants. Servants can be local or remote, relative to the client. The client is unaware of how the CORBA object is implemented. The operations that the client can invoke are those defined in the object's interface as expressed in the OMG Interface Definition Language (IDL).

Servant:  This component implements the operations defined by an OMG Interface Definition Language interface. For OO programming languages, servants are implemented as one or more objects. For non-OO languages, such as C, servants are implemented via wrappers or other special groupings of functions and structures. The wrappers are effectively adapters to server applications and they encapsulate the calls to library routines or some other code that is being reused.

IDL Stubs and Skeletons:  TAO's IDL stubs and skeletons efficiently marshal and demarshal operation parameters respectively. Stubs provide a strongly typed, static invocation interface (SII) that marshal application data into a common packet level representation. Conversely, skeletons demarshal the packet level data back into typed data that is meaningful to an application. Skeletons provide a static skeleton Interface (SSI). TAO's IDL compiler can provide specialized stubs that optimize operation invocations when the target object is collocated with (i.e., in the same address space as) the client.

In addition to the SII and SSI models described above, TAO also supports the Dynamic Invocation Interface (DII) and the Dynamic Skeleton Interface (DSI) as defined by the CORBA specification.

Portable Object Adapter:  The POA specification of CORBA 2.2 replaces the incomplete and under-specified BOA. An Object Adapter associates servants with the ORB and demultiplexes incoming requests to servants. TAO's Portable Object Adapter (POA), by default, uses perfect hashing and active demultiplexing optimizations to dispatch servant operations on constant 0(1) time, regardless of the number of active connections, servants, and operations defined in IDL interfaces. Alternative look-up strategies are configurable, such as linear search, binary search, and dynamic hashing. TAO fully implements the POA specification and thus supports multiple nested POAs per ORB, (along with recursive deletes.) This enables improved scaleability. Additionally V2.2 conforming ORBs can now support various types of servants that possess similar characteristics. This architecture results in a small and simple ORB that can still support a wide range of object granularities, lifetimes, policies, implementation styles and other properties. Portability is achieved by standardizing the skeletons classes produced by the IDL compiler, as well as the interactions between the servants and the Object Adapter.

The characteristics of each POA (other than the root POA) can be customized at POA creation time using different policies. The TAO real time POA supports the following policies:

  • Threading:- either single threaded, or ORB controlled.
  • Lifespan :- specifying whether objects are transient or persistent.
  • ObjectId Uniqueness:- whether unique or multiple identities are implemented.
  • Servant Retention:- either associations between servants and CORBA objects are retained, or new associations are established for each incoming request.
  • Request Processing:- specifies as to how requests should be processed by the POA. (Combining retention with request processing results in a high degree of flexibility.)
  • Implicit activation:- using this a C++ server can register the servant and create an object reference in a single operation.

NOTE: for predictable real time performance it is necessary to avoid calling external unpredictable events. Therefore when using TAO the following POA features may be disabled:-

    Servant Managers: - If this feature is not used then all servants should register, directly with the POA, ahead of time.

    Adapter Activators: - If this feature is not used, all POAs are created at the beginning of execution.

    POA Managers: - This feature can be disabled because extra levels of queuing can lead to priority inversion and excessive locking.

CORBAservices Support -- TAO implements many of the OMG CORBAservices specifications, as follows:

  1. Concurrency Control Service -- Mediates concurrent access to an object such that the consistency of the object is not compromised when accessed by concurrently executing computations.
  2. Logging Service -- Provides applications with distributed logging and log record querying capabilities. Four separate logging services are provided in TAO, differentiated by their log message distribution mechanism: Basic Logging Service, Event Logging Service, Notify Logging Service, and RTEvent Logging Service.
  3. Notification Service -- Extends the OMG Event Service adding structured events, filtering, offers and subscriptions, discovery, QoS, and an optional event type repository.
  4. Audio/Video Streaming Service -- Standard interfaces that control and manage audio and video stream exchanges with Quality of Service (QoS) constraints.
  5. Event Service -- Defines an event data delivery model that allows decoupled communication between suppliers and consumers of events.
  6. Lifecycle Service -- Provides a standard means to locate, move, copy, and remove objects.
  7. Naming Service -- Provides a way to associate objects with names. The Naming Service is the principal mechanism by which most clients locate objects they intend to use.
  8. Property Service -- Allows applications to associate properties with objects dynamically.
  9. Time Service -- Provides globally synchronized time among a system of distributed objects.
  10. Trading Service -- Implements a mapping between attribute constraints and sequences of object references that match those constraints.
  11. Security Service -- Provides a security reference model, implementation architecture, and interfaces that allow object systems, applications, and administrators to participate in security at any of three levels: security unaware, security policy controlling, and security policy enforcing.
  12. Persistent State Service (PSS) -- Provides a way of making a CORBA service persistent. The fact that PSS is being used by a service is known only to the server and not to clients of the service. PSS presents persistent information as storage objects stored in storage homes. Storage homes are the datastores where the persistent data are saved.
  13. Load Balancing Service -- Based on the revised joint submission to the OMG's proposed "Load Balancing and Monitoring for CORBA-based Applications" RFP (OMG Document mars/02-10-14). TAO's implementation features random, round-robin, and least-loaded load balancing strategies.

Other CORBA features that TAO supports include:

  1. CORBA Messaging -- Asynchronous Method Invocation (callback model), QoS Framework and messaging QoS.
  2. Portable Interceptors -- Portable Interceptors are objects that the ORB invokes at predefined points during the request and reply paths (request interceptors) or during thegeneration of IORs (IOR interceptors).
  3. Interface Repository -- Provides for the storage, distribution and management of a collection of related object's interface definitions and the relationship of their modules, operations and interfaces etc.
  4. Implementation Repository -- Enables indirect binding of client requests with server implementations to fulfill those requests. Optionally provides for automatic start up of servers when a client invocation occurs.
  5. Bi-Directional GIOP -- Enables requests and replies to travel bi-directionally across a single connection between two processes, both of which are sending and receiving requests and replies across that connection. This capability helps address the issue of invoking callbacks on clients located behind firewalls.
  6. Object by Value -- Partially implements the CORBA Objects by Value (OBV) specification, which combines the semantics of structures and interfaces, thereby allowing objects (value types) to be passed by value (i.e., copied) across IDL interfaces as long as the implementation exists locally on the receiving side.
  7. Object Reference Template (ORT) -- TAO implements the Object Reference Template (ORT) specification from CORBA 3.0 Core specification for defining an interface for object reference construction by object adapters.

In addition, TAO also complies with Real-Time CORBA version 1.1 and provides the following services/features which serve to demonstrate TAO's capabilities in various deterministic and statistical real-time environments:

  1. TAO Real-Time Event Service -- Augments the standard CORBA Event Service model by providing source and type-based filtering, event correlations, and real-time dispatching.
  2. Pluggable Protocols -- Enables developers to "plug in" custom transports under GIOP without disturbing application level code. IIOP (GIOP over TCP), UIOP (GIOP over UNIX domain sockets), SHMIOP (GIOP over shared memory), DIOP (a limited implementation of GIOP over UDP), Unreliable Multicast Inter-ORB Protocol (MIOP), and SSLIOP (IIOP over SSL) are built in.

ORB Core:  The ORB Core delivers client requests to the Object Adapter and returns responses (if any) to clients. TAO's real-time ORB Core uses a multi-threaded, preemptive, priority-based connection and concurrency architecture to provide an efficient and predictable CORBA IIOP protocol engine.

ACE: TAO is implemented on top of ACE. This is the lower level middleware that implements the core concurrency and distribution patterns for communication software. ACE provides the reusable C++ wrapper facades and framework components that support the QoS requirements of high-performance, real-time applications. ACE is multi-platform and spans both regular and real-time operating systems. A more detailed description can be found here.