domingo, 11 de noviembre de 2012

Comparación de Implementaciones de JPA

Desde República Checa nos llega esta interesante tesis de Lukáš Šember, cuyo objetivo es comparar las tres implementaciones Open Source más populares de JPA:
Comienza con una breve introducción histórica a las bases de datos (relaciones, orientadas a objetos y NoSQL) y a las soluciones de persistencia provistas por la plataforma Java (JDBC, EJB 2, JDO, myBatis, para terminar en JPA).

Luego la tesis se divide en tres partes. En la primera, Šember se dedica a comparar los tres proveedores de JPA elegidos, exponiendo las fortalezas y debilidades de cada uno en distintos aspectos:
  • Generación de IDs
  • Performance
  • Conversión de Tipos
  • Soporte de Caché
  • Eventos
  • Generación de Esquemas
  • Soporte a Stored Procedures
  • Integración con Otros Frameworks
  • Licencias
  • Calidad de la Documentación
  • Sistemas de Build
La competencia es pareja. Es interesante leer el detalle de cada ítem, pero si vamos a la tabla comparativa de las conclusiones de la página 31, tenemos que la implementación de referencia, EclipseLink, el núcleo de TopLink donado a la Eclipse Foundation por Oracle, resulta el más performante en su configuración por defecto y el que mejor soporte provee para stored procedures (es lógico viniendo de Oracle). El veterano de JBoss nos brinda más funcionalidades a la hora de manejar eventos e integrarnos con frameworks existentes (es lógico considerando su historia y su cercana relación con Spring). OpenJPA se posiciona como el candidato más poderoso para generar el esquema automáticamente.

La segunda parte trata sobre distintos intentos del autor de migrar manualmente de un proveedor a otro, a partir de distintos proyectos Open Source descargados de Internet. Šember toma tres proyectos escritos con las tres distintas implementaciones, intenta migrar cada uno a los otros dos, y termina testeando con tres bases de datos diferentes: Oracle, PostgreSQL y MySQL. La conclusión a la que llega es que la migración no es para nada sencilla cuando la aplicación está haciendo un fuerte uso de las funcionalidades nativas, no estándares, que provee la implementación de JPA.

La última parte es más práctica. El objetivo final de la tesis es construir una herramienta que ejecute la migración automática de proyectos existentes que usan OpenJPA o EclipseLink, a Hibernate. La herramienta se llama JPA Migration y está escrita en Scala.

Como ven, el tema de la tesis es bastante interesante. A mí, en particular, la parte que más me interesó fue la primera, donde compara distintos aspectos de los tres proveedores que hay puestos sobre la mesa. En la práctica yo no veo tan útil un migrador. Es muy extraño que una empresa migre de una implementación de JPA a otra, y menos de una Open Source a otra Open Source, a menos que cambie de servidor de aplicaciones, que tampoco es algo tan común.

Quizá el escenario más probable podría ser el de un área de sistemas que desee deshacerse de su software privativo y le de la espalda a Oracle, migrando su servidor de aplicaciones Weblogic a uno comunitario y con gran soporte, como puede ser JBoss AS o TomEE. En ese caso, teniendo aplicaciones Java EE que usan EclipseLink o TopLink, quizá se justifique una migración a Hibernate (en el primer caso) o a OpenJPA (en el segundo). Pero siempre hay otras opciones menos dolorosas, como instalar EclipseLink en JBoss, o usar Glassfish en lugar de JBoss que también utiliza EclipseLink.

La tesis se puede descargar de:
http://is.muni.cz/th/365414/fi_m/thesis.pdf

El material me llegó vía el Twitter de @myfear.
¡Muchas gracias por compartirlo!