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 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.

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

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".