- Motivation
- Problem: Programming Yourself into a Corner with OS APIs
- An Appealing Solution: Host Infrastructure Middleware
- Improving Application Portability with ACE
- The Importance of Open-Source
- Concluding Remarks
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Improving Application Portability with ACE
ACE contains approximately 250,000 lines of C++ code, 500 classes, and 10 frameworks1. To provide its powerful capabilities across a diverse range of platforms, ACE is designed using the layered architecture shown in Figure 1.
){kind=link}
Figure 1 The layered architecture of ACE.
This design allows networked application developers a wide variety of usage options to match their needs. It also makes reuse much simpler within ACE itself. The layers in ACE that enable these capabilities are described in the following list.
OS adaptation layer. This layer does most of the work to unify the diverse set of supported platforms and standards under a common API. In most cases, the OS adaptation layer presents an efficient, POSIX-like interface using C++ inlined static methods. It's possible to write many networked applications portably using only ACE's OS adaptation layer. Other examples of OS adaptation layers include the Apache Portable Runtime and the Netscape Portable Runtime, which are open-source C libraries that form a system portability layer for many operating systems.
Since an OS adaptation layer presents a flat C-like function API, however, programming to it directly incurs the usual drawbacks of algorithmic design. Moreover, this layer's purpose is to unify the means for implementing well-defined behavior, such as opening a file, writing data to a socket, or spawning a thread. Behaviors that aren't common across platforms, such as forking a process (not available on Windows, for example) are not implemented at this layer. For these reasons, many networked applications use ACE's wrapper facade layer, which is described next.
Wrapper facade layer. This layer in ACE provides an object-oriented form of systems programming for networked applications. Its classes reify the Wrapper Facade pattern2, in which one or more classes enforce proper usage by encapsulating functions and data within a type-safe OO interface, rather than a flat C function API. For example, there are separate wrapper facade classes in ACE that listen passively for TCP connections, actively establish a TCP connection, and send/receive data over the resulting connected TCP streams. This layer also contains portable capabilities, such as process management, that don't share portable implementation details across OS platforms.
The ACE wrapper facade layer resolves many of the portability issues described earlier. The vast majority of portable functionality is available with the same classes across all supported platforms. Since ACE is responsible for resolving OS differences, your application code remains clean and neat across platforms. Since ACE offers its functionality via intelligently and efficiently designed class interfaces, your code won't suffer from either hard-to-find semantic differences across platforms or type-safety problems that can plague you at run time. The result is that your code is developed faster, and the porting effort is much shorter than it otherwise would be.
As we've seen, ACE's OS adaptation and wrapper facade layers offer enormous benefit over trying to code directly to native OS APIs. However, ACE offers many more benefits than just object-oriented portability. Many of these benefits are derived from the ACE framework layer described next.
Framework layer. A framework is a set of classes that collaborate to provide a reusable architecture for a family of related applications3. The framework layer is the highest level of abstraction in the ACE toolkit. This layer codifies the interaction of the ACE wrapper facades to offer capabilities such as event demultiplexing and dispatching, asynchronous I/O handling, and event logging. Although ACE framework implementations sometimes use platform-specific details to enhance their performance, ACE framework interfaces expose their capabilities as portably as possible via their systematic use of patterns2.
ACE's frameworks also offer a set of "semi-complete" applications, such as the Acceptor-Connector framework, which simplifies the active and passive establishment of network service sessions, and the Reactor framework, which detects and demultiplexes events from multiple sources and dispatches the events to application-defined event handlers that process the events. Developing complete applications via these frameworks just requires adding business-specific logic in well-defined locations, known as hook methods, rather than re-creating core areas of needed functionality. Framework-based development makes it easy to prototype and enhance designs rapidly because the architecture of many applications is embodied in ACE's frameworks.
In addition to developing networked applications, ACE's frameworks have been used to develop even higher levels of standards-based middleware, such as the JAWS adaptive web server 2 and The ACE ORB (TAO)4.
Together, the ACE middleware layers described above simplify the creation, composition, configuration, and porting of networked applications without incurring significant performance overhead. ACE's layered architecture also allows code to transition from simpler designs and prototypes to more complex designs and complete applications. This benefit is particularly important in large projects in which requirements evolve and changes occur in a product, and where developers gain more experience with the ACE toolkit over time.