En el CexC utilizamos tecnologías Java Enterprise Edition para el desarrollo de aplicaciones web de gestión. Nuestro equipo lleva años trabajando con estas herramientas, y ha vivido la evolución que esta pila empresarial ha sufrido. De hecho seguimos trabajando en el mantenimiento de aplicaciones que algunos clientes tienen implementadas con lo que hoy en día parecen planteamientos obsoletos, como SQL embebido en JSPs, mientras que la mayor parte de los desarrolladores trabajamos con, literalmente, lo más reciente que nos podamos permitir en función de las necesidades.

Como framework principal utilizamos Seam, manteniendo Hibernate como motor de persistencia. Una de las necesidades que suele ser necesario cubrir es la auditoría de los cambios en los datos. A veces, por uno u otro motivo, es necesario mantener un versionado de los datos (o, al menos, de algunos de ellos), de forma que podamos conocer todas las modificaciones que han sufrido. Hay varias maneras para implementar esto: triggers en bases de datos, filtros en Hibernate, código específico... todas con sus ventajas e inconvenientes. Si hace un par de años hubiese escrito mi lista de los deseos sobre qué debería tener una solución de auditoría de datos para la plataforma que venía utilizando (esencialmente Hibernate + Oracle) habría dicho algo semejante a lo siguiente:

• Esfuerzo mínimo por parte del desarrollador (por supuesto :) ).
• Registro de todos los cambios deseados, incluyendo usuario actual (ojo, usuario final, no de base de datos).
• Facilidad para consultar y recuperar versiones previas.
• Separación entre los datos actuales y los previos (no quiero mantener en la misma tabla todo lo demás).

Por aquel entonces la solución por la que optamos fue programar filtros de Hibernate. Es la opción sugerida (aunque no implementada "de serie") en la documentación oficial, y en un wiki se hacía una propuesta. Sin embargo, estaba lejos de ser óptima. El código era complejo y problemático, y no disponíamos de la flexibilidad deseada.

A veces la vida te da sorpresas, y en una de las periódicas visitas que realizamos a jboss.org nos encontramos con una joya en ciernes: Envers. Es, literalmente, una librería de auditoría para Hibernate, ampliando las posibilidades de este último, de forma semejante a como hacen Annotations o Validator. Permite definir la auditoría de las entidades mediante anotaciones, proporciona un API para consulta de los datos, permite definir datos arbitrarios a guardar en cada versionado (usuario actual, fecha, etc.)...

No sin algún (inevitable) problema técnico debido a lo temprano de su adopción (algo a lo que estamos acostumbrados, por otra parte) lo incorporamos decididamente a los proyectos que teníamos en curso. De esta forma, con un coste mínimo (literalmente, el esfuerzo requerido es prácticamente nulo), podemos registrar las modificaciones en los datos que así lo requieran, con información adicional.

El resultado es satisfactorio, y en las últimas versiones están solucionando los pequeños problemas que existían (por ejemplo, para auditar una relación entre dos entidades era necesario que ambas estuviesen auditadas). La aceptación de este proyecto es tal que se ha aprobado como parte del núcleo de Hibernate, y vendrá incorporado en él a partir de la versión 3.5.

Recientemente han incorporado en el wiki una página de "proyectos que utilizan Envers" en la que hemos incorporado uno de nuestros proyectos emblemáticos, y os animamos a que hagáis lo mismo si, como nosotros, habéis adoptado esta solución para la auditoría de los datos de vuestras aplicaciones.