Software Architecture Styles: Pipe-Filter, OO, Event-Driven, Layers, Repositories & Interpreters

Based on Software Architecture: Perspectives on an Emerging Discipline , this article explains what an architectural style is by answering seven key questions: the design vocabulary (component and connector types), allowable structural patterns, underlying computational model, essential invariants, common examples, advantages and disadvantages, and common specializations.

1. Pipe-and-Filter

Components: Filters — responsible for local transformation and incremental computation on input data streams.

Connectors: Pipes — conduits that transport data streams, passing output of one filter to input of another.

Structural constraints: Typically form an arbitrary directed graph (topological constraints may forbid cycles in some scenarios).

Computational model: Incremental stream processing — output can begin as soon as partial input arrives, without waiting for all input.

Design invariants: Filters must be completely independent entities with no shared state; a filter cannot know the identity of its upstream or downstream filters (only relies on data specifications); overall system result does not depend on the specific scheduling order of incremental filter executions.

Real-world examples: Unix shell pipelines (e.g., cat file | grep ... | sort), traditional compilers (lexical, syntactic, semantic analysis, code generation as pipelined stages), signal processing systems.

Advantages: Easy to understand overall I/O behavior as simple composition of filter behaviors; excellent reusability (filters satisfying data conventions can be arbitrarily assembled); easy maintenance and extension; naturally supports concurrent execution.

Disadvantages: Encourages batch-processing mindset; unsuitable for highly interactive applications requiring incremental display updates; may incur extra parsing/unparsing overhead due to generic data formats (e.g., plain text streams).

Specializations:

Pipelines: Restrict topology to a linear sequence.

Bounded pipes: Limit the maximum amount of data that can be buffered in a pipe.

Typed pipes: Require end-to-end transmitted data to have explicitly defined types.

2. Object-Oriented Organization

Components: Objects (instances of abstract data types) acting as "Managers" that protect the integrity of their internal resources (data representation).

Connectors: Function and procedure invocations.

Structural constraints: Network or hierarchical structures formed by explicit invocation relationships among objects.

Computational model: State encapsulation with interactive invocation — internal representation is hidden and manipulated via controlled external methods.

Design invariants: Each object is solely responsible for maintaining the integrity of its internal data representation (by preserving some invariant). The internal representation is completely hidden from other objects (information hiding).

Real-world examples: Modules in object-oriented programming systems, classic design pattern applications.

Advantages: Allows modification of internal data representation without affecting other modules; supports design reuse and module independence.

Disadvantages: When new interactions or cross-object functional enhancements are introduced, because invocation relationships are hard-wired into modules, many existing modules may need modification.

Specializations: Common specializations include architectures based on design patterns (e.g., specific object organization in MVC), Actor model, etc.

3. Event Systems (Event-Driven)

Components: Independent modules/objects capable of publishing events; interfaces provide both a collection of procedures (as with abstract data types) and a set of events.

Connectors: Event broadcast / implicit binding connectors (event broadcast / event manager) that associate events with methods of interested components.

Structural constraints: Loosely coupled topology based on event publish-subscribe.

Computational model: Event-driven — components do not directly call specific procedures but broadcast events; the system automatically invokes all registered methods for that event implicitly.

Design invariants: The event publisher does not know which components (or which methods) will respond to it (publisher and subscribers are decoupled).

Real-world examples: GUI frameworks, database triggers (Active Databases), garbage collection mechanisms.

Advantages: Excellent system evolution and functional extension capability (new components only need to register for events to integrate, without modifying existing code).

Disadvantages: Difficult to provide good support for changes in data representation (similar to shared data); components relinquish control over computation order, making it hard to reason about final system behavior and execution overhead (may introduce extra runtime costs).

Specializations: MVC dependency update mechanisms, Active Databases.

4. Hierarchical Layers

Components: Layers — each layer acts as a client to the layer below and a server to the layer above.

Connectors: Protocols defining inter-layer visibility and invocation rules (e.g., services provided by lower layer to upper layer).

Structural constraints: Layered topology (strict or loose layering); each layer depends only on its immediate lower layer (or lower layers).

Computational model: Top-down or bottom-up stepwise service invocation and abstraction refinement.

Design invariants: Visibility constraints — a layer can only see and use facilities provided by its directly adjacent lower layer (or specific lower layers), hiding implementation details.

Real-world examples: OSI 7-layer network reference model, operating system kernels, layered abstractions in compiler architectures.

Advantages: Supports incremental enhancement based on stepwise decomposition (supports design evolution across multiple abstraction levels); supports high standardization and interoperability (e.g., protocol stacks); local modifications confined to a single layer.

Disadvantages: Not all systems naturally possess clear hierarchical structures; layering may cause performance overhead (requests must traverse multiple layers); difficult to define tightly coupled behavior spanning multiple layers.

Specializations: Strictly layered systems, virtual machine hierarchies.

5. Repositories (Data-Centered Systems)

Components: Central data store/repository (persistent long-term state) and independent computational components that access/update the central repository (e.g., clients, knowledge sources).

Connectors: Database access protocols, SQL queries, transaction protocols, shared variable mechanisms.

Structural constraints: Star topology — multiple independent computational components read/write around a central data repository.

Computational model: Interaction model centered on persistent shared data state.

Design invariants: Integrity and persistence of the central data structure are maintained by the repository component or specific transaction/concurrency control mechanisms.

Real-world examples: Traditional relational database systems, integrated software development environments (e.g., CASE tool collaborative environments), Blackboards (used in AI and complex signal processing).

Advantages: Highly centralized and integrated data, facilitating management and persistent storage; easy to add new computational tools (as long as they follow the database interface).

Disadvantages: Central repository often becomes a performance bottleneck and single point of failure; independent computational components are tightly coupled to the repository schema and its evolution, making global data structure changes extremely costly.

Specializations: Commercial database systems, Blackboard architectures (knowledge sources collaborate via central blackboard to solve complex problems), Hypertext systems.

6. Interpreters

Components: Interpretation engine, virtual machine component containing state (current execution state, variables, code, etc.).

Connectors: Simulated control flow, data state access, and method dispatch.

Structural constraints: Cyclic structure composed of the interpreter core and the program state data it manipulates.

Computational model: Software simulation of hardware or specific language execution semantics, dynamically interpreting and executing "pseudo-code" or scripts.

Design invariants: Execution behavior is controlled by pure software logic, decoupling program representation (code/data) from actual execution.

Real-world examples: Programming language interpreters, virtual machines (e.g., Java JVM), rule engines, script hosting environments.

Advantages: High portability and flexibility; supports dynamic code loading and execution; facilitates implementation of domain-specific languages (DSLs) and debugging.

Disadvantages: Compared to native compiled execution, computational performance and execution efficiency are usually lower.

Specializations: Rule-based systems, command interpreters, script runtime environments.

Heterogeneous Architectures

Real-world complex systems rarely adopt a single pure style; instead they combine, nest, or mix multiple architectural styles. Such systems are called heterogeneous architectures. Three common combination patterns:

Hierarchy / Nested Styles: For example, in a macro Pipe-and-Filter system, a specific Filter may be implemented entirely by an independent object-oriented subsystem or sub-pipeline network.

Mixture of Connectors: A single component interacts with the outside world through multiple different connector types simultaneously (e.g., a component receives data via pipes, accesses objects via procedure calls, and receives notifications via event triggers).

Elaboration of Levels: At a high level one macro architecture is used, while descending to refine a specific level the style switches completely to another.