Ya he sido crítico con EJB 3.1 antes, y aunque como ya he dicho el nuevo TimerService me gusta bastante, lo cierto es que el nuevo empaquetado no me gusta. Ya no es sólo el hecho de cambiar algo que se ha mostrado efectivo durante todo este tiempo sino más bien el transfondo que hay detrás de este cambio, que no es otro que el mismo que hay tras el cambio de hacer las interfaces opcionales: querer abarcar con EJBs todos los escenarios habidos y por haber.
Quizás es que estoy chapado a la antigua, y que vengo de cuando había EJB 1.x, y que casi todo lo que he hecho con EJBs ha sido con EJB 2.x, pero, ¿no hay nadie más por ahí al que esto...
...no le parezca más simple que esto?
En mi opinión la simplicidad no está en el tamaño de los dibujos, si no más bien en su estructura. Y, nuevamente en mi opinión, el meter todo en un sitio sin separar vista y negocio, el mezclar parte web y parte no necesariamente web, el entremezclar recursos utilizados en diferentes partes y permitir su uso indeferente, no son cosas que hagan una solución mucho más simple. Para mi, es justamente al contrario, la propuesta favorece la confusión. Y eso no es simplicidad.
A mi me gusta el modelo de separación en componentes propuesto por EJBs hasta ahora. Como en el caso de las interfaces, me parece una buena y muy recomendable práctica. El nuevo modelo, totalmente anárquico, está claro que apunta hacia desarrollos minimalistas, buscando el exponer EJBs como una tecnología fresca que se puede utilizar para todo. Sin embargo, ya empiezo a ver proyectos con datasources entremezclados y gente preguntándose dónde se ha declarado cada cosa, incompatibilidades entre recursos, proyectos que de pronto hay que separar en contenedor web y servidor de aplicaciones y se paran durante meses porque se diseñaron para ejecutarse como WARs, etc.
En fin, que parece que sigue la tendencia a lightweight EJBs. La verdad es que lo que noto es que cada vez esto le importa menos a la gente. Los que vivimos la época dorada de los EJBs poco a poco vamos dejando el paso a otras personas que no se tragan lo de que hay que usar EJBs por narices. Hay alternativas, y saben utilizar esas alternativas. Por lo tanto, en mi opinión estos cambios poco ayudan y al abrir el abanico de posibilidades están haciendo todavía más complejo el desarrollo y mantenimiento de aplicaciones basadas en EJBs.
Pero bueno, eso y el avance lento de los servidores de aplicaciones en parte debido a ese relevo generacional serían merecedores de otro post.
comments
0 Respuestas a "El nuevo modelo de empaquetado de EJBs"Publicar un comentario