| The Pipes and Filters architectural pattern is a common way of organizing layered/modular applications [SG96]. This pattern defines an architecture for processing a stream of data in which each processing step is encapsulated in some type of filter component. Data is passed between adjacent filters via a communication mechanism, which can range from IPC channels connecting local or remote processes to simple pointers that reference objects within the same process. Each filter can add, modify, or remove data before passing it along to the next filter. Filters are often stateless, in which case data passing through the filter are transformed and passed along to the next filter without being stored. Common examples of the Pipes and Filters pattern include -
The UNIX pipe IPC mechanism [Ste92] used by UNIX shells to create unidirectional pipelines -
System V STREAMS [Rit84], which provides a framework for integrating bidirectional protocols into the UNIX kernel The ACE Streams framework is based on the Pipes and Filters pattern. This framework simplifies the development of layered/modular applications that can communicate via bidirectional processing modules. This chapter describes the following classes in the ACE Streams framework: | ACE Class | Description | | ACE_Task | A cohesive unit of application-defined functionality that uses messages to communicate requests , responses, data, and control information and can queue and process messages sequentially or concurrently. | | ACE_Module | A distinct bidirectional processing layer in an application that contains two ACE_Task objects ”one for "reading" and one for "writing" | | ACE_Stream | Contains an ordered list of interconnected ACE_Module objects that can be used to configure and execute layered application-defined services | The most important relationships between classes in the ACE Streams framework are shown in Figure 9.1. These classes play the following roles in accordance with the Pipes and Filters pattern [POSA1]: Figure 9.1. The ACE Streams Framework Classes  -
Filter classes are the processing units in a stream that enrich, refine, or transform input data. The filter classes in the ACE Streams framework are implemented by subclasses of ACE_Task . -
Pipe classes denote the interconnections between the filters. The pipe classes in the ACE Streams framework are provided by ACE_Module objects that contain interconnected ACE_Task objects linked together to create a complete bidirectional ACE_Stream . Application-defined methods in adjacent interconnected tasks collaborate by exchanging data and control message blocks. The ACE Streams framework provides the following benefits: -
Enhanced reuse and flexibility. Any ACE_Task can be plugged into any ACE_Module and any ACE_Module can be plugged into any ACE_Stream . This flexibility enables multiple applications to systematically reuse existing modules and tasks, all of which can be configured dynamically. -
Transparent, incremental evolution. Application functionality can be implemented in a controlled manner by adding, removing, and changing modules and tasks. This ability to evolve an application's design and functionality is particularly useful in agile development processes, such as Extreme Programming (XP) [Bec00]. -
Macro-level performance tuning. Applications can adapt to varying deployment scenarios and run-time environments by selectively omitting unnecessary service functionality or reconfiguring a mixture of ACE_Task and ACE_Module objects to provide contextually optimal service functionality. -
Inherent modularity. The structure enforced by the ACE Streams framework promotes well-accepted design practices of strong cohesion and minimal coupling. Modular designs help to reduce the complexity of each layer and improve the overall implementation of networked applications and services. Testing and documentation are also more easily accomplished when based on a highly modular design, making application maintenance and systematic reuse easier, as well. -
Easy to learn. The ACE Streams framework contains an intuitive class structure based on the patterns and design of the System V STREAMS framework, as discussed in Sidebar 59. However, even developers who haven't been exposed to System V STREAMS can quickly grasp the structure of the Pipes and Filters pattern and then use that pattern as a basis for learning the rest of the ACE Streams framework classes. The ACE_Task class was described in Chapter 6. This chapter therefore focuses largely on describing the capabilities provided by the ACE_Module and ACE_Stream classes. However, we illustrate how all the classes in the ACE Streams framework can be used to develop a utility program that formats and prints log records stored by our logging servers. If you aren't familiar with the Pipes and Filters pattern from POSA1, we recommend that you read about it first before delving into the detailed examples in this chapter. Sidebar 59: ACE Streams Relationship to System V STREAMS The class names and design of the ACE Streams framework correspond to similar componentry in System V STREAMS [Rit84, Rag93]. The techniques used to support extensibility and concurrency in these two frameworks differ significantly, however. For example, application-defined functionality is added in System V STREAMS via tables of pointers to C functions, whereas in the ACE Streams framework it's added by subclassing from ACE_Task , which provides greater type safety and extensibility. The ACE Streams framework also uses the ACE Task framework to enhance the coroutine-based concurrency mechanisms used in System V STREAMS . These ACE enhancements enable more effective use of multiple CPUs on shared memory multiprocessing platforms [SS95b] by reducing the likelihood of deadlock and simplifying flow control between ACE_Task active objects in an ACE_Stream . | |
