Llevaba unos días queriendo escribir esta entrada, pero la cantidad de trabajo que tengo pendiente últimamente me ha hecho retrasarla hasta el Domingo. Todo comienza con un
post en InfoQ donde redactan un resumen (me encantan sus resúmenes) de las diferentes reacciones en la blogosfera al anuncio de
Spring Application Platform.
El caso es dicha noticia en InfoQ generó, como era de esperar, algunos comentarios bastante críticos sobre la plataforma, a los que los líderes detrás de Spring, incluido Rod Johnson, no tardaron en responder, y en esta ocasión de forma bastante dura. Todo ello además originó
un artículo de Adrian Colyer en el blog de Spring, donde explica lo que a su entender son las razones por las que nos deberíamos preocupar por OSGi.
El problema a mi entender de este artículo en concreto es que no nos explica cuáles son los problemas de OSGi. Como decimos aquí, bueno, fair enough, pero todos sabemos que cualquier tecnología tiene sus problemillas, y no explicarlos no deja de hacer que el artículo se convierta en un mero ejercicio de auto-marketing. Pero claro, el problema es que comentar las dos grandes desventajas de OSGi en el contexto de Spring sería un poco duro desde el punto de vista del artículo:
- OSGi, en este contexto de desplegar aplicaciones empresariales, no está regido por ningún estándar ni soportado por otras empresas (por ahora) a parte de SpringSource.
- OSGi, no es algo sencillo. En particular es bastante más complejo que el actual modelo de despliegue de aplicaciones webs en JEE.
Yo empecé a trabajar con Equinox hace ya unos tres años, allá con Eclipse 3.0. No voy a decir que soy un experto, porque no lo soy, pero sí tengo la experiencia de la aplicación de escritorio que viene con
jLibrary, que a fin de cuentas es una aplicación 100% OSGi formada por diferentes bundles. Es decir, el servidor es un bundle, el módulo de caché es un bundle, los módulos de internacionalización son bundles, el módulo de extractores de texto es otro bundle, el interfaz gráfico es un bundle, etc.
No os voy a aburrir con esta historia, pero lo que me dice mi experiencia es que trabajar con OSGi no es algo trivial. De hecho, a mi se me antoja que la forma más sencilla de
desplegar aplicaciones en Spring Application Server, sigue y seguirá siendo el tener ficheros WAR. No me malinterpretéis aquí, no estoy diciendo que me guste OSGi, a mi me encanta la propuesta, y una vez que te acostumbras a él, eres enormemente productivo. Y es mucho más, OSGi está claro que es mucho más avanzado, potente, y modular que el actual modelo de despliegue de JEE.
Pero, lamentablemente OSGi no es tan sencillo. Y aquí, como se comentaba en algunos de los comentarios en InfoQ, se encuentra uno ante el dilema de ¿es mejor elegir un modelo que satisfaga al 10% de los
power-users o un modelo que el resto del 90% de usuarios puedan utilizar?
Otra cosa que no deja de ser curiosa es que desde SpringSource traten de vendernos algunos conceptos como novedosos cuando realmente esos grandes avances ya se llevan viendo con los servidores de aplicaciones propietarios desde hace años. Por ejemplo, comenta Rod Johnson en el artículo mencionado arriba:
I totally agree. The fact that users are essentially deploying half their server to the server in every EAR or WAR file
Bienvenido al mundo de las extensiones propietarias Mr. Johnson. Cualquier servidor de aplicaciones, digamos WebLogic, WebSphere, JBoss o el mismo Tomcat ofrecen formas para compartir librerías. Sí, no son tan sofisticadas como los bundles de OSGi, pero en Tomcat puedes simplemente dejarlas en el shared/lib, o en WebLogic puedes crear una librería compartida y referenciarla después desde tus EARs o WARs o lo que sea. Sí, por supuesto, no es estándar, pero tampoco lo es SpringSource.
Lo mismo lo podríamos decir para la gestión de versiones en ficheros EAR, que se puede hacer por ejemplo en WebLogic 9.x y supongo que quizás en otros, y que desde luego no es tan sofisticada como la que ofrece OSGi, pero al menos se situa en el contexto de JEE que siempre es una ventaja. Nuevamente, el utilizar estas funcionalidades es responsabilidad del equipo técnico del proyecto, pero no creo que sea justo el intentar sugerir que hasta ahora eso no se podía hacer en JEE, porque siempre se ha podido hacer, y exactamente de la misma forma que propone Spring: apartándose del estándar.
En fin, que mi opinión es que por mucho que se intente maquillar, para mi está claro que S2AP es simplemente la consecuencia de la inversión de capital de riesgo, como ya he
comentado en el pasado. No sería tan radical para afirmar que
el emperador está desnudo, porque realmente creo que la propuesta de SpringSource tiene un valor importante, pero sí que creo que es mejor quitarse las ropas de vendedor y decir claramente que todas las tecnologías tienen sus riesgos y sus problemas, y que no siempre es oro todo lo que reluce.
