El stack de Amneris ha sufrido grandes cambios en los últimos meses. Tenemos 3 nuevas incorporaciones, 2 jubilaciones, y un retiro por invalidez :)

En primer lugar damos la bienvenida oficial a Tapestry5 que si bien ya hacia tiempo que estaba dando vueltas por los alrededores, no había sido debidamente presentado. La adopción de Tapestry5 deja a Tapestry4 relegado al mantenimiento de aplicaciones legacy.

De la misma manera que Tapestry4, se retira con honores Trails 1.x, que ya ha cumplido su ciclo, para dejar paso al todavía en desarrollo Trails 2 basado en Tapestry5. Trails 2 está todavía muy lejos de ofrecer todas las prestaciones que ofrece se hermano menor, pero no tiene sentido seguir invirtiendo tiempo en Trails 1 cuando el framework principal en el que se basa está ya completamente obsoleto. Esto conlleva también el esfuerzo de ir migrando de a poco todos nuestros otros frameworks y librerías que se basaban en Trails.

La incorporación de Tapestry5 al stack desplaza también a Spring como framework de IoC por defecto del stack. Spring (a mi parecer) a dejado de innovar en el espacio de la IoC y en estos momentos hay ofertas muchísimo más interesantes como Guice y Tapestry5 IoC. La cantidad de código basado en Spring IoC que tenemos es tal que reemplazarlo no será tarea fácil, pero de ahora en adelante Spring no será la primer alternativa a la hora de implementar IoC en nuestras aplicaciones. Trails2 será completamente independiente de Spring. Completamente compatible SI, pero independiente al fin.

Ya he mencionado la incorporación de Tapestry5 y Trails2 pero el gran fichaje de la temporada es Magnolia CMS. Trails nos estaba quedando un poco chico para según que cosas y necesitábamos incorporar una solución robusta que nos garantizara estabilidad pero con flexibilidad. Magnolia se usa detrás de los sitios de InfoQ y JBoss.org, así que si puede con la carga de esos dos sitios, podrá manejar nuestra carga sin ningún inconveniente. Otra gran característica de Magnolia es la implementación de Java Content Repository (JCR - JSR-170) que nos da una gran tranquilidad respecto de que nuestros datos son almacenados siguiendo un estándar abierto para la gestión de contenido.

Bienvenidos Magnolia, Tapestry5 y Trails 2!

Existen ciertos falsos mitos sobre la performance de jBPM. Estos mitos informáticos pueden hacer que un cliente descarte una tecnología sin siquiera haber tenido una evaluación real de los beneficios de su uso. Joram Barrez ha salido, como los cazadores de mitos, a refutar la fama de mala performance de jBPM con una muy interesante presentación: Some real-life jBPM action: PoC jBPM Orchestration. Esta presentación ha causado una muy buena impresión en el mismísimo creador de jBPM y ha dado pie a una interesante discusión en el blog de Tom Bayens y a un nuevo post de Joram, con un benchmark más exhaustivo: Short jBPM Performance Showdown

Entre las optimizaciones que menciona Joram destacan:

• Deshabilitar el logging a JBPM_LOG
  

jBPM tiene por defecto muchísimo logging. Simplemente deshabilitando el servicio de logging de jBPM permitió ejecutar 250.000 procesos más en una hora, eso significa que los procesos se ejecutan 3 veces más rápido que con el logging habilitado.
• configurar Log4j a nivel ERROR
  

y así reducir aún más las entradas de los logs.
• poner la propiedad "show_sql" en false.

Con esta propiedad configurada en true, Hibernate imprime en los logs TODAS sus queries SQL.
• Según Joram la mejor ayuda a la performance de jBPM es configurar correctamente la cache de Hibernate.
  

jBPM ejecuta una gran cantidad de queries, y muchas de ellas pueden ser cacheadas sin ningún problema. El 90% del tiempo jBPM está haciendo tareas de Hibernate.

Por supuesto que todo esto es solo para cuando se quiere exprimir al máximo hasta el último ciclo del procesador. Porque en mi opinión, para el uso estándar de jBPM la configuración por defecto es lo suficientemente buena.