INTERCEPTING FILTER

Este patrón ayuda a la detección, identificación y correcto procesamiento de las diferentes tipologías de peticiones.
El objetivo principal de este patrón es interceptar y manipular solicitudes y respuestas, antes y después que éstas sean procesadas.
Algunas aplicaciones tienen requisitos como seguridad y autenticación que pueden ser aplicables a lo largo de todas las solicitudes que se realizan. Utilizando el patrón Intercepting Filter se podrá agregar este tipo de funcionalidad para que haya cierta lógica disponible para los componentes de aplicación que la requieran.
A la hora de realizar una gestión de peticiones, una de nuestras primeras cuestiones es contemplar la tipología de las mismas. La capa de presentación recibe muchas peticiones de diversa tipología. Normalmente cada tipo de petición conlleva un tipo de procesamiento propio (reenvios a componentes, cifrado, auditadas, etc.). Resulta necesario identificar y estandarizar el procedimiento que recibe cada tipo de petición.

El mecanismo de manejo de peticiones de la capa de presentación recibe muchos tipos diferentes de peticiones, cada uno de los cuales requiere varios tipos de procesamiento. Algunas peticiones simplemente requieren su reenvió al componente manejador apropiado, mientras que otras peticiones deben ser modificadas, auditadas, o descomprimidas antes de su procesamiento posterior.


Problema

Obviamente, con este patrón vamos a tener que realizar un esfuerzo previo en decodificar las peticiones y un esfuerzo en interpretar las respuestas producidas por el cliente. Una petición web recorre varias comprobaciones previas a su procesamiento (autentificación, validación de permisos, navegador, etc.). En algunos de estas comprobaciones, se evalúa si se continua o no el procesamiento.

La clave para solventar este problema de una forma flexible y no obstrusiva es tener un mecanismo simple para añadir y eliminar componentes de procesamiento, en el que cada componente completa una acción de filtrado específica.


 Solución 

La solución básica consiste en un serie de chequeos condicionales, si cualquiera de ellos falla la petición se aborta. Las sentencias if/else anidadas son una estrategia estándar, pero esta solución tiene fragilidad de código y un estilo de programación de copiar-y-pegar, porque el flujo del filtrado y la acción de los filtros se compila dentro de la aplicación.

La clave para solventar este problema de una forma flexible y no obstrusiva es tener un mecanismo simple para añadir y eliminar componentes de procesamiento, en el que cada componente completa una acción de filtrado específica.


Causas

• Procesamiento común, como un chequeo del esquema de codificación de datos o la información de login de cada petición, completo por cada petición.
• Se desea la centralización de la lógica común.
• Se debería facilitar la adición o eliminación de sevicios sin afectar a los componentes existentes, para que se puedan utilizar en gran variedad de combinaciones, como:
• Logging y autentificación.
• Depuración y transformación de la salida para un cliente específico
• Descompresión y conversión del esquema de codificación de la entrada.

 Estructura

La siguiente figura representa el diagrama de clases del patrón Intercepting Filter.








 Participantes y Responsabilidades


La siguiente figura representa el diagrama de la secuencia del patrón Intercepting Filter.





FilterManager
El FilterManager maneja el procesamiento de filtros. Crea el FilterChain con los filtros apropiados, en el orden correcto e inicia el procesamiento.

FilterChain
El FilterChain es una collection ordenada de filtros indenpendientes.
FilterOne, FilterTwo, FilterThree
Estos son los filtros individuales que son mapeados a un objetivo. El FilterChain coordina su procesamiento.

Target
El Target es el recurso que el cliente ha solicitado.

Requisitos de Implementación

• Soporte para creación de interfaces
• Soporte de herencia