Ejercicio: Uso de patrones de diseño en una aplicación con EJBs


Los requerimientos de la aplicación AmigosJ2EE se han ido ampliando y modificando con el tiempo. Se necesitan ahora una serie de características que no se habían planificado en un principio:
Dados estos requerimientos se está intentando cambiar el modelo de datos de la aplicación a uno basado en EJBs de entidad con persistencia manejada por el contenedor, ya que el modelo antiguo basado no es accesible a clientes remotos y el código JDBC de los DAOs se va haciendo demasiado costoso de mantener a medida que se complica el modelo de datos. Asímismo la introducción del cobro por el servicio de mensajes hace interesante la idea de poder gestionar automáticamente las transacciones, lo que implicaría la utilización de EJBs de sesión.

EJBs de entidad definidos

Por el momento, como se está empezando a definir la capa EJB solo se han definido dos beans de entidad. Ambos beans tienen interfaces locales  y remotos para permitir los dos modos de acceso.

Arquitectura utilizada

Desgraciadamente se ha utilizado una arquitectura "para salir del paso". En teoría la funcionalidad de envío y recepción de mensajes está implementada pero sin seguir una estructura razonable. El comportamiento actual de la aplicación es el siguiente:




Arquitectura deseada


Vistos los requerimientos e inspirándose en patrones de diseño J2EE se ha decidido que el sistema tenga una arquitectura similar a la de la figura



De esta forma:

Por tanto, se pide:
  1. Implementar una clase Service Locator que sea un singleton y que centralize todo el código de acceso a EJB. Dicha clase tendrá métodos que recibirán como parámetro un nombre JNDI y devolverán interfaces Home remotos o locales. La implementación se puede hacer con métodos genéricos (más recomendable) o particulares. Es decir, puede haber un método public EJBHome getEJBHome(String nombre) o bien uno getUsuarioHome, otro getMensajeHome,...OPCIONAL: implementar una cache (basada por ejemplo en una HashTable) en el Service Locator para que si se pide varias veces un interface Home no se solicite siempre de nuevo a JNDI.
  2. Implementar el patrón Business Delegate que se ocupe de delegar en la capa de negocio. Es recomendable implementar un MensajeDelegate que se encargue únicamente del tema de mensajes.
  3. Implementar el patrón Session Façade para gestionar el envío y lectura de mensajes. Será un bean de sesión de la clase MensajeFacadeBean al que se llamará de modo remoto. OPCIONAL: definir también un interfaz local, útil para el caso de que se decida dejar todo en la misma JVM.
  4. Utilizar el patrón Transfer Object para transferir datos entre el Session Façade y el Business Delegate. Recordar que en principio el Session Façade es remoto, por lo que los objetos para transferir información deben ser serializables. Implementar una clase MensajeTO que lleve los datos de un mensaje a y desde la capa de presentación.
  5. OPCIONAL: implementar el patrón Intercepting Filter para controlar la seguridad de la aplicación. Desarrollar una clase llamada FiltroSeguridad que será un filtro de servlet y que interceptará todas las peticiones a la clase Controlador. Dicha clase tendrá una lista de acciones que requerirán login previo (si el usuario ha hecho login correctamente en la sesión HTTP debería haber un atributo accesible con getAttribute llamado login). En caso de solicitar una acción no autorizada, el filtro redirigirá al usuario hacia la página principal (index.html). La descripción del patrón intercepting filter se puede ver en la página de Core J2EE Patterns

Configuración de la aplicación

Para instalar AmigosJ2EE es necesario realizar los siguientes pasos:
  1. En el código de las plantillas está el proyecto de Eclipse comprimido en .zip. Dicho proyecto tiene la siguiente estructura:
  2. La aplicación necesita de una base de datos para funcionar. Para simplificar la creación de la base de datos, lo más conveniente es:
  3. Para que el código Java compile adecuadamente en Eclipse es necesario decirle dónde está la librería weblogic.jar. En Project->Properties pinchar en la solapa Libraries y editar el path de weblogic.jar para que se corresponda con el real (debería ser /home/j2ee/bea/weblogic/server/lib)
  4. La compilación y despliegue también se pueden hacer con Ant (de hecho el despliegue se hace únicamente con Ant). Para ello hay que definir la propiedad bea.home con el directorio de bea (en el laboratorio debería ser /home/j2ee/bea).
  5. El despliegue que hace el script de Ant (target deploy) simplemente copia la aplicación en el directorio applications del dominio examples. Si se observa cualquier problema de actualización (puede pasar con EJBs si se cambia la estructura de la clase o el descriptor de despliegue) borrar la aplicación desde la consola de Weblogic, ejecutar el target de Ant cleanServer  (que borra el directorio en el servidor) y volver a hacer el deploy.