SpringOne 2GX 2010: Review segundo día

El segundo día ha empezado bastante temprano, a las 7:30 teníamos el desayuno y a las 8:30 la primera sesión. La agenda es bastante completa, 8 tracks concurrentes, así que aquí van los resúmenes de las sesiones que hemos atendido:

 What's new in Spring 3.1?
Juergen Hoellen ha empezado haciendo un resumen de las funcionalidades de Spring 3.0: SpringEL, REST, Portlet 2.0, JSR-330, modelo de validación declarativa...Spring 3.0.5 va a ser la última release de la serie 3.0.x (para finales de Octubre), a partir de ahí, nos vamos a encontrar con Spring 3.1. ¿Qué vamos a poder ver en esta release?
- Environment profiles: podremos tener diferentes entornos en nuestra configuración (dev, test, prod) y definir beans para cada uno de ellos. Básicamente nos proporciona una abtracción de entorno, lo bueno es que no vamos a tener que cambiar nada en nuestro artefacto final (como un war, podemos utilizar el mismo war para test y producción), los perfiles se activan externamente, por ejemplo con una propiedad del sistema (-DspringProfiles=dev). Para la configuración, tendremos y la anotación @Profile.
- Cache abstractions: hace más de 5 años que Spring tiene un paquete que se llama cache, pero nunca se llenó...ahora es el momento de llenarlo y se va a enfocar a las caches distribuidas para entornos cloud. Vamos a poder encontrar adaptadores para EhCaches, GemFire, Coherence... y anotaciones que nos van ayudar como @Cacheable y @CacheEvict junto con un namespace para habilitarlas ()
- Conversation management: gestión la conversación actual, HTTPSession++. Vamos a tener mayor control y definir por ejemplo una windows session (una session válida sólo para la ventana actual, si abrimos otra pestaña, va a tener una sessión nueva) o definir explícitamente nuestra conversación. Esto va a ser utilizado también, por Spring Web Flow 3.
- Otros: soporte para Servlet 3.0, soporte para JSF 2.0 mejorado, mayor soporte para Groovy, nuevo namespace c (similar al namespace p, para constuctor injection).

Respeto a fechas y milestiones, vamos a tener dos milesones para Spring 3.1 (M1 para finales de noviembre y M2 a principios de enero), RC1 para febrero y GA para marzo.

Spring 3.2 básicamente intentará integrar todo lo nuevo de Java 7 (JDBC 4.1, fork-join framework para programación multicore y concurrencia) y está programado para finales de 2011.
 

Spring Web Services 2.0

En esta sesión Arjen Poutsma ha presentado Spring Web Services y el modelo contract first. Gran parte de la charla ha sido una demostración de lo que ya teníamos, cómo generamos el contrato a través de un mensaje de ejemplo XML y posteriormente hacemos la implementación con los endpoints.
Referente a la versión 2.0, lo que pretende es ir a la par con Spring 3.0, esto quiere decir actualizar a java 5. A parte de esto, el modelo de programación se asemeja más al de Spring MVC, se han introducido más anotaciones para permitir obtener cosas como: @RequestPayload, @RequestBody, @SoapHeader en los métodos del endpoint. La jerarquía de endpoints que teníamos en la versión 1, queda deprecated en favor al modelo de anotaciones.
Pero una de las características más interesantes son el full streaming y el soporte para tests de integración (para la parte cliente y la parte servidor).

La versión final de Spring WS 2.0 verá luz en diciembre / enero.

Improve the performance of your Spring Application

 Esta presentación se ha centrado en optimizar el rendimiento de nuestras aplicaciones. ¿Cómo? Introduciéndonos al nuevo Spring Cache Abstraction. Antes de todo se ha hecho una introducción al tema de rendimiento (disponibilidad, tiempo de respuesta...), métricas (instrucciones por segundo, consumo de energía, disponibilidad...) y caches (usadas básicamente para reducir acceso a base de datos, invocaciones remotas y operaciones costosas).

Actualmente hay diferentes caches disponibles: EhCache, JBoss Cache, JCS, OSCache, JCache.. y diferentes data grids: GemFire, Gigaspaces, GridGain, Terracotta, Oracle Coherence, lo que intenta Spring Cache Abstraction es proporcionar un mínimo denominador común para acceder muchos de ellos, una abtracción similar a la que tenemos en el acceso a datos  y con una aproximación como la de transacciones (anotaciones + AOP). Algunas de las anotaciones y sus usos:

@Cacheable(condition="nam.length < 10")
@CacheEvict(name="owners", allEntries=true)

También contamos con un nuevo namespace cache para la configuración en XML.

Lo importante cuando utilizamos estas caches es conocer a nuestros datos, estas abstracciones funcionan como una caja negra, situación que hace difícil gestionar duplicados y relaciones entre datos (puede que tengamos que interactuar con el proveedor directamente para tener un mayor rendimiento). Otra cosa a tener en cuenta es que las caches funcionan de maravilla si consultamos por la key, pero cuando hacemos queries basados en los valores de la cache perdemos todo el rendimiento. Una cache puede ser a veces decepcionante, los misses de una cache son caros, así que siempre se tiene que considerar la situación, los datos que tenemos y como los utilizamos.

Otra solución es usar un data grid como GemFire. Un data grid nos va a permitir tener una cantidad de datos importante y a la vez tener rendimiento y escalabilidad (pudiendo replicar datos entre nodos, distribuirlos para escalabilidad horizontal...). Aquí nos mostraron los el proyecto Spring GemFire y la configuración a través de su namespace. ej:

When is garbage not garbage? Using Ehcache to overcome the JVM's limitations

Personalmente me encantó esta charla. El CTO de Terracota, Ari Zilka, nos dió una clase de una de las asignaturas pendientes de muchos desarrolladores Java: la gestión de memoria. Para ello, nos puso un caso práctico de una aplicación donde se creaban muchos objetos. El problema era evidente, el garbage collector paraba la aplicación a menudo para hacer su función con lo que el rendimiento de esta era muy pobre. ¿Cuál fué la primer solución? Utilizar el garbage collector en paralelo (flag -XX:-UseParallelOldGC), esta solución no fue suficiente, así que se cambiaron al colector ConcurrentMarkSweep e implementaron todo el código sin locks, tampoco tuvieron éxito.

El problema es la complejidad de todos estos temas. Hacer código sin locks requiere experiencia (atomicidad, read repair...) y el tuning del GB es muy sensible, cada vez que cambiamos el código tenemos que reajustar los parámetros. 

Como alternativa se presentó BigMemory, lo que hace principalmente es esconder la el contenido EhCache del GB, de esta manera nos evitamos las paradas del GB y para ello tiene propia gestión de memoria. Acabaremos teniendo el heap, el off-heap (gestionado por BigMemory) y el disco (usado por BigMemory para persistir)

En la demo que nos hizo, pudimos ver como una aplicación tenia 200mb de heap, pero como proceso consumia 2Gb debido a la gestión de BigMemory.

What's new in Spring Integration 2.0?

En esta charla se presentaron las novedades de Spring Integration 2.0. Ahora, igual que en todos los nuevos proyectos del portfolio de Spring, SI 2.0 utiliza el Spring Expression Language (se puede utilizar dentro de los transformes, routers...). Además utiliza los nuevos ConversionService, para hacer conversiones automáticas entre objetos, los mismos que podríamos utilizar en la capa web por ejemplo. Los adaptadores HTTP ahora utilizan el RestTemplate internamente. Estas funcionalidades, básicamente se adaptan a los que es Spring 3.0.

También encontraremos un nuevo adaptador para XMPP y evolución de los adaptadores para JDBC, JMX, TCP/UDP, RSS, FTP, Twitter. Nuevos patrones que podremos encontrar: message history, message store, claim check y control bus. Soporte también para Spring Roo.

Una de las caracteristicas que ahora viene con el STS (2.5), es el soporte visual para Spring Integration, muy útil para ver nuestro flujo.

Para acabar, nos hicieron una demo utilizando el nuevo adaptador para XMPP. A través de GTalk y proporcionando un código postal, el sistema obtenía los datos meteorológicos y de trafico y lo enviaba por correo electrónico, por twitter... Podéis encontrar todas las demos aquí: http://git.springsource.org/s2gx-2010/spring-integration

 Grails 1.3
En esta charla Graeme Rocher habló un poco sobre lo nuevo en Grails 1.3 pero sobre todo lo que han cambiado para la siguiente versión: 1.3.5. En la charla estaba también Peter Leadbrook, otro commiter del proyecto que intervino bastante en el transcurso de la sesión.

La sesión inició mostrando el soporte mejorado a Grails en la nueva versión de STS. Ya está bastante pulido y causó muy buenas impresiones. Graeme mencionó que en esta versión han seguido mejorando el performance y como ejemplo mencionó como han arreglado el tema de la compilación de los GSP que tomaba demasiado tiempo y ha menudo terminaba con problemas de falta de memoria PermGem poniendo una tarea de compilación que precompila estos archivos para que en runtime ya no ocurra.

Otros temas que trató fueron que ahora puedes declarar las dependencias de tu proyecto en el fichero BuildConfig usando sintaxis de Gradle, algo bastante interesante. Incluso puedes declarar los plugins que estás usando, para que no se tengan que conseguir a través del comando grails install-plugin: ya está centralizada la gestión en el archivo de configuración. Incluso puedes especificar que ciertas dependencias de un plugin no se instalen (por ejemplo, quitar ehcache de las dependencias de Hibernate si no lo vas usar).


De lo nuevo, lo que causó más expectativa es el soporte a NoSQL con GORM. Ahora GORM también es una abstracción sobre varios datastores NoSQL (Redis, Cassandra, GemFire, MongoDB, etc) que permite al programador usarlos en sus aplicaciones de una forma bastante consistente a lo que venía haciendo con GORM para Hibernate. De esta forma, puedes usar los finders, namedqueries, constraints que ya se usaban pero ahora con bases de datos NoSQL.

Entre otros cambios, se cambio totalmente el JSONBuilder para que sea más amigable y con una sintaxis más cercana a Json, se anunció un plugin para Flex y para VMForce.

La sesión fue muy interactiva porque los programadores que estaban ahí en su mayoría tenían ya aplicaciones en producción con Grails, por lo que hacían muchas preguntas y sugerencias sobre los nuevos features. Graeme aprovechó para mencionar algunas features que ya están en la 1.3 pero no funcionan muy bien y están arreglándolas para la 1.3.5.

Esta versión será estable antes de fin de año. En la 2.0 -que saldrá en algún momento del próximo año- vendrán muchos cambios. De entrada se cambiará el build system para usar Gradle, cambio que mencionaron será lo más complicado de esta versión. Además se migrará a las últimas versiones estables de las dependencias: Groovy, 1.8, Spring 3.1, Hibernate 3.6. Se cambiará además el sistema de recarga en caliente del contexto que ahora está basado en recargar el classloader de la aplicación lo que lo hace muy ineficiente a uno basado en agentes java (usando el proyecto Continuous Deployment).

También se anunciaron varios nuevos features para GORM producto de las peticiones de los usuarios. Migrations, ingeniería en reversa de bases de datos existentes, abstract inheritance.

Todos estos cambios ocasionarán que Grails 2.0 no sea compatible hacía atrás con la 1.x. De hecho, lo más seguro es que ni siquiera habrá un comando en la 1.3.5 para actualizar a la 2.0

En esta sesión y a lo largo de lo que se ha visto en la SpringOne, Grails goza de una gran salud, una gran comunidad de usuarios y SpringSource está apoyando mucho al proyecto. De hecho a diferencia de lo que ha pasado durante este año, se ha hablado más de Grails que de Spring Roo.

Keynote

Después de cenar (por cierto, muy buena comida durante toda la conferencia), Adrian Colyer, se encargó de la keynote, básicamente haciendo un resumen de todo lo nuevo que habíamos visto.

Aprovechando la keynote, se entregaron los Springy Awards:
- El producto más innovador: Gradle
- Community champion: Manuel Jordan Elera, de la Univesidad Católica de Santa María en Perú con más de 1600 posts en el foro de Spring.
- Mejor aplicación:Inkchaser, una aplicación realizada en Grails en sólo 45 días.