Hoy me parece que hay más de uno con dolor de cabeza de las cervezas belgas de ayer, pero parece que la gran mayoría de miembros de SpringSource están ahí...o falta alguien? Bueno, empieza la keynote por parte de Adrian Colyer (CTO de SpringSource) y como no, después que todo el mundo le preguntase por el pato del año pasado, dice que desgraciadamente no ha podido venir pero que tendremos otro invitado, así que entra Rob Harrop en escena.
Se preguntan que después de desarrollar un framework que es un estándar por defacto se van a quedar ahí. Spring nos ofrece poder modularizar una gran aplicación, pero cuando desplegamos nuestra aplicación todos estos módulos desaparecen, convirtiéndose en un simple WAR, por lo que la modularidad desaparece. Aquí es cuando entra en juego OSGi y SpringSource ApplicationPlatform.
La única estrella de hoy, es sin duda SpringSource Application Platform, así que voy a hacer un resumen global de la keynote, y las siguientes tres presentaciones (ya que se pisaban unas con otras; frases como "oye Sam, esto lo has explicado en tu presentación?" era frecuentes :P)
Introduction to the SpringSource Application Platform por Andy Wilkinson
Building Web Applications with the SpringSource Application Platform por Sam Brannen
Inside SpringSource Application Platform por Rob Harrop
El SpringSource Application Platform es un servidor de aplicaciones completamente basado en módulos para Java. Se sustenta en lo que le llaman SpringSource Dynamic Module Kernel que proporciona un backbone basado en módulos para el servidor, este kernel esta basado en Eclipse Equinox, extendiendo su control de módulos y versiones. Utiliza Tomcat por debajo. No hace falta decir que todo el sistema se basa en OSGi.
Se comentan las modificaciones y extensiones que han realizado en Equinox, como por ejemplo la super difícil tarea de hacer Equinox thread-safe y las propiedades Import-Library / Import-Bundle del Manifest OSGi. Este kernel se encarga básicamente de la concurrencia, IO, configuración (curiosamente la configuración se hace con JSON en vez de XML) y gestión de perfiles (los perfiles definen los subsistemas de una instancia concreta; por ahora solo esta definido el perfil web, pero más adelante tendremos por ejemplo el perfil webservice; se pueden definir perfiles personales también).
Durante las tres sesiones se han realizado bastantes demostraciones para aclarar todo el funcionamiento
Deplegar aplicaciones, cuales y como
Podemos desplegar cualquier tipo de aplicaciones:
un bundle OSGi: se puede tratar de una librería stand-alone expuesta como módulo del sistema (imaginemos el módulo de Hibernate) o cualquier servicio que queramos publicar globalmente en el contenedor OSGi;
Platform Archive (PAR): es el formato para empaquetar los módulos de un sistema, realmente es un JAR y lo podemos comparar con los EAR pero en el contexto de un contenedor OSGi, con el beneficio de poder actualizar cada módulo dentro del PAR independientemente; y finalmente una aplicación web clásica:
WAR: realmente lo que hace es transformar el WAR en un módulo OSGi internamente.
Se hicieron diferentes demos de despliegue de una misma aplicación en las versiones: un WAR simple, un WAR con dependencias compartidas como módulos, un WAR con servicios y dependencias compartidas y un módulo web (PAR).
Para realizar el despliegue de una aplicación se puede hacer en caliente, simplemente copiando la aplicación en el directorio pickup del servidor o bien a través de la consola de administración (tiene un campo para subir la aplicación y se encarga de desplegarla)
Serviceability
Han separado lo que es el trace de los logs. El trace es una información muy detallada de todo lo que pasa al sistema que se encuentra en serviceability/trace. Los logs son realmente mensajes breves preparados para diagnosticar y ver el estado de la plataforma (sin tener que navegar entre gigas y gigas de logs, para eso existen los archivos de trace), una línea de log tiene esta pinta:
[2008-06-13 17:28:59.096] fs-watcher Creating web application '/admin'.
Si nos fijamos, cada línea tiene un código dónde la última I expresa que es un mensaje de información, podemos encontrar W de warning o E de error.
Lo bueno es que se crean archivos de trace para cada aplicación independiente.
Otra buena funcionalidad son los dumps, que son capturas del estado de la plataforma en un momento concreto, y se hacen automáticamente cuando se identifica un fallo o cuando se encuentra un thread dead-lock. En los dumps podemos encontrar por ejemplo el stack de thread que están corriendo con todo su estado. Todo el dump esta en formato JSON.
Una cosa que me hizo gracia es el mensaje que genera cuando compilamos y nos da un ClassNotFoundException (han redefinido la clase) que nos muestra un: Did you mean? com.clase, al estilo de google
Classloading
El clásico class loading se basa en un modelo de delegación lineal jerárquica (parental), donde una clase es cargada por solo un ClassLoader (no existe el versionado). OSGi tiene un sistema más complejo de classloading, que es lo que permite el versionado, la modularidad y el todo el sistema dinámico.
Cada módulo OSGi tiene su propio ClassLoader y extiende el modelo parent first delegation con su modelo networked delegation. Esto supone que para cargar una clase se puede hacer de dos maneras: del ClassLoader padre o del ClassLoader de otro bundle (módulo). Como se determina? Con las reglas de delegación de la especificación OSGi. Básicamente, se especifica que todas la clases java.* se cargan a través del ClassLoader padre y todas las otras a través de los ClassLoaders de los otros bundles (un bundle solo mira los classloaders de los bundles de los que depende).
Estas reglas se pueden modificar para obtener otros comportamientos.
Con este pequeño resumen os quería preguntar si encontrais interesante que se hiciese alguna ponencia / sesión de OSGi y el SpringSource Application Platform al estilo de lo que se hizo en SpringOne, durante el OpenJavaDay de la semana que viene. Quien se apuntaría y lo encuentra interesante? Espero vuestras opiniones!
jueves, junio 19, 2008 at 6:12PM 