El falso Santo Grial de J2EE y la nueva esperanza JEE

Con visión retrospectiva podemos ver que muchas de las bases sobre las que se sustentaba J2EE fueron un error.

En los primeros días de J2EE, los xmls eran vistos como el Santo Grial de la configuración, el framework estaba pensado para que todo se pudiera y tuviese que configurar en un xml, incluyendo nombres de clases java y métodos. Esta técnica que sobre el papel parecía ideal para ayudar al desacoplamiento del sistemas tenía consecuencias nefastas en el desarrollo.

La configuración en ficheros xml resultó ser muy repetitiva, propensa a errores (muy difíciles de encontrar en tiempo de ejecución) y en definitiva demasiado compleja para el programador medio.

Ahora, mirando hacia atrás podemos ver que no solo el propio J2EE, sino también otros frameworks como Hibernate, Struts, Spring, iBatis, etc… cometieron el mismo error, y poco a poco la plataforma Java se ha ido haciendo cada vez más y más compleja, hasta ser considerada por algunos como un dinosaurio inmanejable, con una dura curva de aprendizaje.

Esta situación, conocida como “El infierno XML“, la han aprovechado muy bien otros lenguajes como Ruby on Rails con su lema programación por convención, que precisamente evita la trampa en la que cayó J2EE.

Por suerte la comunidad Java ha reconocido el problema del abuso de XMLs y ha actuado remplazando parcialmente los ficheros XML con una mezcla de anotaciones en el código y convenciones establecidas que sólo requieren la configuración de los casos excepcionales.

Como respuesta a estos y otros problemas, han empezado a aparecer algunas soluciones como por ejemplo:

* EJB3/JPA: Que simplifica dramáticamente el engorro que actualmente suponía trabajar con EJBs 2.0 o Hibernate y que desde hace un año forma parte de todas nuestras aplicaciones con unos resultados excelentes.

* Seam: Un framework ligero para Java EE 5.0 que simplifica el desarrollo de aplicaciones web y que despues de algunos proyectos internos, se convierte este año 2008 en nuestro framework base para todos nuestros nuevos proyectos web.

* Web Beans (JSR 299): La gran esperanza que parte del camino iniciado por Seam y que pretende convertirse, al igual que ya pasó con JPA, en el estándar para comunicar la capa web con los EJBs.

* Grails: Que ha resultado muy ilusionate en las pruebas y quizás en el futuro se convierta tambien en compañero de viaje.

* JAX-WS 2.x: Que simplifica enormemente tanto la publicación como el consumo de Servicios Web. Después de años utilizando Axis, JAX-WS pasa a convertirse en nuestra pila Web services preferida.

En definitiva, aunque los XMLs seguiran siendo parte esencial de nuestro día a día, un nuevo camino se abre en los paradigmas de programación Java, …

Comentarios

  1. Ando desfasado, ¿podría alguien aclararme por qué son tan malos los XMLs? simplifican el hacer código y evitan recompilar. No hay nada como hacer una aplicación con Spring.

  2. En cualquier caso es solo una opinión, pero claro que los XMLs no son tan malos, de hecho son una maravilla, los xml/xslts/xhtml/etc… siguen y seguirán siendo muy utilizados, y nosotros por supuesto que los utilizamos para la configuración, plantillas, etc. Lo que esta cambiando es filosofía “XMLs para todo”, todas las plataformas, incluido Spring en su nueva versión, están reconduciendo su camino hacia la convención, las anotaciones y la simplicidad. Larga vida al XML, y bienvenida la nueva filosofía tipo “Java on Rails”.

  3. Muy interesante perspectiva sobre el uso de los xml habra que observar como se mueven las tendencias, definitivamente los xml simplifican mucho la vida en algunas cosas pero su “abuso” puede llegar a ser muy complicado

  4. ¿Comparás “el engorro” de trabajar con EJB 2.x a trabajar con Hibernate? Creo que ambas cosas están en dos planos increiblemente distinto.

  5. Hola Claudio,
    Tienes razón, están en dos planos muy distintos, y esto es solo una opinión personal, en mis inicio tuve que sufrir EJB CMP 1.0 y 2.0, y el cambio a Hibernate digamos que mejoro mi calidad de Vida. Y eso mismo es lo que he sentido al dar el salto desde Hibernate core a la especificación JPA (implementación también de Hibernate)

  6. Ja, si por eso me refería. Quizás tenías alguna queja particular al uso de hibernate que podía llegar a hacerlo tan tedioso como programar Entity Beans en EJB 2.x.
    En mi opinion el uso de Annotations para proveer al fwk de la metadata requerida para persistir es una excelente idea. Al fin y al cabo:
    1. los mappeos siempre estaban acoplados a la estructura de las clases.
    2. el requerimiento de “cambiar los mapeos sin cambiar el código” es uno de los requerimientos más fantasmas que he visto (no solo que nunca aparece, sino que nunca pero nunca de los nuncas harías un cambio de ese estilo ‘en caliente’ en un ambiente productivo sin antes pasar por un ambiente de testing en donde, al no ser productivo, tranquilamente podés re compilar. Y vamos. La compilación en java desde hace años que no tarda nada).

    En cuanto a trabajar con el EntityManager de la JPA (en lugar de con la Session de hibernate) todavía no le he visto mucho provecho.

    Saludos, Claudio

  7. Buen día, me parece que el enfoque hacia las anotaciones es bastante bueno porque todo se maneja en la clase y no hay que preocuparse por varias cosas sobre lo mismo. Solo tengo que añadir que aun no logro comprender si en EJB3 aún se puede lograr el efecto BMP y si los entity siempre estan consultado de la base de datos como sucedia en EJB2 CPM o solo cuando se hace explicitamente.

    Gracias.

  8. Pingback: Java y el Infierno XML

Comments are closed.