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 being further processed. We require Preprocessing and post-processing of a client Web request and response.

We require a 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

Solution is to 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. We are able to add and remove these filters unobtrusively, without requiring changes to our existing code.

We are able, in effect, to decorate our main processing with a variety of common services, such as security, logging, debugging, and so forth. 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.

Intecepting filters centralizes control with Loosely Coupled Handlers, Filters provide a central place for handling processing across multiple requests, as does a controller. Filters are better suited to massaging requests and responses for ultimate handling by a target resource, such as a controller. Additionally, a controller often ties together the management of numerous unrelated common services, such as authentication, logging, encryption, and so forth, while filtering allows for much more loosely coupled handlers, which can be combined in various combinations.

Intercepting filters improves reusability, Filters promote cleaner application partitioning and encourages reuse. These pluggable interceptors are transparently added or removed from existing code, and due to their standard interface, they work in any combination and are reusable for varying presentations.

Intercepting filters provide Declarative and Flexible Configuration, Numerous services are combined in varying permutations without a single recompile of the core code base.

But Sharing information between filters can be inefficient, since by definition each filter is loosely coupled. If large amounts of information must be shared between filters, then this approach may prove to be costly.

The responsibilities of the components participating in this patterns are :

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.

Strategies-

Custom Filter Strategy: Filter is implemented via a custom strategy defined by the developer. This is less flexible and less powerful than the preferred Standard Filter Strategy. The Custom Filter Strategy is less powerful because it cannot provide for the wrapping of request and response objects in a standard and portable way. Additionally, the request object cannot be modified, and some sort of buffering mechanism must be introduced if filters are to control the output stream. To implement the Custom Filter Strategy, the developer could use the Decorator pattern [GoF] to wrap filters around the core request processing logic.

Standard Filter Strategy : Filters are controlled declaratively using a deployment descriptor, as described in the servlet specification version 2.3. The Servlet 2.3 specification includes a standard mechanism for building filter chains and unobtrusively adding and removing filters from those chains. Filters are built around interfaces, and added or removed in a declarative manner by modifying the deployment descriptor for a Web application.

Base Filter Strategy: A base filter serves as a common superclass for all filters. Common features can be encapsulated in the base filter and shared among all filters. For example, a base filter is a good place to include default behavior for the container callback methods in the Declared Filter Strategy.

Template Filter Strategy: Using a base filter from which all others inherit allows the base class to provide template method [Gof] functionality. In this case, the base filter is used to dictate the general steps that every filter must complete, while leaving the specifics of how to complete that step to each filter subclass. Typically, these would be coarsely defined, basic methods that simply impose a limited structure on each template. This strategy can be combined with any other filter strategy, as well.

Using Intercepting Filters centralizes control with loosely coupled handlers. Filters provide a central place for handling processing across multiple requests, as does a controller. Filters are better suited to massaging requests and responses for ultimate handling by a target resource, such as a controller. Additionally, a controller often ties together the management of numerous unrelated common services, such as authentication, logging, encryption, and so forth, while filtering allows for much more loosely coupled handlers, which can be combined in various combinations.

Intercepting filters improves reusability. Filters promote cleaner application partitioning and encourages reuse. These pluggable interceptors are transparently added or removed from existing code, and due to their standard interface, they work in any combination and are reusable for varying presentations.

Intercepting filters are declarative and have flexible configuration. Numerous services are combined in varying permutations without a single recompile of the core code base.

But using intercepting filters the information haring is inefficient. Sharing information between filters can be inefficient, since by definition each filter is loosely coupled. If large amounts of information must be shared between filters, then this approach may prove to be costly.