Diseñando una arquitectura (Apéndice): Trabajo futuro

En este tiempo hemos ido dejando cosas por el camino y anotando "oportunidades de mejora". Algunas las incorporaremos en cuanto podamos, otras habrá que probarlas, otras quedarán para otros proyectos...


Todas las críticas y sugerencias adicionales serán bienvenidas, como siempre.

Objetivos:
  • Mejorar la productividad del desarrollo.
  • Reducir el desarrollo propio del framework al mínimo, maximizando el uso de herramientas open source disponibles.
  • Solventar o al menos atenuar las limitaciones de la plataforma (J2EE) y de JSF.
  • Facilitar la integración de librerías.
JSF 1.2 (+ RichFaces 3.2)

Lo primero será migrar a JSF 1.2. Este estándar está estrechamente vinculado con el servidor de aplicaciones, y hacerlo exige migrar a SJSAS 9 (o al revés, como prefieras verlo, ya que tampoco se puede usar el 1.1 en el 9). No es un gran avance en sí mismo (se espera bastante de JSF 2, hay multitud de cosas inexplicablemente mejorables todavía en la actualidad), pero llevará consigo pasar a la rama 3.2 de RichFaces, lo cual sí es una gran mejora. Nuevos componentes, mejoras muy importantes en los actuales...

JavaRebel

Tener que reiniciar el servidor constantemente es un infierno. Esta librería promete mejorar esto, minimizando la necesidad de reinicios mejorando la sustitución de clases y ficheros de configuración en caliente. Hay que probarlo.

Pruebas orientadas a datos

Probar el código de una aplicación de gestión implica conocer y manipular el estado de la base de datos. Estoy seguro de que ya hay soluciones para facilitar esto (¿TestNG, Unitils...?).

JSFUnit

Quiero poder probar a nivel de vista, y JSFUnit sirve para esto. Por ejemplo, cuando me encuentre con un problema de visualización en una página, quiero poder programar (con un coste en tiempo bajo) una prueba que demuestre que existe dicho problema, y que me sirva para comprobar que la solución efectivamente lo resuelve.

Motor de workflow

Realizamos una formación en el motor Enhydra Shark, y fue francamente decepcionante. Sí, se podía hacer lo que dice que hace, pero no ayuda a realizar una aplicación. Al elegir un componte tan fundamental en una arquitectura no me vale con que proporcione algo de valor añadido, debe ser realmente productivo. Vimos que nos iba a dar más trabajo y problemas de lo que iba a aportar, y lo descartamos en favor de desarrollar uno propio. En la actualidad lo que hemos desarrollado nos permite implementar el diagrama de flujo de un modelo a nivel de base de datos. Sin programar una línea de código nuevo podemos hacer que un modelo pase por estados, controlar a nivel de lógica de negocio la seguridad de las acciones, asignar tareas automáticamente, delimitar plazos, realizar forks y joins, declarar la seguridad a nivel de propiedad (símplemente con las propiedades rendered y displayValueOnly en los componentes JSF el sistema calcula qué campos puede ver y/o editar un usuario) y un largo etcétera. La gran ventaja de "nuestro" motor con respecto al resto, aparte de poder hacer (casi) de todo sin programar una sola línea, declarando todo en base de datos, es que tenemos componentes JSF. Mediante una simple etiqueta se pueden hacer cosas como listar las tareas pendientes, generar una botonera para ejecutar las acciones que el usuario puede hacer, mostrar el historial de la tramitación... Tener todo esto es un auténtico trabajo tangible que permite tener un flujo funcionando en una aplicación en muy poco tiempo.

El desarrollo del mismo fue por imposición, pero creo que ha sido beneficioso (suelo decir que del desarrollo propio para el framework esto es lo único realmente útil). Sin embargo, no creo que desarrollarlo desde cero haya sido lo mejor. La decisión se tomó porque ya se había perdido demasiado tiempo con el Enhydra Shark como para plantearnos otras opciones, pero estoy casi seguro de que tiene que haber alternativas mejores. Tengo jBPM en el punto de mira. Si cumple mis expectativas, mi intención es, para nuevos horizontes (no pienso reemplazar lo existente en el Framework ya), adoptarlo y ampliarlo, que para algo es open source. Por ejemplo, hacer componentes JSF que reduzcan ese salto entre el interfaz y el modelo, principalmente.

Seam

Cuando se decidió la arquitectura del framework, Seam era un proyecto prometedor pero todavía inmaduro, como han demostrado los grandes cambios y mejoras incorporados en la 2. Por ello elegimos Spring, maduro, completo, y no nos hemos arrepentido en absoluto.
Sin embargo, a estas alturas la lista de características de Seam contiene todo lo que usamos de Spring, a la vez que complementa a JSF corrigiendo sus carencias. Lo que es más, está orientado a dar "en un paquete" toda la pila de librerías, desde Hibernate a RichFaces, e integrarlas a todos los niveles. También para nuevos horizontes (estoy muy contento con el uso que damos a Spring) mi objetivo es usarlo intensivamente. 

Posted by Juan Ignacio Sánchez Lara 16:05  

15 Comments:

  1. goodkail said...
    Gracias por compartir tu expericia!
    el holgazán said...
    Muy buena tu serie de artículos.
    Algunas recomendaciones a estudiar, a lo que veo no le habeis prestado especial atención:
    - Selenium
    - JMeter
    - Maven
    - GWT para la capa de presentación de aplicaciones muy usables

    Y ¿para el futuro?: ¿Grails?
    Nacho said...
    Por partes...

    Selenium: probé BadBoy, del estilo (pruebas embebidas en el navegador), pero no me acabó de convencer. Programarlas no me resultaba cómodo, y para grabarlas la página tiene que estar ya hecha, lo cual es un handicap. Seguramente merece un segundo intento (habrán madurado desde entonces).

    JMeter: no lo he citado, pero llevo tiempo usándolo, especialmente para pruebas de carga, aunque también pruebas funcionales mediante aserciones.

    El problema de los anteriores para las pruebas funcionales son los datos. Es engorroso definir y usar conjuntos de datos de entrada y esperados de salida.

    Maven (2) está citado en la siguente entrada :).

    GWT me interesa mucho, pero no lo veo todavía suficientemente maduro. Hace poco he hecho alguna pruebecilla (me interesaba especialmente el combo de GWT+Gears), pero no lo veo tan completo ni fácil de desarrollar como JSF+RichFaces. Pero voy a mantener un ojillo puesto en él.

    Grails es una de las cosas que suenan con frecuencia que no he podido probar. ¡Hay tantas (Wicket, Groovy, Velocity, ICEFaces, Spring Web, Shale...) que no se da abasto!

    Gracias por las recomendaciones!
    jcesarperez said...
    Lo primero, mi enorabuena por ese gran trabajo de evolución que has realizado sobre la arquitectura de tu empresa. No ha debido ser nada fácil, ya no sólo el tema tecnológico sino, sobretodo, el humano. Eres una máquina.

    Felicidades también, por supuesto, por contarlo tan ordenadamente, con estilo y con modestia.

    Comparto tu punto de vista en muchos aspectos, en especial en la importancia que le das a la formación y el aprendizaje. Realmente sorprende el nivel medio en aptitud y actitud de muchos compañeros de profesión.

    En cuanto a tecnología, no soy tan optimista como tu con JSF e Hibernate, sobretodo con JSF al que trato de evitar todo lo que puedo. Hibernate es una tecnología muy útil, pero no es la bala de plata para el acceso a base de datos.

    Tengo mucha curiosidad por saber como funcionais en muchos temas. En especial: integración continua, gestión de tareas/issues, cobertura de pruebas y requisitos.

    Me ha gustado mucho la idea de que las preguntas se hicieran por foro. Era la opción mas reutilizable visto el número de personas involucradas.

    También he visto que andas muy preocupado por las pruebas en las que interviene el estado de base de datos. Por si te sirve de ayuda, te puedo comentar como lo hacemos nosotros.

    Por un lado usamos mocks que simulan los dao y así conseguimos que éstos devuelvan justo lo que queremos.
    Para los casos que no usamos mocks, lo que hacemos es tener un script sql que carga la base de datos con los registros necesarios. El script lo ejecutamos dde ant, lo que permite integrarlo facilmente en el proceso de test que tambien lanzamos dde el ant. Pero tb se puede lanzar el script dde ant y ejecutar un test concreto en el Eclipse.
    Si nada de esto te convence, puedes mirar tb DbUnit para inicializar la base de datos y comprobar su estado despues. Yo lo estuve evaluando, pero si ya me cuesta que hagan tests, que ademas hicieran el DbUnit lo veia demasiado.
    Nacho said...
    Muchas gracias, jcesarperez (por cierto, como habrás visto has ganado otro lector para tu blog).

    No, Hibernate no es la bala de plata, realmente creo que ésta no existe en nada en informática. "La única respuesta que siempre es válida es 'depende'". Pero sí creo que sus ventajas superan con creces sus inconvenientes.

    JSF está lejos de ser ideal, pero la combinación con Facelets y RichFaces me encanta, y espero que Seam corrija adecuadamente gran parte de sus limitaciones. ¿Qué otras alternativas de MVC con Ajax recomendarías para J2EE?

    Los mocks me serían de utilidad en ciertos casos, cierto. Tengo que ver cuántas pruebas podrían sustituir la capa DAO con ellos. Aunque esto haga que requiera pruebas específicas para los DAO, seguramente merezcan la pena.

    El uso de otra librería más como DbUnit es lo que tiene, introduce aún más trabajo, por liviano que sea...

    Muchas gracias por las recomendaciones,
    jcesarperez said...
    Hola de nuevo Nacho.

    Si usas Hibernate+Spring para los dao y ademas generas el modelo de bd con Hibernate, no necesitaras muchas pruebas. Con 1 unico test puedes probar todos los mapeos y luego alguno más para cosas complicadas, como operaciones en cascada.
    Insisto en lo del script de inicializacion de la base de datos. Con él sabes que la bd siempre va a estar en un estado conocido para hacer todos los tests que quieras, luego al terminar el test haces un rollback y todo sigue igual para el siguiente. Ademas eso con la clase de test transaccional de Spring sale solo.

    En cuanto al tema JSF, te vas a sorprender jeje. Nosotros aun usamos Struts1. Es un framework que en sus últimas versiones más XDoclet superó sus principales debilidades (configuración y excesivo número de clases Action y Form) aunque mucha gente no lo sabe. Además mi equipo lo domina a la perfección y para lo que hacemos nos funciona perfecto. Así que entre que no le veo la necesidad de cambiarlo y qué no sabría por cúal (Struts2?, Spring MVC?, JSF?, GWT?, Stripes?, Tapestry?, Seam? ...) seguimos usandolo.
    Para la magia Ajax usamos DWR, no se si lo conoces, te permite invocar remotamente métodos de clases Java desde Javascript.
    Y para los efectos especiales usamos JQuery y su infinidad de plugins, en especial su fantastico grid.
    Nacho said...
    Ya vi el test que verifica todos los mapeos en tu web ;)

    Sorprende lo de Struts, pero está claro que los argumentos son buenos. Yo elegí JSF porque quería Ajax sin programar Javascript, y en eso JSF+RichFaces cumple a la perfección.
    Anónimo said...
    Hola,

    Un comentario acerca de Shark, el workflow desechado:
    yo lo utilicé hace un par de años (versión 1.x) en un proyecto y aunque la API es algo compleja es bastante potente y flexible y en poco tiempo (y con algo de esfuerzo, es cierto) conseguimos hacer un proyecto bastante interesante y que funcionaba muy bien.
    Ahora estoy pensando volver a utilizarlo y tengo que ponerme al día de los cambios en la nueva versión 2 y pico.

    Estoy buscando información para ahorrarme la puesta al dia de la nueva versión y al ver esto no sé... ¿Habéis descartado la versión 2 o la 1?

    Hoy mismo desde el foro de Shark he recibido un correo a un nuevo producto que parece que permite usar Shark desde Eclipse, tiene muy buena pinta aunque no he tenido tiempo de evaluarlo.

    En fin, miraré también alternativas por si acaso.
    Nacho said...
    Buenas,

    Desechamos la versión 2. La razón definitiva fue que no conseguimos hacerlo funcionar en el SJSAS 8, pero aún así lo que ví no me gustó (a pesar de que recibimos un curso de 4 días). Aunque se pueda "hacer funcionar" creo que daría más trabajo del que quita.

    Para la próxima pienso probar jBPM.
    Juanjo said...
    Muy buena relación de artículos!!!

    Nosotros estamos valorando más o menos la misma pila en la que vosotros habéis estado trabajando y estamos a punto de comenzar con los trabajos de normalización del uso de cada una de las tecnologías.

    Nuestro objetivo principal es no tener una gran cantidad de desarrollo (venimos de un framework desarrolado ad-hoc) sino normalizar una pila de productos .

    Con respecto a la pila que habéis planetado, coincidimos casi en todo. Una en la que no coincidimos es en el manejo del flujo de pantallas. Nosotros incluiremos Spring WebFlow para esto.

    La inclusión de jBPM en el futuro también la tenemos en el roadmap pero no en la primera fase de nuestro producto.

    Tengo una pregunta para vosotros. Viendo la pila de productos que habéis escogido, no habéis valorado el uso de "appfuse" para acelerar el desarrollo? Habéis incluido vuestros propios scripts o herramientas de Desarrollo para esto?

    Un saludo
    Nacho said...
    Hola, Juanjo,
    Hay (literalmente) cientos de frameworks a considerar cuando desarrollas web, y no se puede tener en cuenta todos. Hace más de dos años decidimos tirar por JSF (RichFaces + Tomahawk + MyFaces + Facelets), Spring e Hibernate. Ahora, la evolución natural de esto es Seam, y viendo las características de AppFuse, ni me planteo un "Seam vs. AppFuse". Te lo recomiendo encarecidamente.
    Nacho said...
    Había quedado preguntas por resolver:

    - Para el manejo del flujo de pantallas, cuando el de JSF (con las mejoras de Seam) se quede corto, Seam permite usar jBPM, que será lo que usemos.
    - JBPM, igual que Drools, es MUY interesante. Aunque no lo uses desde el principio, adoptar Seam asegura que el coste de incorporarlo es nulo.
    - Antes, para el desarrollo, teníamos MyEclipse, una "guía de comienzo de proyectos", unas cuantas clases esqueleto, y un par de scripts ant (especialmente para los diferentes despliegues). Ahora, Eclipse (Ganymede) con JBoss Tools nos cubre todo esto (y más).

    Cuando tenga tiempo y ganas ampliaré la información sobre Seam, pero la experiencia con él está siendo muy, muy, buena.
    technodrops said...
    Hola Nacho,

    Nosotros ya habemos probado Seam y comparto todas tus opiniones. Es un Full-Stack entero, incorpora herramientas de desarrollo... incluso posibilita el trabajo con WebBeans. Esta última característica creo que es lo que más están potenciando ahora y creo que esta tecnología terminará siendo un estándar para JEE.

    La no utilización de Seam por el momento se debe principalmente a que nosotros vamos a ofrecer una arquitectura modular en todas las capas. Con esto quiero indicarse que tenemos una gran masa de desarrollo que conoce Struts y que tenemos que contemplar. Seam+Struts... mala pareja hacen.

    Es por eso por lo que estamos intentando ir con JSF/Struts/SpringMVC... + Spring + Hibernate (aunque también posibilitaremos el uso de EJB3 o implementaciones concretas de JPA)

    Nuestra arquitectura será de tipo "pizza" en la que la masa y posibles cmbinaciones las ponemos nosotros pero los ingredientes los eliges tú.

    Si tuviera la posibilidad de apostar únicamente por una tecnología, creo que iría por JBoss Seam por la cantidad de componentes que proporciona (creo que todos o casi todos los que se necesitan en el 99% de las aplicaciones).

    Seguimos en contacto.
    Elmer W. said...
    Interesante todo lo del blog, yo estoy introduciendome al desarrollo JAVA y tengo serias dudas sobre que framwork usar. Leo tanta variedad: appFuse, Grails, IceFaces, RichFaces, Shine, myFaces, luego veo Hibernate, Struts y no logro aterrizar sobre cual me convendría usar. Si me puedes ayudar con alguna sugerencia, estare altamente agradecido.
    Nacho said...
    Seam :). No sé si será el mejor, pero es muy bueno y lo que será el estándar JEE 6 está tomado en gran parte de él.
    Haz una aplicación con él, y nos cuentas :)

Post a Comment