Infraestructura web JAVA
¿Qué harías si sabes que cualquier cosa (herramienta, framework,...) que elijas sabes que la vas a tener que cambiar en unos años? Pues prepararte para el cambio: buscándolo.
El montaje que hemos realizado para los desarrollos JAVA sigue la clásica configuración de tres capas: presentación, servicios y persistencia, intentando no atarnos a ninguna tecnología demasiado de la que nos sea imposible prencindir en un momento dado.
La elección de las tecnologías depende de muchos factores que no son solo tecnológicos, como el conocimiento con el que puedes contar en la organización para empezar a trabajar, o la disponibilidad de personas formadas para una posible contratación. Después ver que eficacia y eficiencia puedes esperar de ellas.
El montaje que hemos realizado para los desarrollos JAVA sigue la clásica configuración de tres capas: presentación, servicios y persistencia, intentando no atarnos a ninguna tecnología demasiado de la que nos sea imposible prencindir en un momento dado.
La elección de las tecnologías depende de muchos factores que no son solo tecnológicos, como el conocimiento con el que puedes contar en la organización para empezar a trabajar, o la disponibilidad de personas formadas para una posible contratación. Después ver que eficacia y eficiencia puedes esperar de ellas.
- Presentación: Necesitas un framework ágil, en el que se pueda ser eficiente y rápido desarrollando la interfaz. Ese framework no es Struts 1.X., ¿podrá ser Struts 2, o Wicket? Hay muchas opciones en esta capa. Ahora hemos elegido Struts 1.x... jeje, sí, ese que no es ágil y es pesado de desarrollar (muchos xml, clases), por que era donde teníamos mayor conocimiento y experiencia.
- Servicios: Al decidir seguir una arquitectura basada en servicios, debes decidir también como va a ser el acceso a los mismos: EJBs, clases locales, servicios web... La opción que parece que ofrece más flexibilidad es Spring. Permite la utilización de IoC de manera que nos facilita el acceso a los servicios inyectándolos en la capa de presentación, y además tiene utilidades para hacer transparente el cambio de EJBs a clases o viceversa.
- Persistencia: Para proyectos que no requieren de excesivo énfasis en el rendimiento, un framework de persistencia objeto-relacional parece hoy en día la opción más interesante. Aquí vamos con Hibernate.
La evolución de esta arquitectura está clara:
- Migración de Struts 1.x a otro framework, que sea más ágil, ofrezca una velocidad de desarrollo mayor y basado en plantillas que la gente de diseño pueda tocar más fácilmente. Wicket parece una gran opción.
- Eliminación del trabajo manual de modelado de la persistencia. Hibernate Annotations simplifica el trabajo de mantenimiento de la persistencia, pero la automatización del proceso es un objetivo más ambicioso. Estuve probando androMDA, pero la verdad que no lo hice funcionar satisfactoriamente.
- Despliegue automático de las aplicaciones en versiones EJBs o clases locales o servicios web. Una vez que se tiene las clases de implementación de los servicios, un objetivo sería poder desplegar los mismos de manera automática en cualquier plataforma.
Mi Twitter
Para servicios y persistencia yo uso lo mismo que has comentado. Esa elección es lo que los yankis llaman "no brainer".
ResponderEliminarPara presentación ahora mismo creo que lo mejor es JSF, con MyFaces + Tomahawk + Ajax4JSF + RichFaces. Permite hacer interfaces con añadidos Ajax sin demasiado esfuerzo adicional. No está orientado a plantillas ni es el colmo de la productividad, pero su orientación a componentes permite reutilización de verdad.
Ya fuera de la programación en sí, creo que JUnit para programar con orientación a las pruebas es boina. Especialmente cuando un arranque de hibernate + spring es de todo menos rápido.
Y, para temas de automatización de despliegues, una herramienta de integración contínua como Cruise Control o Continuum es muy útil.
Eso sí, no veo la "preparación para el cambio" con la que comenzabas el artículo. Como dentro de un año te canses de Spring y te pases al framework de IoC de Google, por ejemplo, tienes que tirar casi todo lo hecho (aparte de lo que ellos proporcionen, claro). Y me parece bien, porque la forma de prepararse para el cambio suele ser montarse un wrapper por encima de la biblioteca sustituible, y eso siempre es un error.
En mi blog de ingeniería del software estoy comentando a menudo tecnologías en esta línea, por si a alguien le interesa ;)
Hola Nacho,
ResponderEliminar"no brainer", sin duda, son apuestas seguras, que sabes que son eficaces.
JSF no me acaba de convencer, la verdad. No me gusta demasiado el estilo de programación como por eventos en la web, te esconde demasiadas cosas. De todas maneras, siempre digo que me recuerda a Netdynamics, igual es por eso que les tengo algo de manía :)
Sobre la plataforma, utilizamos CruiseControl, con varias construcciones diarias y test basados en JUnit también. Eso lo dejaba para otro post ;)
La preparación para el cambio viene del hecho principalmente de que las capas son independientes, dependiendo únicamente de interfaces entre ellas. Y también de que asumimos que esta arquitectura DEBE evolucionar, así que deberemos formarnos, investigar otras lineas de productos y asimilarlo.
En cuanto a la dependencia de Spring, sin duda es un poco el pegamento que pega las capas, pero estas son bastante independientes del mismo, en cuanto a que funcionalidad requerida del negocio no depende directamente de Spring (o no debería). Quizás los test unitarios es dónde más utilizamos las facilidades que nos proporciona.
Nosotros utilizamos una arquitectura muy parecida, Spring + Hibernate y para la parte cliente hemos empezado a utilizar GWT. Hemos integrado AndroMDA dentro del proceso de desarrollo y la verdad es que nos funciona muy bien.
ResponderEliminaremilio@i2e.com.es
Hola emilio, me encantaríá que nos contases un poco más el proceso con AdroMDA.
ResponderEliminarde acuerdo con hibernate para la persistencia, que dependiendo de la arquitectura y requerimientos de tu sistema se veria la forma de distribuir el trabajo de la base de datos.
ResponderEliminarpara la capa de presentacion, siempre voy por xsl, es cierto que xslt transformation pega en el performance de la aplicacion pero eso se combate con un buen cache tool, ademas xslt te proporciona una enorme ventaja ya que tus objetos tiran xml, un lenguaje que ya todos hablan, ademas piensa en el diseño, el diseño y desarrollo de codigo pueden ir sin ningun problema de la mano, a la par, y es una enorme satisfaccion conectar las capas y saber que la presentacion funciona tal y como se esperaba :-)
saludos desde la tierra del te
Hola Frank!
ResponderEliminarWelcome to Najaraba ;)
Lo del XSLT no veo demasiado bien que facilite la relación con el diseño. Ahí casi me inclino más por un buen sistemas de plantillas, como pueda ser Wicket para el futuro.
Lo bueno de esto es que cada uno puede encontrar la opción que mejor le funcione!! Lo malo es lo que cuesta encontrarla!! :D