A Field Guide to Boxology

The paper on boxology was to me the most interesting paper/chapter of the first two weeks of this course. The paper attempts to establish a taxonomy and framework for describing different architectural styles and to place different well known styles in a two dimensional topology. The paper appears to be from before architecture styles started to be documented as patterns (i.e. from before the POSA book) and treats styles in a somewhat more formal manner than patterns do. However, since the paper is about creating a framework for classifying different architectures it is equally applicable as a classifications of architectural patterns. In addition the papers treatment of architectural styles is observational as opposed to a priori or analytical and as such it is very similar to the pattern approach.

After the introduction the main part of the paper has one section describing their framework for classification followed by two example architectural (dataflow networks/pipes and filters and message passing processors) that are elaborated to demonstrate and attempt to validate the classification.

To me the section on their classification strategy was by far the most interesting. They defined components and connectors as primary classification criteria in addition to the secondary criteria control, data organization and the interaction between these. One of the things I like about this section is the treatment of connectors as an aspect that are as important as components since there are many more ways to do this than simple static function calls (observers, function pointers, virtual functions, message passing, etc.). I also found their examples of different characteristics that can be associated with connectors such as format conversion (Adapters...) and even additional functionality such as logging and performance monitoring to be interesting.

The architectural styles that I am most familiar with from the their classification in the appendix ("Table 1") are layered architectures, dataflow networks (mostly through pipelines), different call-and-return styles and to some degree message passing processors. The architectures I am the least familiar with are the data-centered repository architectures and I don't actually know how a blackboard works so I guess I have some reading to do.

I have encountered pipelines mainly through my work on graphics drivers. A graphic driver, along with the GPU it drives, is primarily a pipeline for producing images. In this particular instance of a pipeline the user will provide stream data in the form of vertices and attributes as well as auxiliary data such as textures and matrices. In addition to this the user can typically configure the operation of different pipeline stages (lighting, texture stages) and/or, in more modern systems, even provide whole stages to be executed on the stream data in the form of shader programs. Such a system can consist of many stages such as draw-call setup, vertex processing, fragment processing and each stage can typically operate concurrently on different sets of data as one would expect from a pipeline. Some stages are performed on a CPU while other stages are more typically offloaded to specialized hardware such as a GPU.

An example of directed acyclic data network would be the gstreamer architecture for media processing. This pipe-and-filter architecture allows the user to define different filters to process or transform data as well as sources of data and sinks (for example a file or a surface to be blitted to a computer screen). These components can then be stitched together into a DAG that can be used to process a flow of data (video/audio/images). This provides for an incredible powerful architecture (although at the time I was trying to use it several years ago gstreamer was quite immature and caused me to loose some of my hair) where a relatively small set of filters can be composed into many different interesting components of a larger application.

One architecture that is interesting to try to place in the authors table is model-view-controller. This architecture (often, but certainly not exclusively, found as a "sub-architecture" inside the server of a client/server architecture) can in some sense be seen as variation of main program/subroutines specialization of call-and-return. Flow of control, for the most part, moves hierarchically from the presentation layer downwards, but that also has a feedback loop that is dynamically bound at runtime in the form of an observer that synchronizes different parts of the presentation layer with the current model state. However, a typical MVC can also be seen as a data-centered repository style architecture as the model will usually represent a set of data to be manipulated and presented.