Una arquitectura muy extendida para aplicaciones web en JAVA, es la basada en JSF, Spring e Hibernate. La intención principal es que pueda servir como idea general para otros proyectos, pero aprovecharé para comentar las ventajas que ofrecen y los problemas que nos hemos encontrado.
Capa de presentación.
JSF: Estándar de Sun para simplificar el desarrollo de interfaces de usuario en aplicaciones web. En particular hemos elegido la implementación de MyFaces y la librería de tags JSF Tomahawk.
JasperReports: Para la generación de reports.
Dozer: Con este tipo de arquitecturas se suele usar BeanUtils y código Java para mapear los Objetos de Hibernate y los Backing-beans de JSF. Nosotros hemos seleccionado Dozer para sustituir a BeanUtils.
Capa de lógica de Negocio.
Spring: Framework a nivel de aplicación. Se encarga del control de la transacción y mediante configuración proporciona a los POJOS todo lo que necesiten para ejecutar la lógica.
POJOS: Conteniendo la lógica de negocio y nada más.
Capa de datos.
Hibernate: Motor de persistencia.
DAOS: Código generado para el acceso a los datos
POJOS: O beans, representación java de la estructura de la base de datos. También se trata de código generado.
Ventajas, inconvenientes y soluciones aplicadas.
Esta arquitectura está basada en estándares y soluciones probadas de alto reconocimiento. No necesita de servidores de aplicaciones de alto coste económico y si ya se tienen funciona perfectamente en ellos. Esta arquitectura, junto con la instrucción técnica necesaria ofrece al programador una clara división de capas y funciones que debe realizar en cada capa. Facilita el mantenimiento de la aplicación y es por eso que se recomienda para proyectos de gran tamaño y/o larga vida. Reduce el código repetitivo. Control de transacción, creación de DAOS, … La arquitectura en si misma, fuerza o al menos orienta al uso de determinadas buenas prácticas. El esfuerzo requerido para la documentación, definición de plantillas y tutoriales paso a paso, también ha redundado en un mayor rendimiento y en la automatización de ciertas tareas repetitivas. Por ejemplo el desarrollador de los informes sólo se tiene que preocupar de la presentación del mismo ya que todo el código necesario es generado con Velocity.
Curva de aprendizaje larga. De la manera en la que trabajamos la curva de aprendizaje podríamos decir que es media para los desarrolladores puesto que realmente sólo tienen que aprender realmente JSF, ya que de Spring sólo se ha de entender la filosofía y de Hibernate además de la filosofía DAO, la API relacionada con las consultas. Para facilitar el aprendizaje de JSF se han realizado documentos enfocados al proyecto indicando el uso que se hace de cada tag.
También se han creado plantillas de cada uno de los archivos y se han documentado tutoriales “paso a paso” para un mantenimiento sencillo y para un mantenimiento con maestro-detalle.
Para más información sobre el tiempo dedicado al desarrollo ver apartado Tiempos.
La definición de los ficheros de hibernate es compleja y requiere el conocimiento de qué es lo que se va a necesitar, cómo y cuando. Una mala configuración puede acarrear problemas de rendimiento o un cambio en la configuración puede hacer que fallen otros desarrollos. Para crear la versión inicial se usa el generador de hibernate facilitando así el trabajo. El analista-programador que ha diseñado el caso de uso y sabe lo que se va a necesitar es quien configura los archivos, es el responsable de los mismos y el que se encarga de los posibles cambios que necesiten teniendo en cuenta su conocimiento global del proyecto.
En función de la aplicación puede convertirse en un “matar moscas a cañonazos”. Es evidente que esto puede pasar. Esta arquitectura es de tipo “general”, permite realizar “cualquier cosa”, si sólo se necesita mantener cierta información de la base de datos, apenas hay lógica de negocio, o la lógica de negocio se implementa en la base de datos y en muchos otros casos no es necesaria este tipo de arquitectura.
Tiempos
Un informe consiste en una pantalla de filtro para el usuario y un listado en PDF con los elementos que cumplen el filtro. El tiempo dedicado a cada uno de ellos se estimó inicialmente en 8 horas, pero se ha reducido el tiempo dedicado a menos de dos en la mayoría de los casos gracias a la generación de código.
Un mantenimiento simple consiste en una pantalla de filtro para el usuario, un listado paginado y las opciones de nuevo, editar y eliminar. El tiempo estimado para el desarrollo es de 8 horas, pero en la mayoría de los casos se acaban antes de que acabe el día con todas las pruebas pertinentes realizadas.
Un mantenimiento medio es aquél mantenimiento simple que mantiene más de una tabla o tiene muchos campos a mantener. El tiempo estimado en este caso es de 24 horas aunque algunos casos se ha bajado de 10.
Un mantenimiento complejo es aquél mantenimiento con maestro-detalle y muchos campos a mantener. En este caso la estimación es de 40 horas y en los resultados obtenidos hay grandes diferencias que asociamos a la complejidad de la presentación cuando hay muchos campos y a que no hay un grupo de mantenimientos muy complejos.
Ventajas e inconvenientes de cada componente de la arquitectura
JSF
Realmente simplifica el desarrollo de interfaces de usuario. En muchos aspectos es incluso más natural que Struts.Tienes control sobre algunos eventos.Los componentes pueden ser muy potentes, incluso encapsulando sus propios archivos css y js.Muy configurable. Por ejemplo se puede tener acceso declarativo a los beans de Spring. O un caso más sencillo modificar la presentación en pantalla de los datos mediante converters. No tiene un control global de excepciones. Cada método de cada Backing-Bean ha de controlar y tratar las excepciones. Tiene un ciclo de vida complejo para poder gestionar los eventos. Hay que tener muy claro que si el Backing-Bean está en scope request algunas cosas no funcionan como uno espera. Las validaciones son por componente no por formulario, haciendo difícil las validaciones basadas en otros componentes. Como efecto secundario la lógica de negocio de las consultas es llamada dos veces, la primera vez con el filtro anterior y la segunda vez con el nuevo filtro introducido por el usuario.No está pensado para el desarrollo de pruebas en muchos aspectos, aunque comparado con struts 1.0, JSF es la panacea.La extensión de sus componentes y el desarrollo de nuevos componentes requieren un buen conocimiento del ciclo de vida de los componentes.Hay claras limitaciones en el uso de librerías de Tags JSF de diferentes proveedores.
Tomahawk
Componentes básicos extendidos para aumentar sus prestaciones. Ej. El tag panel puede deshabilitar todos los inputs que contiene, facilitando mucho el desarrollo de las pantallas de consulta y edición.Nuevos componentes muy útiles. Tablas autoordenables, paginación, menú, campos fecha,… No se pueden mezclar librerías de Tags JSF de otros proveedores.
JasperReports
Se integra perfectamente con la arquitectura permitiendo reutilizar la lógica de negocio desarrollada. Es menos eficiente que usar Oracle Reports para hacer los listados, pero esto exige que se duplique la lógica de obtención del listado.
Dozer
Simple, configurable mediante XML y realiza automáticamente conversiones de tipos.Una sola línea de código para realizar el mapeo y el resto en XML. Se ha de tener cuidado con lo que mapeas y con los nombres de las funciones que no sean getter/setter.
Spring
Simple, entre comillas.Configurable mediante XML, de una manera anteriormente desconocida. Ligero.Realmente simplifica el desarrollo de la lógica de negocio, evitando que el programador se tenga que preocupar por cosas como la transacción.Realmente simplifica el desarrollo de pruebas de unidad.
Hibernate
Prestaciones de rendimiento y fiabilidad.Buenos generadores de código. Integración con PL/SLQ es pobre pero te permite hacerlo.
Referencias
Petstore. Desarrollado con JSF, Spring, Hibernate.
http://java.sys-con.com/read/46977.htm
JSF-Spring. http://jsf-spring.sourceforge.net/
Velocity. http://velocity.apache.org/engine/releases/velocity-1.5/overview.html
