La respuesta, también puede que nos interese tratarla (por ejemplo:
para transformarla, comprimirla, etc..).

La gracia es que estos filtros se pueden conectar en cascada y
activar y desactivar sin afectar al código de nuestra aplicación (o
justo lo contrario, que también nos puede interesar)

Es sencillo implementar este patrón con el uso de filtros que
podemos encontrar en últimas versiones de la especificación de
servlets.

El uno de nuestros tutoriales anteriores podéis ver la
implementación de un filtro
para comprobar la velocidad de las peticiones que nos hace un
cliente.

Un controlador se encarga de recoger las peticiones y unificar el
código repetido.

Si recurrimos a los patrones de asignación de responsabilidad (GRASP)
podemos identificar estos comportamientos desde la fase de análisis.

Podemos ver el núcleo de la creación de un controlador para
servlets en este otro tutorial.

Cuando hablamos de View Helper, hacemos referencia a clases que,
utilizadas desde la capa de presentación, encapsulan la complejidad del
acceso a las verdaderas estructuras de datos.

Cuando hablamos de JSPs, la manera más práctica de implementar un
Helper es a través de etiquetas (custom tags). Podemos ver como crear
estas etiquetas en el siguiente enlace.

Otro modo de hacerlo es a través de JavaBeans pero trataremos de
evitar lo máximo posible la inclusión de código Java. La ealción
entre TAGs y Beans la podéis encontrar en este enlace.

Normalmente, es necesario utilizar técnicas avanzadas de
composición de estas páginas para simplificar su construcción y
mantenibilidad.

JSP (y sevlets) nos proporciona mecanismos sencillos para poder
incluir porciones de una página en otra (de
modo estático o dinámico). Estos mecanismos, normalmente son
insuficientes por si mismos por lo que tenemos que utilizar algunas
técnicas más elaboradas en incluso recurrir a productos especializados
como gestores de contenidos.

Service to worker define un marco global donde separar las distintas
responsabilidades a la hora de servir una petición.

Esto además facilita la integración entre aplicaciones y la
gestión centralizada de mensajes de error….

El controlador delega sobre el dispatcher la presentación de un
elemento lógico. El dispatcher se encarga de resolver la indirección y
proporcionar el elemento físico.

El patrón MVC con servlet y JSPs utiliza un dispatcher aunque
podemos verlo de un modo más claro en aplicaciones basadas es struts.

Podemos crear unas clases que hagan de proxy sobre las funciones
reales remotas.

Este nuevo nivel de indirección añade más trabajo pero mejora la
flexibilidad.

En algunos entornos de desarrollo integrado, la construcción de
estas clases se realiza con un click de ratón.

Este patrón nos puede ayudar, combinado con otros, a resolver
situaciones particulares:

• Cache de objetos
• Repetición de peticiones cuando un objeto remoto no está
  disponible (o hay un problema temporal de comunicaciones).

Un mecanismo sencillo, en multitud de aplicaciones, para solucionar
el problema, podría ser retornar un objeto simple (Value Object). De
este modo, el rendimiento del sistema se ve mejorado.

En esta situación, podría adicionalmente existir un EJB de sesión
con estado, que se encargase de realizar las sincronizaciones.

Desde un punto de vista más simple, cuando invocamos un método una
clase, podemos pasar los parámetros agrupados en un VO (Value Object)…
incluso los valores en la sesión de un servlet, podría agruparse en un
Value Object

Aunque debemos no abusar. Este abuso se suele llamar Golden Hammer o
martillo de oro que consiste en, una vez conocida una técnica,
aplicarla indiscriminadamente en todas las situaciones (aún sin hacer
realmente falta).

La capa de presentación es posible que, para controlar el flujo de
ejecución, tenga que llamar a muchos objetos de la capa de negocio. Si
la capa de negocio está implementada como EJBs, el problema se agraba (y
más si accedemos directamente a EJBs de entidad).

Podemos crear un EJB de sesión que centralice las peticiones entre
la capa de presentación y negocio, que proporcione el correcto flujo de
control para una aplicación en concreto, sin obligar a deformar
nuestros objetos atómicos de negocio.

Si estos objetos ya existen y debemos construir una aplicación,
podríamos construir uno que los unifique, de tal modo que a la capa de
presentación (o al EJB que actue de fachada según el patrón
anterior), se le simplifican los accesos.

Adicionalmente deberíamos analizar el libro de Anti-ptrones J2EE
porque el exceso de aplicación de este patrón, también lo podemos
pagar.

Es conveniente revisar los interfaces de Java estándar para no
repetir comportamiento ya existentes en los sistemas.

Todos estos servicios requieren código particular (creación de
contexto, carga de clases, etc.) en función de la implementación
particular. Esta parte especifica que nos permite acceder a los
servicios, la podemos centralizar en un componente denominado
localizador de servicios.

Este localizador de servicios se encarga de retornarlos los recursos
listos para utilizar, independientemente de como se hayan obtenido.

Estos datos pueden estar almacenados de modos distintos (EJBs, JDO, LDAP,
etc.). A la lógica de negocio le debería dar igual como estos datos
estén almacenados y como se realicen los accesos.

El patrón DAO nos enseña como podemos hacerlo de un modo sencillo y
transparente. Este patrón realmente es una combinación de otros ….

Creo que es el patrón que hay que estudiar con mayor profundidad
porque, siendo el más obvio, es el que creo que más valor añadido
aporta.

Numerosas veces es necesario  realizar aplicaciones que envíen
una petición y dispongan de un mecanismo para atender adecuadamente a
la respuesta, cuando se encuentre disponible.

El patrón service activator nos proporciona un modelo simple que
podemos implementar a través de servicios de mensajería asíncrona
como JMS…