Bipunto..

sábado enero 15, 2005

Los frameworks rebeldes de Java

Me ha llamado la atención un artículo en InfoWorld del pasado diciembre en el que se comenta el informe de Burton Group Los proyectos opensource pueden ser una alternativa o suplir a las tecnologías J2EE, en el que se expone que los frameworks para el desarrollo en Java, por su mayor facilidad de aprender, utilizar y 'testear' que las tecnología homólogas de J2EE, suponen un riesgo de bloqueo por parte del opensource similar al que pueden provoca los productos propietarios.

En dicho artículo por frameworks rebeldes se identifica a aquellos productos opensource, con modelos de programación y API's que no siguen los estándares del JCP y que se muestran como alternativas o reemplazos del J2EE, compitiendo y limitando su expansión.

Abordando tres tipos de frameworks: los frameworks web (como Struts, Tapestry y Velocity), los de persistencia (como Hibernate, iBATIS y Castor) y los contenedores ligeros (como Spring, HiveMind y PicoContainer) se puede considerar que de cada tipo existe un estandar de facto (Struts, Hibernate y Spring) que rivalizan con sus homólogos (JSP/JSF, CMP/JDO y EJB propiamente dicho) creados bajo el amparo del JCP. De hecho, Burton pone de manifiesto que cuanto más crece la popularidad de estos frameworks rebeldes los desarrolladores son más reacios a utilizar los "oficiales".

Sin embargo, los servidores opensource como JBoss, Geronimo y JonAss no los consideran como "Rebeldes" al ser implementaciones de la especificación J2EE y por contra sí contribuyen a la expansión de dicha tecnología, al ponerla al alcanze de cualquiera.

También dejan de manifiesto que los desarrolladores pueden quedar tan cautivos y dependientes de una solución opensource como de cualquier otra propietaria, mencionando el disuelto Avalon de la ASF. Aunque destacan que el hecho de que estén las fuentes disponibles, permite, al menos en teoría, retomar el proyecto o realizar un fork.

Finalmente parece que queda claro que los proyectos opensource tienden a ser más dinámicos, productivos e innovadores, y que sus buenas ideas pueden acabar contribuyendo y recogiendose en el JCP. Casos como Hibernate que ha influido tanto en el nuevo JDO como en el EJB3; las influencias de Struts en el JSF o las que hacen derivar EJB hacia algo más ligero sin tanto callback.

La conclusión final, es la esperada. Todo es bueno si se sabe utilizar adecuadamente y con precaución.

Desde mi punto de vista, la multitud de implementaciones de software, tanto de middleware y frameworks, como de aplicaciones finales, que no se desarrollan con las tecnologías oficiales, pone en tela de juicio si estas últimas son todo lo buenas que deberían de ser. Quizás el problema venga únicamente de que no se entienden o que no se han sabido explicar, de mala comunicación, de excesivo dinamismo de la comunidad de desarrolladores, de su inquietud, puede que incluso de un carácter rebelde o una acusada inconformidad.

Comparando la plataforma Java con .Net aquí se ve claramente las diferencias de los dos mundos. Hasta donde he podido constatar, los desarrolladores de .Net son mucho más fieles (puede que dóciles o cómodos) a seguir las doctrinas oficiales. Además, la existencia del megaportal del desarrollador (léase MSDN), y la fuerte tutela que Micro$oft ejerce sobre su comunidad de desarrolladores transmitiendo la idea de que "no te preocupes, nosotros te ofrecemos todo lo que necesitas" hacen que, si bien el número de software final sea muy elevado, en relación, el número de librerías, API`s y de middleware, con significativa aceptación, sean comparativamente minoritario.
El ejemplo contundente es el de los IDEs. Para Java el mercado está muy diversificado, mientras que en .Net existe predominantemente "EL" IDE. Otro ejemplo es el de las bases de datos, ocupado fundamentalmente por SQLServer/MSDE, sobre todo cuando descendemos de los entornos corporativos en los que Oracle tiene la última palabra.

Y para acabar, ilustrar con el ejemplo gráfico que obtenemos al comparar TheServerside.com con TheServerside.net. Contando las empresas que se citan en uno y otro, o agrupando los productos por la empresa que los desarrollan vemos que la omnipresencia de Micro$oft acaba haciendo TSS.net prácticamente monotemático.

En fin, al igual que en la plataforma Java el ecosistema siempre estará formado por productos amparados en el JCP y otros, de importante relevancia, que inicialmente no lo están, esta plataforma ha de convivir con .Net y aprender ha "interoperar" con ella, pero eso es parte de otra historia..