Aunque quizás suene a excusa, he estado muy liado… En serio, he estado inmerso en preparar la migración de un proyecto que usa JPA, JAX-WS, JAXB, etc. a integración continua. Ya os contaré a partir del lunes algunas de las buenas prácticas que estoy extrayendo de esto, pero sí os puedo adelantar que tengo un CruiseControl 2.7 (con una consola mejorada, aunque no del todo conseguida) llamando a varios proyectos que se construyen con Maven 2, por supuesto lanzando los tests unitarios e incluso despliegando los correspondientes EAR en un Glassfish usando el plugin antrun. Y aunque algunos puedan pensar que es una simpleza, no lo es tanto cuando debes pensar en que el diseño del procedimiento y todo lo que le rodea (incluyendo la organización del repositorio, la configuración en el SVN, etc.) debe escalar (y mucho) porque en un futuro no muy lejano tendremos cientos de proyectos como éste en marcha…
Pero lo prometido es deuda… y voy a tratar de hacer un “resumen muy resumido” de aquellas notas sobre la sesión con Mr. Pelegrí (que algunos afortunados habrán ya podido atender en primera persona en el Java Symposium).
Eduard nos comenzó contando cómo se han unido los equipos que desarrollaban el viejo iPlanet (con sus diversas denominaciones) y otros que venían de proyectos en comunidades como Apache y que habían confluido en la construcción de la implementación de referencia de Java EE (es decir, de Glassfish). Los del primero actualmente se dedican sobre todo a la consola y, si no entendí mal, a todo lo relacionado con alta disponibilidad), mientras que los del segundo, lógicamente, se dedican a lo que es Glassfish en sí (implementación de Java EE).
En cuanto a las versiones aclaró lo siguiente:
- GF v1 = 9.0 Platform Edition
- GF v2 = 9.1 (Ya no hay editions sino profiles, e.d. el administrador decide qué características están disponibles en la instancia correspondiente). En esta versión se incluye:
- nuevo stack de WS (incluido WSIT para interoperabilidad con WS de .NET)
- mejoras en el rendimiento, el tiempo de arranque…
- balanceo de carga, clustering, failover…
- GF v3 = Modularización
Glassfish v2
Durante esta sesión, Eduard se centró especialmente en Glassfish v2 (que aún está en “beta” pero falta muy poco para su versión final).
En cuanto al “failover” y la alta disponibilidad, explicó que lo están implementando con HADB y replicación de memoria. Aconsejó que, en general, consideremos la alternativa de la replicación de memoria porque es una solución más fácilmente manejable (casi coste de configuración cero) y da un rendimiento más que aceptable. Usar HADB es una solución más compleja y en la mayoría de las situaciones más costosa de lo realmente necesario. (Permitidme que no entre en este tema en mayor profundidad porque yo ahí me pierdo bastante y creo que es mejor no hablar de aquello que no se conoce bien).
Alguien le pidió una comparativa entre GF v2 y JBoss (para una configuración en cluster) y dijo que aunque no la tenía la trataría de encontrar. Si alguien tiene interés en ella, creo que lo mejor sería que la pidiera en el foro.
En cuanto a todo lo relacionado con WebServices… después de que nos enseñara una comparativa entre GF v2 y Axis2 en la que, claro está, GF era bastante superior… Perdonad la suspicacia, pero no me suelo creer demasiado las comparativas, sobre todo cuando me dicen que XFire es una mejor implementación que Axis2 (si es así, ¿por qué no comparar GF con XFire?) Explicó que el xml pull-parser Woodstox tiene bastante que ver con esto.
Bueno, yo le pregunté (me gané una camiseta) por su opinión sobre SCA y los planes de Glassfish respecto a esta iniciativa. Me dijo que, en su opinión, JBI y SCA quizás terminarán convergiendo porque los unos y los otros están tomando ideas entre ellos. En cualquier caso, lógicamente, Glassfish está apostando ahora por JBI como mecanismo para hacer que los servicios colaboren entre sí. En este sentido le pregunté sobre Java CAPS pero, al no ser él un experto en esto, tampoco me pudo decirme mucho…
También nos habló de Metro, que es un “bundle” de frameworks que usa Glassfish v2 para implementar el stack de WebServices, pero también se podrían usar con Tomcat, Jetty…
En cuanto al web tier de GF v2, Eduard nos habló de JSR 199 (que son JSPs que se compilan al vuelo, sin persistir en fichero), de mejoras en el protocolo AJP (de Apache), un “non-blocking SSL”, lo último en JSF… ¡Ah! Y Grizzly, claro. Por cierto, que nos contó que Grizzly se convirtió (a partir de la versión 1.5) en un framework de programación de java.nio (en una API) porque es muy fácil cometer errores.
Alguien presente le preguntó sobre seguridad y el Security Manager y él explicó que a partir de la 9.0 decidieron permitir que se usaran frameworks o productos (como Struts) que entran en conflicto con el Security Manager y que esa es la razón por la que está apagado por defecto.
Glassfish v3
A continuación, Eduard pasó a adelantarnos algunas de las características de Glassfish v3 (del que ya está disponible una “technology preview”).
El arranque en v3 será sustancialmente más rápido porque van a refactorizar para tener un núcleo (HK2) más módulos y contenedores/servicios, donde un servicio podrá ser p.ej. un motor JBI. Esto permitirá tener servidores más livianos, p.ej. para hacer plataformas de juegos “massive scale” (tipo “warcraft”).
GF v3 saldrá antes que Java SE 7, y parece ser que para este último no han decidido aún cómo implementar los módulos (si adoptan OSGi o no). Mi compañero Sixto Cantolla le preguntó por cómo afectaría esta decisión de Java SE 7 a GF v3 y Eduard nos explicó que ellos habían desacoplado hasta donde afecta (el “modules subsystem“) y que el resto era “agnóstico”.
Quizás haya una versión “Early Access” de v3 antes de fin de año, pero se espera que la versión definitiva estará para Java EE 6.
A continuación nos hizo un resumen de algunos proyectos de la comunidad Glassfish que más peso están tomando (algunos se incorporan a GF v2 y v3):
- JSFTemplating (que se está usando en la consola)
- Woodstock (componentes JSF)
- Open MQ (una implementación de JMS “enterprise quality”)
- Hudson (un servidor de integración continua)
- jMaki (permite usar diferentes librerías Javascript a la vez, especialmente útil para aplicaciones Ajax)
- Rome (RSS)
- WADL (escribe interfaces REST)
- y muchos más…
La última pregunta fue acerca de la elección del nombre “Glassfish” para el proyecto:
Cuando se creó el proyecto, se puso el foco en la transparencia, como la de uno de esos peces de cristal (glassfish en inglés).
Ruego a aquellos que estuvieron presentes en la sesión disculpéis tanto mis lagunas de memoria como aquellas incorrecciones técnicas que haya podido cometer. La solución es fácil: pulsad en el enlace “escribir un comentario”. 🙂
Muchas gracias.