J2EE Design Patterns - Intercepting Filter

Different type of processing is required for the different type of request, received by the presentation tier request handler. Some requests are simply forwarded to the appropriate handler component, while other requests must be processed before actual request processing.
We require Preprocessing and post-processing of a client Web request and response.

When a request enters a Web application, it often must pass several checks, prior to the main processing stage -
- Authentication, Authorization
- data-encoding scheme.
- logging information about each request
- transformation of output for a specific client
- Uncompressing and converting encoding scheme of input.
- Does the client have a valid session?
- Does the request path violate any constraints?
- What encoding does the client use to send the data?
- Do we support the browser type of the client?

Some of these checks are tests, resulting in a yes or no answer that determines whether processing will continue or not.

With fulfillment of above requirement, we also need below demands be inline -
- Common processing, such as checking the data-encoding scheme or logging information about each request, completes per request.
- Centralization of common logic is desired.
- Services should be easy to add or remove unobtrusively without affecting existing components,
so that they can be used in a variety of combinations, such as Logging and authentication, Debugging and transformation of output for a specific client, Uncompressing and converting encoding scheme of input
- For an efficient system, these requests and responses must be pre-processed and post-processed in a proper way.
In addition to that this, processing must be independent from the rest of the system.

Solution -

Create pluggable filters to process common services in a standard manner without requiring changes to core request processing code.
The filters intercept incoming requests and outgoing responses, allowing preprocessing and post-processing.

Features -
- We are able to decorate our main processing, with a variety of common services, such as security, logging, debugging etc.
- These filters are components, that are independent of the main application code and they may be added or removed declaratively.
For example, a deployment configuration file may be modified to set up a chain of filters. The same configuration file might include a mapping of specific URLs to this filter chain. When a client requests a resource that matches this configured URL mapping, the filters in the chain are each processed in order before the requested target resource is invoked.
- Intercepting filters provide Declarative and Flexible Configuration with the help of web.xml file, where we can have Filter defination and filters are used in servlets, where we want them to act as filters.
- Numerous services are combined in varying permutations without a single recompile of the core code base.
- Intercepting filters improves reusability, Filters promote cleaner application partitioning and encourages reuse.
- The Intercepting Filter separates request/response processing from the rest of the system by creating filters.
- It provides authentication, authorization, transformation and conversion of requests and responses as needed.

Below Components are involved in this pattern -

FilterManager :
The FilterManager manages filter processing. It creates the FilterChain with the appropriate filters, in the correct order, and initiates processing.

FilterChain :
The FilterChain is an ordered collection of independent filters.

Filters :
These are the individual filters that are mapped to a target. The FilterChain coordinates their processing.

Target :
The Target is the resource requested by the client.