Thursday, 14 June 2007

Intercepting Filter Design Pattern

Intercepting Filter is classified as an enterprise or J2EE design pattern. Intercepting Filter design pattern is typically used in cases where some messages should be processed but the target processing should be wrapped into chain of arbitrary pre/post processings as are authorization checks, message resources transformations (eg. translation, escaping), ...

Intercepting Filter design pattern is built from five basic components:

  1. FilterManager
  2. FilterChain
  3. IFilter interface
  4. Context
  5. ITarget interface

FilterManager - FilterManager class is a boundary class of Intercepting Filter design pattern. It means that a client uses it as an interface to process some target operation (represented by ITarget interface) in a specific context (represented by abstract interface Context). FilterManager is then typically responsible for FilterChain creation, it's setup (concrete filter set configuration, target propagation, ...) and finally it's execution.

FilterChain - FilterChain class is basicaly data object carrying list of filters and the target, with just very simple logic of filter queue.

IFilter - IFilter interface has just one method. The method is typically implemented as captured on following diagram. It makes some pre processing, and if everything is OK than it calls FilterChain to process to following filter.

If something is wrong (some data are wrong or missing in Context) then it can return or throw exception.

When the target is reached through chain of filters, it is processed, and the thread is returning back same way, so it can make some post processing in every filter, during which it can also make some changes to Context (eg. response translation, escaping, ...).

ITarget - ITarget interface should be implemented as message receiver or it's wrapper.

Context - Context class in this presentation of Intercepting Filter design pattern should be considered as very abstract. It means that it can be totally different type of class or it can be set of classes or it can be some Map, etc. For example it can be ServletRequest together with ServletResponse when we are talking about Intercepting Filter design pattern implementation defined by Sun - Core J2EE Patterns - Intercepting Filter.

Implementation of Intercepting Filter design pattern is pretty simple. The most complex component can be FilterManager which can implement some sophisticated way of configuration which defines mapping filters to context and their configuration. But whenever it is implemented it is very simple to extend message processing by new features or change its behavior.

Related patterns:
  • Decorator [GoF]
    • Does not have FilterChain - the order of filters is defined wrapping one filter into another.
  • Template Method [GoF]
    • Very simple version of Intercepting Filter design pattern implementing Filter Chain (template method) and IFilter implementations (methods called from template method) in one class.
  • Chain of Responsibility [GoF]
    • Does not have FilterChain - the order of "interceptors" is defined as chain of successors.
  • Interceptor [POSA2]
    • Similar also to Chain of Responsibility but the chain of successors is not "hard coded" but propagated to "interceptor" as parameter of the method call.
  • Pipes and Filters [POSA1]
    • The Pipes and Filters design pattern is oriented basically for stream related use cases. It also doesn't provide implicit possibility of post processing.
References: