PATRÓN INTERCEPTING FILTER

CONTEXTO

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 reenvio al componente manejador apropiado, mientras que otras peticiones deben ser modificadas, auditadas, o descomprimidas antes de su procesamiento posterior.

PROBLEMA

Se requiere un pre-procesamiento y un post-procesamiento de unas peticiones o respuestas de un cliente Web.

Cuando una petición entra a una aplicación Web, normalmente debe pasar varios test de entrada antes del estado de procesamiento principal. Por ejemplo,

¿Se ha autentificado el cliente?

¿Tiene el cliente una sesión válida?

¿La dirección IP del cliente es de una red conocida?

¿Viola alguna restricción el path de la petición?

¿Qué codificación usa el cliente para enviar los datos?

¿Soportamos el tipo de navegador del cliente?

Algunos de estos chequeos son tests, que resultan en una respuesta de si o no que determina si continuará el procesamiento. Otros chequeos manipulan el stream de datos entrantes a una forma aceptable para el procesamiento.

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
• Descomprensión y conversión del esquema de codificación de la entrada.

SOLUCIÓN
Crear filtros conectables para procesar servicios comunes de una forma estándar sin requerir cambios en el código principal del procesamiento de la petición. Los filtros interceptan las peticiones entrantes y las respuestas salientes, permitiendo un pre y post-procesamiento. Podemos añadir y eliminar estos filtros a discreción, sin necesitar cambios en nuestro código existente.
Podemos, en efecto, decorar nuestro procesamiento principal con una variedad de servicios comunes, como la seguridad, el logging, el depurado, etc. Estos filtros son componentes independientes del código de la aplicación principal, y pueden añadirse o eliminarse de forma declarativa. Por ejemplo, se podría modificar un fichero de configuración de despliegue para configurar una cadena de filtros. Cuando un cliente pide un recurso que corresponde con este mapeo de URL configurado, se procesa cada filtro de la cadena antes de poder invocar el recurso objetivo.

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 independientes.

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.

CONSECUENCIAS

• Centraliza el Control con Controladores de Acoplamiento Ligero 
• Mejora la Reutilización 
• Configuración Declarativa y Flexible 
• La Compartición Información es Ineficiente