Aplicacin de Patrones J2EE en un Caso de Estudio

1 . Resumen 2 . 1.- Introduccin 3 . 1.1.- Value Object 4 . 1.2. Session Faade 5 . 1.3 Data Access Object 6 . 2. Caso de estudio 7 . 3. Implementacin 8 . Conclusiones

Resumen
El siguiente documento tiene por objetivo definir y aplicar los patrones de diseo Session Faade, Data Access Object y Value Objet a un ejemplo particular. Para lograr este objetivo, se define que son los patrones J2EE, para posteriormente concentrarnos en la definicin de los patrones de estudio. A continuacin, se define un caso de estudio en el cual se aplican tcnicas de anlisis y diseo orientado a objetos, ilustrando la aplicacin de los patrones directamente en la fase de diseo. Finalmente, se desarrolla una aplicacin web de baja escala, la que implementar una solucin a la problemtica del caso de estudio en JSP / Struts / JDBC. Los resultados del estudio permiten a los desarrolladores J2EE que no tienen conocimientos sobre el tema de patrones, comprender su aplicacin y aprender su utilizacin por medio del ejemplo.

1.- Introduccin
Sun Microsystem provee en su sitio web [SUN03-1] [SUN03-2] un conjunto de patrones que pueden ser usados en el contexto del diseo de aplicaciones Java 2 Enterprise Edition, J2EE. Los patrones de diseo J2EE consisten en soluciones recurrentes y documentadas de problemas comunes de diseo de aplicaciones J2EE. Muchas de estas soluciones se basan en los patrones de Gamma et al. [GAM95], as que se podrn encontrar soluciones J2EE que son aplicadas al diseo de aplicaciones de software en general. Un patrn J2EE consiste en un documento basado en una plantilla que define las siguientes secciones:

Contexto: Juego de entornos bajo los cuales el patrn existe Problema: Describe el problema de diseo enfrentado por el desarrollador. Motivacin: Lista de las razones y motivaciones que afectan al problema y a la solucin. Esta lista resalta la razn del porqu se debe elegir utilizar el patrn en discusin en un problema de diseo y de la justificacin de su utilizacin. Solucin: Describe el acercamiento a la solucin brevemente y los elementos de la solucin en detalle. Esta seccin contiene 2 subsecciones: Estructura: Diagrama de clases que definen los objetos y relaciones entre estos. Estrategias: Describen diferentes formas de cmo un patrn puede ser implementado. Consecuencias: Los trade-off (ventajas y desventajas) cuando se aplica el patrn.

A continuacin, se definen los patrones J2EE Value Object, Session Faade y DAO..

1.1.- Value Object

Contexto Las aplicaciones cliente necesitan comunicar, transportar e intercambiar datos de negocios con los Enterprise Java Beans, objetos JDBC y otros objetos. Problema

Cada llamada a get y set de un objeto remoto implica una invocacin remota, lo que afecta directamente en la escalabilidad de una aplicacin.

El paso de los atributos de un objeto de dominio (por ejemplo, Consumidores) a un mtodo puede conducir a mtodos con muchos argumentos, y cada modificacin de un atributo del objeto de dominio afectar la signatura de todos los mtodos que usen este objeto, teniendo con ello problemas de acoplamiento y mantenibilidad.

Motivacin

Solucin

Las aplicaciones J2EE generalmente hacen uso de EJB para la implementacin de los componentes de negocio, lo que implica que cada llamada a una propiedad de un entity bean por medio de los mtodos get/set significara una llamada remota. El cliente requiere ms de un atributo del componente remoto, lo que conduce a varias llamadas de red (ej, ingreso de un Consumidor).

Se debe usar una clase que implemente el interfaz Serializable (redefinir el metodo toString() ), en donde sus propiedades miembro pueden variar segn el tipo de enfoque: Si se necesita modelar una tabla relacional o similar, las propiedades de la clase seran las mismas que los campos de la tabla relacional. Este enfoque se denomina Domain Value Object [MAR02]. Si se necesita encapsular atributos de varias tablas en una peticin (por ejemplo, un carrito de compra, con el id de un cliente, el id y cantidad de un producto), se crea una clase que combine todos los atributos que son requeridos. Este enfoque se denomina Custom Value Object [MAR02]. En una aplicacin que no utilice un VO para una operacin de negocios, se tendra la siguiente signatura en un mtodo crear:

public void crearConsumidor(String rut, String nombre, String Apellido, Calendar edad.)
Es claro que la signatura es muy larga y difcil de escribir, y que su dificultad de escritura es proporcional a la cantidad de campos de una tabla. Sin embargo:

public void crearConsumidor(ConsumidorVO vo)

Provee de una signatura mucho ms sencilla que la anterior, puesto que se enva una referencia del objeto consumidor, el cual encapsula todos los datos requeridos. La estructura del patrn es la siguiente: Consecuencias

En el contexto de aplicaciones remota, se logra una mayor eficiencia, puesto que reduce el envo de mensajes por red. En el contexto de JDBC, permite representar un conjunto de atributos procedentes de uno o varios objetos de dominio, representados por la signatura mtodo (VO) en ves de mtodo (arg1, arg2, arg3). Un Value Object puede contener informacin obsoleta si se pretende usar en una actualizacin posterior en otra transaccin. Esto se puede corregir con el patrn Versin Number [MAR02].

1.2. Session Faade

Contexto Clases Java comunes o EJB encapsulan lgica y datos de negocios, exponiendo sus interfaces y la complejidad de los servicios distribuidos a la capa cliente. Problema En un mtodo de aplicaciones donde se utiliza la arquitectura estratificada (o por capas), se pueden presentar los siguientes problemas:

Acoplamiento fuerte, provocado por la dependencia directa entre los clientes y los objetos de negocio.


Motivacin

Demasiadas llamadas a operaciones entre el cliente y el servidor, abocando a problemas de rendimiento de red (en el caso de EJB). Falta de una estrategia de acceso uniforme de los clientes, exponiendo los objetos de negocio a una mala utilizacin.

Solucin

Proporcionar a los clientes un interfaz sencillo que oculte todas las interacciones complejas entre los componentes de negocio. Ocultar al cliente las interacciones y las interdependencias entre los componentes de negocio, permitiendo de esta forma el aumento de flexibilidad y evitar que los cambios en los objetos de negocio repercutan en errores en la vista. Evitar la exposicin directa de los objetos de negocios a los clientes, para mantener el acoplamiento entre las dos capas al mnimo. Centralizar los casos de uso en mtodos centralizados sobre una clase.

Usar un session bean (para el caso de aplicaciones EJB) o una clase java comn que encapsule la complejidad de las interacciones entre los objetos de negocio participantes en un flujo de trabajo (workflow). El session faade maneja los objetos de negocios y proporciona un servicio de acceso uniforme a los cliente. Es decir, el cliente (JSP, Swing, etc) no tratar con los EJB ni con la complejidad del acceso remoto, ni con JDBC, sino que trabajar con colecciones y Value's Object. . La estructura del patrn es la siguiente Consecuencias

Introduce una capa extra entre el Modelo y el Controlador: Agregando esta capa, se puede modelar los casos de uso de una forma centralizada, logrando tambin centralizar todo el acoplamiento a esta capa intermedia. Expone un interfaz uniforme para el acceso al Modelo. Cuando se utiliza con EJB, reduce el nmero de invocaciones remotas, aumentando la escalabilidad. Simplifica la gestin de transacciones y el mantenimiento de los casos de uso.

1.3 Data Access Object

Contexto El acceso a los datos vara segn el soporte persistente y el proveedor. Problema

La poca homogeneidad del almacenamiento persistente produce distintas implementaciones para lograr la accesibilidad (la iimplementacin de operaciones sobre un archivo de texto plano es distinta a la realizada sobre un motor de base de datos, aunque se requiera de ambos las mismas operaciones)). Un cambio en el sistema de almacenamiento (cambio de proveedor de bd o de formato) puede conducir a una reimplentacin de los componentes de datos y componentes vinculados (los que requieren estos datos). Con el API de JDBC se puede acceder de una forma estndar a los servidores de bases de datos relacional. Sin embargo, la implementacin del lenguaje SQL puede variar segn el propietario, aunque se suponga que es un estndar (por ejemplo, las operaciones para recuperar el autonumrico de un registro ingresado no es igual en Oracle que en MySQL o SQLServer). El acceso a datos de sistemas no relacionales incurre en la utilizacin de un API no propietario, por lo que se aumenta la dependencia entre el cdigo de la aplicacin y el cdigo del acceso a datos. Introducir el cdigo de conectividad en todos los componentes que requieren de acceso hace difcil la mantencin y la migracin cuando se desea cambiar la fuente de datos.

Motivacin

Los componentes de la aplicacin necesitan recuperar y almacenar informacin desde almacenamientos persistentes y otras fuentes de datos variadas (includos archivos de texto, planillas de clculo, etc). Adems, puede variar los proveedores, por lo que se tiene el problema del SQL propietario. Una API de datos que exponga al cliente un conjunto de operaciones comunes lograra reducir el acomplamiento y dependencias de la implementacin. Por ejemplo, una tabla de clientes en un modelo relacional para el proveedor Oracle o MySQL tiene las mismas operaciones: agregar, eliminar, modificar, etc. Sin embargo, algunas operaciones pueden tener distintas implementaciones (porque el SQL para esa accin puede ser distinto segn el proveedor), pero esto sera independiente para los clientes (por medio de una factory) Los componentes necesitan ser transparentes al almacenamiento persistente real o la implementacin de la fuente de datos para proporcionar una portabilidad y migracin sencillas a diferentes productos, tipos de almacenamiento y tipos de fuentes de datos.

Solucin

Estructura

Utilizar un Data Access Object (DAO) para abstraer y encapsular todos los accesos a la fuente de datos, logrando as desacoplar la lgica de negocios de la lgica de acceso a datos. El DAO maneja la conexin con la fuente de datos para obtener y almacenar datos. El desacoplamiento de la lgica de negocios con el acceso a datos permite crear implementaciones plugables del DAO, con solo seleccionar el tipo de fuente de datos durante la instalacin/configuracin de una aplicacin.

Consecuencias

Flexibilidad en la instalacin/configuracin de una aplicacin. Independencia del vendedor de la fuente de datos. Independencia del recurso (base de datos relacional, base de datos orientado a objetos, ficheros planos, etc.). Reduce la complejidad de la implementacin de la lgica de negocios (Session Faades) Ms complejidad en el diseo, debido principalmente al conjunto de clases que colaboran en el DAO y en forma general, cada DAO es utilizado para modelar una tabla del modelo relacional.

2. Caso de estudio
Para aplicar estos dos patrones J2EE, se presentar un caso de estudio de baja escala, en el cual se aplicar en forma directa los patrones de diseo vistos anteriormente. El caso de estudio se enmarca en el grupo de desarrollo Inukisoft. Esta empresa basa su principal actividad en el desarrollo de software, por lo que requiere de una web que permita a los clientes ver la oferta de productos y enviar consultas / sugerencias. Los administradores de la web de Inukisoft deben poder revisar las consultas y actualizar el catlogo de productos, con una cuenta exclusiva para usuarios administradores. Se especifica que se requiere de una nica cuenta de administracin, por lo que no se deber registrar una lista de usuarios. Cada producto incluye su identificador, nombre, descripcin. Los administradores podrn actualizar todos los datos de estos productos, y eliminarlos si lo consideran pertinente. Las siguientes funciones se pueden resumir en el siguiente diagrama de casos de uso:

En base a este diagrama de casos de uso, se pueden identificar algunos objetos de dominio candidatos: Producto de software, Catlogo, Consulta, Cliente y Administrador. Definiendo un diagrama de clases para armar el modelo conceptual, quedara: Ya definido un bosquejo del anlisis, toca ir al diseo de la aplicacin. Para ello, se define el modelo de datos que se utilizar.

Atributo / Tipo id / entero largo sin signo autonumrico

Descripcin del atributo Identifica a cada consulta con un nmero

correlativo. consulta / texto largo 255 fecha / tipo fecha timestamp Tabla: Atributo / Tipo id / entero largo sin signo autonumrico nombre / texto largo 50 descripcion / texto largo 1000 precio / flotante sin signo El texto de la consulta efectuada por el cliente La hora y fecha de la consulta ProductoSoftware Descripcin del atributo id / entero largo sin signo autonumrico Describe las funcionalidades del producto La hora y fecha de la consulta El precio del producto de software

Los otros elementos del modelo conceptual no estn incluidos en el modelo relacional, puesto que no son entidades que almacenan cantidades de datos. Ya con los objetos de dominio persistentes definidos, se puede entonces aplicar directamente el patrn Domain Value Object sobre las tablas Consulta y ProductoSoftware, por lo que se obtendra las clases ConsultaVO y ProductoSoftwareVO.

Ya generalizadas las tablas del modelo relacional en clases, se debe a continuacin aplicar el patrn DAO a las tablas Consulta y Producto de Software. Bellas [BEL03] propone un esquema estructural para los DAO's, el cual se reutilizar este diseo para la tabla Consulta:

Tabla: Clase / Interface SQLConsultaDAO Descripcin

Consulta Interface que define todas las operaciones de accin y consulta de la tabla Consulta Clase Abstracta que implementa SQLConsultaDAO. Los mtodos implementados en la clase abstracta son los que son independiente de plataforma (en general son todos, a excepcin del mtodo create() ). Subclase de AbstractSQLConsultaDAO, la cual es una clase concreta y final que implementa los mtodos dependientes de la plataforma. En general, se implementa el mtodo create(), puesto que el campo clave de la tabla es un autonumrico, por lo que la estrategia de recuperacin, en este caso, es por DriverJDBC del tipo 3. Clase que implementa el patrn de diseo Factory Method [GAM95]. Esta clase define cual subclase de AbstractSQLConsultaDAO debe ser instanciada cuando se utiliza el DAOConsulta.

AbstractSQLConsultaDAO

JDBC3CCConsultaDAO

SQLConsultaDAOFactory

El diagrama de clases de este DAO queda representado de la siguiente manera: Podramos reutilizar este diseo de clases para la tabla ProductoSoftware, por lo que se tendra terminado el Modelo de Tablas del sistema.

El siguiente paso del diseo es definir donde van a ir implementados los casos de uso. Para ello, se puede aplicar directamente el patrn Session Faade, donde se definirn todas las operaciones de los casos de uso. La faade es una clase concreta, definida de la siguiente forma:

package inukisoft.patronesj2ee.facade; public class ProductoSoftwareFacade { public ProductoSoftwareVO createProductoSoftware(ProductoSoftwareVO vo) throws InternalErrorException,DataBaseException {} public ConsultaVO createConsulta(ConsultaVO vo) throws InternalErrorException,DataBaseException {} public Collection listConsulta() throws InternalErrorException {} public Collection listProductoSoftware() throws InternalErrorException {} public void removeProductoSoftware(Long softwareIdentifier) throws InternalErrorException {} public void removeConsulta(Long consultaIdentifier) throws InternalErrorException { } public void updateProductoSoftware(ProductoSoftwareVO vo) throws InternalErrorException, DataBaseException {} public ProductoSoftwareVO findProductoSoftware(Long softwareIdentifier) throws InternalErrorException,DataBaseException { } }
Esta faade ser el punto de acceso a todas las funcionalidades del sistema. En una arquitectra MVC (Modelo Vista Control), los DAOs y el VO representan la capa Modelo. La Vista puede ser representada por una aplicacin Swing, JSP o Applet. La vista se comunica con las clases controlador, las cuales son las que se comunican a su vez con la faade del sistema. De esta forma, se tiene una arquitectura general del software con menos acoplamiento, lo que permite trabajar con el modelo de forma independiente a la vista (potenciando la separacin de roles de trabajo, por ejemplo, equipo de desarrollo del Modelo, equipo de desarrollo de la Vista y Control, etc.) La siguiente fase del diseo es definir la vista que se favorecer del Modelo. Segn el caso de estudio, se requiere de una WebApp, por lo que las vistas sern implementadas como JSP y las clases controlador sern definidas como Servlets Action (subclase de Action de Struts) que invocan a los datos de la faade (para evitar que la vista se comunique directamente con la faade del sistema). Para definir los elementos de la vista, se requiere del diseo de la navegacin, la cual ser jerrquica:

Mapa de navegacin / componentes de la vista Administrador (1) Tambin incluye la siguiente jerarqua:

La navegacin de la vista Cliente queda definida de la siguiente forma:

Los servlets action cumplen el rol de controlador de flujo de las acciones, seteando los datos que deben presentarse en las pginas JSP, y tambin son utilizados para invocar a los mtodos de negocios definidos en la faade.

3. Implementacin

En la implementacin se deben codificar los modelos de clases obtenidos del diseo (en este caso, en un diseo logrado con la aplicacin directa de los patrones de diseo). Se debe tener en cuenta que el patrn de diseo representa una solucin de diseo, teniendo como objetivo la reutilizacin. Sin embargo, la codificacin del patrn de diseo a lenguaje Java no conduce necesariamente a componentes reutilizables, por lo que se debern utilizar otras herramientas para hacer reutilizable el cdigo obtenido. En esta investigacin se utiliz el Refactoring de Eclipse para reutilizar el cdigo de las clases, utilizando un DAO de otro proyecto anterior, para luego adaptar el nombre, la ruta de los paquetes, y la redefinicin del mtodo (en general, cambiar el SQL). Las vinculaciones y correcciones de nombres son realizadas por el IDE. Esta tcnica es til para los DAOs que tienen pocos campos y que cumplen las mismas funcionalidades bsicas (por ejemplo, una tabla pais (id,descripcin) y otra tabla categorias (id, categoria) las que son utilizadas para llenar los comboBox de un formulario). La implementacin del Modelo Vista Control se realiz en Struts 1.1 [APA02], aconsejando la siguiente metodologa en la implementacin del mapa de acciones [URZ03]: 1. Definir el mapeo correspondiente a la nueva accin en el archivo struts-config.xml, indicando el nombre de la accin, y la clase Action que ejecutar las acciones correspondientes, el nombre del FormBean que validar los datos, el alcance que tendrn esos datos, de donde ser referenciada y quien desplegar los datos para los ActionForward definidos en el servlet. (ver struts-config.xml) Escribir el BeanForm, y realizar las validaciones correspondientes para asegurar que los datos lleguen al controlador (Action). (ver ProductoSoftwareForm.java) Escribir el Action Servlet, el cual ejecutar las acciones del requerimiento (tpicamente una invocacin a la faade, la asignacin de valores al FormBean y la asignacin de valores asociados a la Request). (ver EditVerCatalogoAction.java) Escribir el o los archivos JSP que generar la vista para el usuario. Se debe tener especial cuidado con los beans y atributos que se utilizarn en este archivo ya que deben estar definidos en el FormBean e ingresados como atributos al requerimiento que recibe la pgina JSP.(ver VerCatalogo.jsp)

2.

3.

4.

Para implementar los componentes de la vista, se utiliza Java Standar Tag Library (JSTL), puesto que consiste en una solucin, basada en XML, que sustituye el scriptlet incristado de la pginas JSP por tags XML [PAL03]. Este tipo de solucin permite adecuar la vista a los roles que no estn familiarisados con el cdigo Java, como por ejemplo, los diseadores. De esta forma, se mejora la separacin de roles de trabajo.

Conclusiones
La implementacin de patrones J2EE no es trivial en los desarrollos de aplicaciones empresariales. Los desarrolladores necesitan conocer propuestas metodolgicas para una correcta implementacin de los patrones. La investigacin entrega un aporte metolgico, junto con un producto de baja escala con ejemplos de implementacin. El cdigo fuente del caso de estudio, incluido en la investigacin, puede ayudar a comprender la implementacin del patrn, pero debe quedar claro que los patrones no son las respuestas nicas a un problema, sino que ms bien representan una solucin estructural y de comportamiento para un problema de diseo recurrente.