Government // Enterprise Architecture
12:00 AM

Defining SOA, Part IV: Pipes and Filters

This post is part of a series of posts trying to define SOA as an architectural style. In the previous post I talked about SOA and the Layered Architecture Style (which generated a couple of follow-ups -- one on l

This post is part of a series of posts trying to define SOA as an architectural style. In the previous post I talked about SOA and the Layered Architecture Style (which generated a couple of follow-ups -- one on layered architecture in general, one on its importance for SOA , and one on layers in enterprise architecture vs. solution architecture).

The next architectural style SOA builds on is Pipes and Filters. Unlike Layers and Client/server which I described in previous installments, Pipes and Filter is not also a base style for REST. This basically, this style is where SOA and REST begin to diverge.

The pipes and filters architectural style defines two types of components -- yep you've guessed it, Pipes and Filters.

  • Filters are independent processing steps they are constrained to be autonomous of each other and not share state, control thread etc.
  • Pipes are interconnecting channels

Each filter exposes a relatively simple interface where it can receive messages on an inbound pipe, process them, and produce messages on outbound pipes. The idea behind this is to allow easy composability, thus allowing greater usage (also known as "reuse" -- I'll discuss the difference in another post). Systems are composed of several filters working together, filters can be replaced with newer version (provided they keep the same interface) etc.

On the downside, the overall latency is increased since to accomplish a task you have to move from filter to filter.

The pipes and filters style brings to SOA things like the autonomy of services, the sense of explicit boundaries. For instance, this is the basis for why you wouldn't want to do distributed transactions across service boundaries, which I blogged about several times before.

The pipes part of the "pipes and filters" also means that the wiring can be taken care of outside of the services themselves and that you can control them externally. This works well with ithe use of middleware (service bus). Additionally Fielding (you know, the REST guy) also mentions that

One aspect of PF styles that is rarely mentioned is that there is an implied "invisible hand" that arranges the configuration of filters in order to establish the overall application. A network of filters is typically arranged just prior to each activation, allowing the application to specify the configuration of filter components based on the task at hand and the nature of the data streams (configurability). This controller function is considered a separate operational phase of the system, and hence a separate architecture, even though one cannot exist without the other.
Which is the harbinger of the orchestration/choreography aspects of SOA.

So as you see, Pipes and Filters is one of the important pilars of SOA. In the next installment (unless I'll have to clarify things about this post) I'll talk about the last architectural style SOA builds -- "Distributed Agents".

Comment  | 
Email This  | 
Print  | 
More Insights
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Elite 100 Digital Issue, April 2015
The 27th annual ranking of the leading US users of business technology
Back Issues | Must Reads
All Videos
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
Join us for a roundup of the top stories on for the week of April 19, 2015.
Friday, May 8, 3pm EDT

InformationWeek Live for the Week of May 3, 2015
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.
Full schedule | Archived Shows