Patrones de diseño J2EE

0
79413

Patrones de Diseño J2EE

Para construir aplicaciones J2EE ,de un modo profesional, debemos conocer
técnicas avanzadas de análisis, diseño y desarrollo (podéis ver otro
tutorial donde hablábamos de
patrones de análisis
).

Sun tiene una obra grandiosa (disponible
vía Web
aunque es un libro que todos deberíamos tener en las estanterías)
donde nos propone una serie de patrones para ayudarnos a la construcción de
nuestras aplicaciones java. Sin su conocimiento, y el de algunas obras más, el
diseño y desarrollo de aplicaciones puede ser nefasto…

La labor de arquitecto de software (lo que antes era el tecnólogo de las
organizaciones) es muy duro y complejo, fundamentalmente por el entorno tan
cambiante dentro del mundo Java y las nuevas tecnologías en general (yo no paro
de estudiar y siempre me faltan cosas que probar).

Os ofrecemos un pequeño resumen de algunos de los patrones ofrecidos en la
obra de Sun, con algunos toques personales. Es un requisito para entenderlos
medianamente bien haber visto los patrones
GoF
(en este enlace podéis leer sobre patrones).

Intercepting  Filter Cuando un cliente realiza una petición, se pueden
realizar comprobaciones sobre ella de un modo transparente (por ejemplo:
por si contienen código malicioso).

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.

 

Front Controler Los sistemas requieren de unos servicios centralizados de
validación de parámetros, invocación de acciones de negocio,
invocación a la vista adecuada (incluso dependiendo del tipo de
dispositivo que realiza la petición) , etc…

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.

 

View Help Un Helper es una clase que se encarga de aglutinar cierto
código común. Es aplicable tanto para las capas de negocio como para
presentación.

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.

 

Composite View Las aplicaciones Web reales agregan mucha información
distinta (contenidos) en sus páginas, muchas veces poco relacionada con
nuestro negocio (noticias, encuestas, estadísticas, cotizaciones,
etc..).

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 De los patrones vistos anteriormente, parece de sentido
común que un framework
de trabajo debe combinar todos los mecanismos.

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

 

Dispatcher View Cuando en un controlador, debemos derivar la respuesta a
un componente de presentación, normalmente deseamos separar su parte
lógica de la física. Es decir, establecer un nivel más de
indirección y poder intercambiar los elementos físicos de
presentación de un modo transparente a la lógica de la aplicació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.

 

Business Delegate Si hemos decidido, en nuestras aplicaciones, la
utilización de componentes complejos, (EJBs,
JMS,
etc) nos puede interesar simplificar su utilización  (o abstraer
la implementación para posteriormente poder cambiarla) a la capa de
presentación.

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).
Value Object Una aplicación que utilice EJB
de entidad
, cada vez que accede a un atributo, está invocando a un
método remoto. Además, existir multitud de mensajes para mantener la
integridad del objeto.

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

 

Session Facade Las aplicaciones inician sencillas pero se van poco a poco
complicando. Esto provoca que la capa de negocio se vea muchas veces
condicionada por la capa de presentación.

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.

 

Composite Entity Uno de los principales problemas de diseño a la hora de
utilizar EJBs de entidad, consiste en definirlos con un nivel muy bajo
de atomicidad (objetos muy pequeños).

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.

 

Value Object Assembler Las aplicaciones J2EE es posible que utilicen un modelo de
datos que esté compuesto por distintos tipo de objetos con distintos
accesos (EJB de Entidad, JDO,
JDBC,
etc.). Para simplificar los accesos podemos crear un objeto que se
encargue en ensamblar estos modelos.

 

Value List Handler Una aplicación cliente puede requerir una lista de
objetos que obtiene a través de la invocación de un servicio. Podemos
crear un componente que, implementando un interfaz estándar, nos
permita recuperar los valores e iterar por ellos (independientemente de
la implementación) y realizar otras labores de valor añadido (como
cachear los datos o reintentar su recuperación).

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

 

Service Locator En nuestras aplicaciones tenemos que acceder a pilas
de conexiones
JDBC, a EJBs, a servicios asíncronos, etc..

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.

 

Data Access Object Los objetos de negocio requieren acceder a datos.

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.

 

Service Activator Muchas aplicaciones no se pueden comportar de un modo
síncrono, es decir, realizar una petición y esperar una respuesta
inmediata.

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…

 

Estos patrones realmente son un punto de partida para hacernos pensar sobre
problemas comunes en aplicaciones J2EE.

Solo el estudio de las técnicas de diseño y el esfuerzo de modelado
(utilizando UML para discutir con compañeros en un lenguaje común) nos
permitirá crecer como arquitectos …

Sobre esta base y repasando la arquitectura sobre la que se encuentra construido Java
y algunos de los Frameworks más importantes, podremos llegar a construir
aplicaciones de gran valor arquitectónico (evitando errores comunes)… eso
sí…. hay que estudiar un poquito …..

Sobre el
Autor ..

Dejar respuesta

Please enter your comment!
Please enter your name here