icono_twiter icono LinkedIn icono Facebook Icono Xing
Roberto Canales Mora

Creador y propietario de AdictosAlTrabajo.com, Director General de Autentia S.L., Ingeniero Técnico de Telecomunicaciones y Executive MBA por el Instituto de Empresa 2007.
Twitter:

Autor de los Libros: Planifica tu éxito: de aprendiz a empresario y Informática profesional, las reglas no escritas para triunfar en la empresa

Puedes consultar mi CV y alguna de mis primeras aplicaciones (de los 90) aquí

Ver todos los tutoriales del autor

Fecha de publicación del tutorial: 2004-03-23

Tutorial visitado 67.334 veces Descargar en PDF
Intercepting  Filter

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

A continuación puedes evaluarlo:

Regístrate para evaluarlo

Por favor, vota +1 o compártelo si te pareció interesante

Share |
Anímate y coméntanos lo que pienses sobre este TUTORIAL:

Fecha publicación: 2006-07-12-04:25:23

Autor:

[Charlie] Me encanta tus manuales, la pena es que no sean mas extenso. Me gustaria que pusieras algo en esta Web de como usar UML para aplicaciones totalmente XML, JAXB, XFORMS, OWL, etc. Estoy tratando de abordar mis aplicaciones con XML y XMI para pasar datos de una herramienta a otra pero no se como orquestar esta posibilidad que veo posible desde UML. Gracias y Felicidades

Fecha publicación: 2006-06-16-08:33:20

Autor:

[Paquita Solorzano] es muy malo es muy pobre