1.4 A Tour through the ACE Frameworks

Ru-Brd

1.4.1 An Overview of ACE

ACE is a highly portable, widely used, open -source host infrastructure middleware toolkit. The source code is freely available from http://ace.ece.uci.edu/ or http://www.riverace.com/. The core ACE library contains roughly a quarter million lines of C++ code that comprises approximately 500 classes. Many of these classes cooperate to form ACE's major frameworks. The ACE toolkit also includes higher-level components , as well as a large set of examples and an extensive automated regression test suite.

To separate concerns, reduce complexity, and permit functional subsetting, ACE is designed using a layered architecture [POSA1], shown in Figure 1.7. The capabilities provided by ACE span the session, presentation, and application layers in the OSI reference model [Bla91]. The foundation of the ACE toolkit is its combination of an OS adaptation layer and C++ wrapper facades, which together encapsulate core OS network programming mechanisms to run portably on all the OS platforms shown in Sidebar 2 (page 16). The higher layers of ACE build on this foundation to provide reusable frameworks, networked service components, and standards-based middleware.

Figure 1.7. The Layered Architecture of ACE

1.4.2 A Synopsis of the ACE Frameworks

The ACE frameworks are an integrated set of classes that can be instantiated and customized to provide complete networked applications and service components. These frameworks help to transfer decades of accumulated knowledge directly from the ACE developers to ACE users in the form of expertise embodied in well- tested and reusable C++ software artifacts. The ACE frameworks implement a pattern language for programming concurrent object-oriented networked applications. Figure 1.8 illustrates the ACE frameworks. To illustrate how the ACE frameworks rely on and use each other, the lines between boxes represent a dependency in the direction of the arrow. Each framework is outlined below.

Figure 1.8. The Key Frameworks in ACE

Sidebar 2: OS Platforms Supported by ACE

ACE runs on a wide range of operating systems, including:

• PCs, for example, Windows (32- and 64-bit versions), WinCE, and Macintosh OS X

• Most versions of UNIX, for example, SunOS/Solaris, IRIX, HP-UX, Tru64 UNIX (Digital UNIX), AIX, DG/UX, Linux (Redhat, Debian, and SuSE), SCO OpenServer, UnixWare, NetBSD, and FreeBSD

• Real-time operating systems, for example, VxWorks, ChorusOS, LynxOS, Pharlap TNT, QNX Neutrino and RTP, RTEMS, and pSoS

• Large enterprise systems, for example, OpenVMS, MVS OpenEdition, Tandem NonStop-UX, and Cray UNICOS.

ACE can be used with all of the major C++ compilers on these platforms. The ACE Web site at http://ace.ece.uci.edu contains a complete, up-to-date list of platforms, along with instructions for downloading and building ACE.

ACE Reactor and Proactor frameworks. These frameworks implement the Reactor and Proactor patterns [POSA2], respectively. Both are architectural patterns that allow applications to be driven by events that are delivered to the application from one or more event sources, the most important of which are I/O endpoints. The Reactor framework facilitates a reactive I/O model, with events signaling the ability to begin a synchronous I/O operation. The Proactor framework is designed for a proactive I/O model where one or more asynchronous I/O operations are initiated and the completion of each operation triggers an event. Proactive I/O models can achieve the performance benefits of concurrency without incurring many of its liabilities. The Reactor and Proactor frameworks automate the detection, demultiplexing , and dispatching of application-defined handlers in response to many types of events. Chapters 3 and 4 describe the ACE Reactor framework and Chapter 8 describes the ACE Proactor framework.

ACE Service Configurator framework. This framework implements the Component Configurator pattern [POSA2], which is a design pattern that allows an application to link and unlink its component implementations without having to modify, recompile, or relink the application statically. The ACE Service Configurator framework supports the configuration of applications whose services can be assembled late in the design cycle, such as at installation time and/or run time. Applications with high availability requirements, such as mission-critical systems that perform online transaction processing or real-time industrial process automation, often require such flexible configuration capabilities. Chapter 2 describes the design dimensions associated with configuring networked services and Chapter 5 describes the ACE Service Configurator framework.

ACE Task framework. This framework implements various concurrency patterns, such as Active Object and Half-Sync/Half-Async [POSA2]. Active Object is a design pattern that decouples the thread that executes a method from the thread that invoked it. Its purpose is to enhance concurrency and simplify synchronized access to objects that reside in their own threads of control. Half-Sync/Half-Async is an architectural pattern that decouples asynchronous and synchronous processing in concurrent systems, to simplify programming without reducing performance unduly. This pattern incorporates two intercommunicating layers, one for asynchronous and one for synchronous service processing. A queueing layer mediates communication between services in the asynchronous and synchronous layers. Chapter 5 of C++NPv1 describes the design dimensions associated with concurrent networked applications and Chapter 6 of this book describes the ACE Task framework.

ACE Acceptor-Connector framework. This framework leverages the Reactor framework and reifies the Acceptor-Connector pattern [POSA2]. This design pattern decouples the connection and initialization of cooperating peer services in a networked system from the processing they perform once connected and initialized . The Acceptor-Connector framework decouples the active and passive initialization roles from application-defined service processing performed by communicating peer services after initialization is complete. Chapter 7 describes this framework.

ACE Streams framework. This framework implements the Pipes and Filters pattern, which is an architectural pattern that provides a structure for systems that process a stream of data [POSA1]. The ACE Streams framework simplifies the development and composition of hierarchically layered services, such as user -level protocol stacks and network management agents [SS94]. Chapter 9 describes this framework.

When used together, the ACE frameworks outlined above enable the development of networked applications that can be updated and extended without the need to modify, re-compile, relink, or restart running applications. ACE achieves this unprecedented flexibility and extensibility by combining

• OS mechanisms, such as event demultiplexing, IPC, dynamic linking, multithreading, multiprocessing, and synchronization [Ste99]

• C++ language features, such as templates, inheritance, and dynamic binding [Bja00]

• Patterns, such as Component Configurator [POSA2], Strategy [GoF], and Handler/Callback [Ber95]

The ACE frameworks provide inversion of control via callbacks, as shown below:

ACE Framework	Inversion of Control
Reactor and Proactor	Calls back to application-supplied event handlers to perform processing when events occur synchronously and asynchronously.
Service Configurator	Calls back to application-supplied service objects to initialize, suspend, resume, and finalize them.
Task	Calls back to an application-supplied hook method to perform processing in one or more threads of control.
Acceptor-Connector	Calls back to service handlers to initialize them after they're connected.
Streams	Calls back to initialize and finalize tasks when they are pushed and popped from a stream.

The callback methods in ACE's framework classes are defined as C++ virtual methods. This use of dynamic binding allows networked applications to freely implement and extend interface methods without modifying or rebuilding existing framework classes. In contrast, the ACE wrapper facades rarely use callbacks or virtual methods , so they aren't as extensible as the ACE frameworks. The ACE wrapper facades do support a broad range of use cases, however, and can be integrated together via generic programming [Ale01] techniques based on the C++ traits and traits classes idioms outlined in Sidebar 40 (page 165).

Figure 1.9 illustrates how the class libraries and frameworks in ACE are complementary technologies. The ACE toolkit simplifies the implementation of its frameworks via its class libraries of containers, which include lists, queues, hash tables, strings, and other reusable data structures. Likewise, application-defined code invoked by event handlers in the ACE Reactor framework can use the ACE wrapper facades and the C++ standard library classes [Jos99] to perform IPC, synchronization, file management, and string processing operations. Sidebar 3 describes how to build the ACE library so that you can experiment with the examples we present in this book.

Figure 1.9. Applying Class Libraries to Develop and Use ACE Frameworks

Sidebar 3: Building ACE and Programs that Use ACE

ACE is open-source software that you can download from http://ace.ece.uci. edu or http://www.riverace.com and build yourself. These sites contain a wealth of other material on ACE, such as tutorials, technical papers, and an overview of other ACE wrapper facades and frameworks that aren't covered in this book. You can also purchase a prebuilt version of ACE from Riverace at a nominal cost. See http://www.riverace.com for a list of the prebuilt compiler and OS platforms supported by Riverace.

If you want to build ACE yourself, you should download and unpack the ACE distribution into an empty directory. The top-level directory in the distribution is named ACE_wrappers . We refer to this top-level directory as " ACE_ROOT ." You should create an environment variable by that name containing the full path to the top-level ACE directory. The ACE source and header files reside in $ACE_ROOT/ace .

The $ACE_ROOT/ACE-INSTALL.html file has complete instructions for building ACE, including how to configure it for your OS and compiler. This book's networked logging service example source and header files reside in $ACE_ROOT/examples/C++NPv2 and are ready to build on all platforms that ACE supports. To build your own programs, the $ACE_ROOT directory must be added to your compiler's file include path. For command-line compilers, this can be done with the -I or /I compiler option. Graphical IDEs provide similar options, such as MSVC++'s "Preprocessor, Additional include directories" section of the C/C++ tab on the Project Settings dialog box.

Ru-Brd