The ACE ORB (TAO), pronounced "dau", is a CORBA V2.5 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 further down this page. 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.

http://www.theaceorb.com/images/ataofig.gif

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

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.

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.

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.
  
  

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.
  
  

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

• 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.
• Log Service -- Implements parts of the Telecom Log Service with event based logging and query capabilities.
• Notification Service -- Extends the OMG Event Service adding structured events, filtering, offers and subscriptions, discovery, QoS, and an optional event type repository.
• Audio/Video Streaming Service -- Standard interfaces that control and manage audio and video stream exchanges with Quality of Service (QoS) constraints.
• Standard CORBA Event Service -- Defines an event data delivery model that allows decoupled communication between suppliers and consumers of events.
• Lifecycle Service -- Provides a standard means to locate, move, copy, and remove objects.
• 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.
• Property Service -- Allows applications to associate properties with objects dynamically.
• Time Service -- Provides globally synchronized time among a system of distributed objects.
• Trading Service -- Implements a mapping between attribute constraints and sequences of object references that match those constraints.
• 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.
  
  

Other CORBA features that TAO supports include:

• CORBA Messaging -- Asynchronous Method Invocation (callback model), QoS Framework and messaging QoS.
• 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).
• 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.
• 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.
• 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.
• 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.
  
  

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

• 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.
• Load Balancing -- Implements round robin and minimum dispersion load balancing algorithms to forward requests to registered replica services.

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), and SSLIOP (IIOP over SSL) are built in.

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.

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.

The ORB is only one (but an important one) element in a series of elements which together link distributed object systems. In order for the combined behavior to be predictable and of acceptable performance all elements must be carefully designed and configured consistently. QoS is an end to end issue. Some examples of the issues facing the system designer are:

• Client marshaling
• Client protocol queuing
• Network delay.
• Server protocol queuing
• Thread dispatching
• Server dispatching
• Server demarshaling
• Method execution
  
  

Therefore overall QoS cannot be resolved strictly within the domain of the ORB. However TAO can contribute two elements to the equation of end of end determinism and performance. The first is a design that is sensitive to real time requirements and ensures that features are implemented at every level of the ORB architecture, mindful of what is optimal. Such requirements can be:

• Meeting deadlines
• Low latency
• Bounding jitter (which is latency variation)
• Avoiding priority inversions
• Low overhead (efficiency)
  
  

The second is to recognize there is no universal singular way of implementing the ORB to satisfy all needs and therefore provide choices that the designer can match to the specifics of the problem. Hard real time systems have needs different from, for instance, stream oriented systems such as Video on Demand, or Voice over IP. In all cases they have quality of service requirements, but they are fulfilled by different approaches. (Such as dynamically spawning new threads on each invocation.) TAO's configurability allows the software designer to select those options that are consistent with strategies the architect is employing in the application, with those of the network protocols and the (real time) operating systems. Such options must be able to collaborate harmoniously with the variety of options offered by the other elements in the system. This is achieved by using patterns which allow the behavior of TAO to be tailored for specific platforms and application requirements without requiring access to, or modification of, ORB source code. Patterns, which collaborate in this manner, avoid the drawbacks that arise when one applies them in isolation.

Strategies incorporated within TAO are adaptive and flexible. TAO enables the benefits of abstraction by the use of CORBA without compromising the designer's need for control of all elements in the chain. TAO can be used in variety of situations where quality of service is a requirement.

In classic hard real-time systems the timing constraints are an integral part of the application. If these constraints are not met then the application is not correct. Speed or performance is not necessarily the issue. Predictability is. Speed and performance can contribute to meeting demanding timing constraints. However from a design standpoint the concern is that in the worst case situation the timing boundaries are not exceeded. Guaranteed behavior is required, best effort is not sufficient. Average performance is not meaningful, bounded limits are.

In static (or closed) applications the designer endeavors to eliminate anything which is superfluous and might contribute to variability. Machine tool cells or aircraft control systems are examples of static, predefined systems. Dynamic systems are more complex because they are subject to change. Here the real-time issues are most likely addressed by ensuring activities are prioritized. Telecom networks and other shared resources are examples where the loading is subject to environmental conditions. The designer has to ensure appropriate allocation of resources according to need and that any degradation in service, due to load or abnormal events, is implemented in accordance with a policy.

Real-time systems designers sometimes classify their systems in terms of hard, firm or soft needs. In a hard real-time system the activity has disastrous consequences if its constraints are violated. Transportation control, guidance and switching systems are classic examples. Firm real-time systems however have no value to the activity if the timing requirements are missed. Examples of such are stock trading systems that cannot keep up with market volatility. Soft real-time systems are those where missed constraints (of an occasional kind) decrease the value of the activity but do not totally invalidate it. Systems that report information by sampling from a source may occasionally miss a value. In that case the overall trend is still obtained, even though there is now a lower degree of confidence in a reading at a moment in time.

Systems can often contain a mix. The control loop of a critical process may have hard real time requirements, but the observation or monitoring application, which displays information to an operator, may be soft. In this case the operator is not expected to participate except as an observer.

Developers are increasingly finding themselves designing distributed applications, which compete for resources in shared environments. All applications are not created equal. Some must have priorities. An ORB that cannot distinguish amongst clients seeking services cannot guarantee quality of service. User satisfaction is best achieved when expectations can be set and met with some predictability. TAO's real-time design enables the designer to manage the variability in the chain of elements. Best effort ORBs are unable to support the designer in that goal.

The terms real-time and embedded are often used interchangeably. Systems can be both but they do not have to be. They are independent of each other. Embedded describes a computer that is a component of a much larger system. This computer has a narrowly defined purpose(s). This fixed environment enables the designer to focus the resources to the task, creating a static or bounded system. Exhaustive testing of such defined systems is possible and this results in a high degree of confidence in its behavior. Small footprint is not necessarily a requirement for an embedded system, but by bounding the system one can be more efficient and eliminate superfluous elements.

TAO's open source model and configurable design enables the developer to understand exactly the intent of the software, and to select only those elements that are required to solve the problem at hand. TAO can be configured and compiled to exactly match the need of an embedded systems designer.

For many years, builders of large-scale distributed object systems have relied on CORBA for implementing their infrastructure needs, in a time and cost effective manner. Middleware was the optimum place to share functionality, rather than duplicating it in every application. These systems were implemented at a time when the resources available to them, such as memory, processing power and expanded bandwidth became very cost effective. In this environment CORBA gained acceptance, more features were added, platform support extended and performance optimizations incorporated. TAO’s position in the market bears testimony to its leveraging of the growth in these resources to take CORBA beyond the best effort limitations of first generation CORBA products.

The features of TAO have made it very appealing to a wide variety of users. Now that its users are convinced of the benefits of CORBA in general, and of TAO in particular, they are seeking to extend its use. There are a new group of target hardware and software systems for object technologies, beyond the traditional desk-top and server systems. These new applications and their platforms are aimed at network control equipment, telephony devices, hand-held products, sensors, airborne systems, orbiting vehicles, industrial controllers and the like. This new class of computing machinery does not have the luxury of supporting such large shared objects. They have limitations on heat dissipation, unit costs, power consumption, battery size and weight, all of which make a small memory footprint a desirable characteristic. Configuring TAO for small memory usage by makes it attractive in a wider range of circumstances because it reduces initial cost, power consumption, heat emitted, physical size etc.

Footprint implications are a prime consideration in TAO’s continued development.

To see the latest progress in TAO’s footprint check with the web site http://doc.ece.uci.edu/Stats/. All builds include an analysis of footprint size to encourage parsimonious coding practices, and to provide users with an open and transparent way of tracking status. Improvements today to the betas will manifest themselves in the next release product.

OCI has already contributed to TAO’s memory footprint reduction activities through sponsors. We are actively seeking additional sponsors to continue this activity.

One way to meet the need of this market is by making TAO more configurable, so that it can be tailored specifically for the embedded systems designer. This allows the OEM to derive the middleware from a standards compliant open source code base, and yet know the code is configured specific to the need at hand. Such tailoring is still cost effective compared with developing code from scratch. As TAO continues to add and evolve functionality, the OEM will still have a source of contemporary technology from which to refresh the product line.

The embedded and wireless systems market is presently undergoing dramatic change to meet the opportunities offered. New battery and other power source technologies, the latest software for power management, and new low power hardware, all of which are sensitive to the needs of the growing embedded market are constantly altering the mix of options available to the designers. A severe limitation today, maybe gone tomorrow. Middleware’s role is to absorb change and mask the developers from underlying systems’ turbulence, at both the hardware and O/S level. This benefit should not be denied lightly. TAO’s layer of abstraction provides a level of protection to the savvy designer.

When reviewing TAO, or in fact any ORB, for footprint size with regards to your application please consider the following:

1. A zero footprint means zero functionality. CORBA performs a service, which you must replace with your code, if CORBA is not there to do it for you.
2. Even if you save memory with your own code replacing that of the ORB, remember you are now assuming a maintenance burden for the future, which might have been avoided.
3. A short cut in your code today may eventually result in more (and complex) code as you extend across additional platforms in the future. TAO efficiently manages platform extensions by means of its ACE layer.
4. If you have a choice of compilers on the platform bear in mind that compiler selection can affect memory size dramatically. Ensure you are aware of the compiler characteristics and its biases towards sharing code or performance optimizations (in-lining) for example.
5. What is your target chip? What is its instruction set? CISC chips have up to half the footprint size of the RISC architectures.
6. Do not confuse a rich (and large) development environment of source code, examples, test cases, and large memory and disk requirements for builds etc with footprint size. The two are separate and distinct issues. TAO’s open source environment is comprehensive and can be overwhelming initially.
7. Do not be misled by the size of the TAO library file. It is not the amount of memory consumed for code and data.
8. What ORB services are you including? The OMG Minimum CORBA Spec. is a good reference point for what constitutes a minimum level of functionality and inter-operability. What really matters is what you need. Ensure you building only what you need.
9. Are you looking at size for a debugging version of TAO? This will not be representative of run time size.
10. Do you need logging? This also provides valuable service while consuming more space.
11. Are you using the Unix command "size" for estimating memory usage, in a consistent manner, during your evaluation? Measurement techniques must be consistent between environments and products. The TAO team uses the "size" command.
12. Are you able to set up TAO for "client only", or "server only" builds? If so you can eliminate extraneous code, such as POA code in the client application.
13. In some instances you may choose to employ ACE only, and still derive the benefits from an abstraction and platform portability standpoint. ACE is approximately one third the size of the ACE/TAO combination.
14. TAO is open source. If you are confident that your environment is static and bounded, that you know exactly what you need, that the benefits of CORBA are meaningful to you, then you may take advantage of TAO being open source and tailor TAO specifically to meet your needs. Through testing you can identify those files that are not being exercised, and remove potentially 20 to 30% of TAO’s code base. OCI can help you implement such a strategy.
15. Remember the IDL you generate also takes up memory space. It can be influenced heavily by the number of objects in your code. Before compiling IDL be sure to check this FAQ to ensure the settings are correct to compile as small as possible.
16. Look at the OCI tool "SOreduce" (an abbreviation for Shared Object reduction) found in $ACE_ROOT/apps/soreduce/. This tool is described below and enables further footprint reduction as the design concludes.
    
    

The motivation for this tool was the understanding that the ACE & TAO libraries were to be linked with the VxWorks kernel to allow multiple applications to be run simultaneously with a minimum of footprint consumed. Ordinarily a choice is made between static linking applications, where each application gets only the object modules needed, and shared object linkage, where multiple applications share access to full libraries. Frequently a shared library will contain code and data which is not used by any of the applications in a particular configuration. The Shared Library Reduction Tool builds libraries that include only the modules needed to support a specified set of applications.

The analysis is performed very late in the application implementation, allowing the system implementers the freedom to use whatever TAO & ACE components are needed. Once an application is built and running, its shared object need may be evaluated. The evaluation is straight forward. Run the soreduce program, passing the path to all of the applications that will share the libraries. The soreduce program uses the following steps to generate its results.

1. A list of undefined symbols and shared libraries is built by invoking the ldd and nm commands on each application. For now, soreduce assumes the GNU variant of these tools.
2. For each shared library, soreduce tries to invoke nm on each of the intermediate object files used to build the library. It is important that target library directory has a current .shobj subdirectory.
3. The list of undefined symbols is traversed. For each entry in the list, the modules loaded from step 2 are examined to look for a matching symbol. When one is found, the target symbol, and any others satisfied by the module are removed from the list, and any undefined symbols in the module are added to the list. This process is repeated until the entire list of undefined symbols is traversed without change.
4. Makefiles are generated. Rather than invoking the linker directly, a make file is generated that may be used to build the libs. With these makefiles, the actual library will be named lib(orig)_subset.so.
   
   

For more information go to the $ACE_ROOT/apps/soreduce/README file.

In evaluating middleware, with regards to memory footprint, one must exercise care and good judgment.

Although the actual numbers are constantly changing (see the above URL) you may require a rule of thumb as to memory sizing. The LibACE size for Linux on X86 is about 700 kilobytes. On Vxworks for the PowerPC the size is around 850 kilobytes. LibTAO is just over a megabyte for the Linux/X86 combination and just under 1.4 megabytes for the VxWorks/PowerPC combination. Both are required for TAO. These numbers should help you obtain a general feel for the size of TAO on CISC and RISC environments.

Contact OCI if you are concerned about footprint and want to fairly evaluate TAO and ACE for your small footprint project.