The ACE ORB (TAO) is a freely available, open-source, and standards-compliant real-time C++ implementation of CORBA based upon the Adaptive Communication Environment (ACE). It attempts to provide efficient, predictable, and scalable quality of service (QoS) end-to-end. TAO applies the best software practices and patterns to automate the delivery of high-performance and real-time QoS to distributed applications. TAO is for developers of distributed and embedded applications who have stringent performance demands.
Domain of application
Certain real-time applications have benefited from TAO's use of familiar software concepts to present a solution to challenging real-time software problems. In general, real-time systems require predictable timing characteristics and robustness since they are used in mission-critical domains. Other real-time applications require low development cost and fast time to market. TAO addresses both of these by providing an already-implemented general-purpose communications framework that uses concepts familiar to non-real-time portions of the software industry.
Traditionally, the barrier to viable real-time CORBA has been that many real-time challenges are associated with end-to-end system design aspects that transcend the layering boundaries traditionally associated with CORBA. That's why TAO integrates the network interfaces, OS I/O subsystem, ORB, and middleware services in order to provide an end-to-end solution. For instance, consider the CORBA Event Service, which simplifies application software by supporting decoupled suppliers and consumers, asynchronous event delivery, and distributed group communication. TAO enhances the standard CORBA Event Service to provide important features, such as real-time event dispatching and scheduling, periodic event processing, efficient event filtering and correlation mechanisms, and multicast protocols required by real-time applications.
Familiar concepts presented
TAO brings familiar concepts from elsewhere in the software industry to real-time systems. These concepts include CORBA, RPC, an OO presentation, and Berkeley-sockets. In OO, RPC is usually termed “remote method invocation” (RMI), because subroutines or procedures that are directly associated with objects or classes are termed methods, but the concept is fundamentally the same in that the caller at the origin is suspended while the method at the destination object executes. This provides a simplicity of execution of software that can be desirable when subroutine is the idiom that is intended in the design or architecture.
Suspension of execution
TAO, like all CORBA implementations, presents an OO RMI interface to the application. Invoking a subroutine suspends the execution of the superior who is delegating the operation and transfers the sole right to execute to the invoked method at the destination object, the subordinate to which the operation was delegated. Perhaps the caller could go on and perform other activities during that delegated operation, but the caller is suspended, awaiting the final accomplished result from the subordinate.
This becomes especially troublesome when the superior and subordinate are on different processors. Because the superior is suspended and only the subordinate is actively executing, two threads on two processors are occupied in the accomplishment of a single delegated operation. Typically, the counter-measure to this when using RMI/RPC is to increase the number of threads in the superior to match the desired total number of concurrent operations throughout the set of all subordinates. The resources consumed by a thread are typically greater than the resources consumed by communicating each delegated operation to the subordinate. Thus the overhead of concurrency is multiplied when using an RPC/RMI approach when compared to the approach of allowing the superior to continue executing to perform other tasks.
The alternative used by competitors to CORBA is simply to forgo the subroutine model so that the superior continues to execute concurrently with the delegated operations. The superior simply prepares a message that is sent to the subordinate. The subordinate immediately acknowledges the receipt of the message that requests the accomplishment of the delegated operation (without yet starting to accomplish the delegated operation itself). The superior then goes about other business, such as preparing messages for other delegated operations either to that same subordinate or to other subordinates. Each subordinate that has been delegated an operation, enqueues the operation's requesting message in a message queue that corresponds to the message's priority or deadline. A thread (perhaps in a thread pool) dequeues that message from that queue to accomplish the delegated operation. Upon accomplishment, the result is sent as a different message to the superior. The superior processes the result messages similarly to the way the subordinate processed the delegation messages.
TAO provides this alternative through the asynchronous method invocation (AMI) and Asynchronous Method Handling (AMH) mechanisms. AMI is used by clients to make remote invocations without blocking for a response, the reply is received as a callback. AMH is used by servers to delay sending responses, for example, if the server itself needs to wait for other remote calls. AMI is part of the CORBA standard. AMH is a TAO extension to the CORBA specification.
TAO can be downloaded from the Internet and freely used and redistributed without developer or run-time licensing costs. Commercial support, documentation, training, and consulting for TAO are available from multiple vendors. Many other third-party tools and services have also been integrated with TAO. Remedy IT provides an extension for TAO called TAOX11 which adds support for the IDL to C++11 Language Mapping to TAO.
- Adaptive Communication Environment (ACE)
- Component-Integrated ACE ORB (CIAO)
- WikiBooks:ACE+TAO Opensource Programming Notes
- "Remedy IT announces new v1.3.2 release of TAOX11". Remedy. Retrieved 2015-02-04.