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:

• Core J2EE Patterns - Intercepting Filter
• MSDN - Intercepting Filter

Interceptor Design Pattern

Usage of Interceptor Design Pattern [POSA2] can solve many problems in daily development. It is very easy to:

• monitor what is the application doing inside
• provide possibility to change some of application's behavior
• provide possibility to extend application with new features
• implementer of the extension need not to know rest of the application
• implementer of the extension need not change existing code
• new extensions can or can not affect current system

Interceptor design pattern is built from three basic components:

1. IInterceptor interface
2. Dispatcher
3. Context

IInterceptor - IInterceptor interface can define arbitrary number of operations which are executed by Dispatcher in specific cases (at the beginning of the request processing or at the end of the request processing). There is typically just one parameter for every method - Context - carrying input and output data. The interface is then implemented by specific interceptors (logging, authorization, transaction, ...).

Dispatcher - Dispatcher class typically implements IInterceptor interface. There are many ways how the dispatching can be implemented. For example the interceptors called by Dispatcher can be prioritized or exception thrown from interceptor can be handled as interception termination. The Dispatcher is the class which is called from "intercepting point" to perform intercepting.

Context - Context is typically simple data object used to carry data for interceptors or to keep results of intercepting (eg. transaction id generated by TransactionInterceptor). There can be different Context implementations not only for different IInterceptor interfaces but also for different methods of IInterceptor interface.

As mentioned in description of basic elements the Interceptor pattern has many degree of freedom:

1. IInterceptor
• one/many methods
• one/many Context types for many methods
• result propagation to Dispatcher, intercepting point or following interceptors
  
• Context - Dispatcher can decide about next step by status of the Context
  
• Exception - Dispatcher can handle different exceptions different way
  
2. Dispatcher
• implements/does not implement IInterceptor interface
• dispatching mechanism (prioritized, random, based on context, ...)

Implementation of Interceptor Pattern is not the easiest work. But whenever it is implemented it is very simple to extend application by new features or change its behavior.

Related patterns:

• Template Method [GoF]
• Very simple version of Interceptor Pattern implementing Dispatcher (template method) and IInterceptor implementations (methods called from template method) in one class.
  
• Chain of Responsibility [GoF]
• Does not have Dispatcher - the order of "interceptors" is defined as chain of successors.
  
• Intercepting Filter
• 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.
  

References:

• Intreceptor Design Pattern presentation
• ONJava - Web and Enterprise Architecture Design Patterns for J2EE, Part 2