Bipunto..

Hibernate JPA

JBoss ha publicado como GA (disponibilidad general) la versión 3.2.0 de Hibernate.
Para quien no lo sepa, Hibernate es un ingenio software que permite persistencias de objetos planos Java (POJO's), cuya particularidad es que es una persistencia transparente, luego hablo poquitín más de esto.
Esta versión contiene un proveedor de persistencia Java que ha sido certificado mediante el Sun Technology Compatibility Kit (TCK) como compatible con la especificación Java Persistence API (JPA).

A efectos prácticos, esto significa que puede usarse JPA sin depender de un servidor de aplicaciones J2EE5, mediante Hibernate, o alternativamente usar el mismo código, específicamente sus anotations JPA, dentro de un servidor de aplicaciones J2EE5.
Otra relevante conclusión es que hasta este momento, Hibernate era uno de esos frameworks rebeldes, que tras la consolidación de JDO y JPA quedaba en una incómoda posición al no ser un estándar oficial. Ahora la situación ha cambiado y va a volver a ser como el tarro de miel para las moscas.

En combinación de Hibernate anotations, y evidentemente para Java 5, la implementación de JPA está montada por encima del núcleo de Hibernate mediante un wraper. Esto no parece un logro excepcional dado que Hibernate influyó (su creador Gavin King) en la especificación JPA, que no sé si catalogarlas como hermanas o primas.

Si al señor King se le ocurriese que Hibernate implementara además la especificación JDO, ya sea mediante otro wraper o como algo paralelo, crearía un monstruo de tres cabezas muy difícil de batir, incluso para béstias bicéfalas como BEA Kodo u Oracle TopLink. Pero eso va en contra de los intereses del servidor de aplicaciones de JBoss, cuyo proveedor de persistencia Java por defecto de su implementación EJB 3.0 es precisamente el de Hibernate, aunque tampoco sería del agrado de ningún otro servidor de aplicaciones J2EE5.

Volviendo al tema de la persistencia, básicamente ¿en que consiste esto?. Centrándonos en Java, el problema viene de que en nuestros programas, cuando se cierra la aplicación, los objetos creados desaparecen. Para solventar esto, dado que no es una característica intrínseca de Java, hay que proveer algún mecanismo para persistir el estado de los objetos. De entre las varias alternativas existentes: volcar la memoria, usar un fichero plano, una BBDD orientada a objetos o un SGBD Relacional, entre otras, esta última es reconocida como la más acertada, aunque no exclusivamente para Java.

Para no extenderme, finalmente tendremos que tener dos subsistemas, el del código Java y el del gestor de la Base de Datos relacional. De por medio, le metemos algún otro subsistema (middleware), como el propio mecanismo de persistencia con su adaptador de impedancias entre el mundo OO y el mundo relacional.

Lo ideal, sería que existiera un débil acoplamiento entre el código Java y el modelo de base de datos. Esto usualmente se conseguía con un fichero XML en el que se describía el 'mapeo' relacional, básicamente por que no existía ninguna otra manera de hacerlo (bueno con .ini's o XDoclets). Pero apareció Java5 y sus anotations, que permiten introducir en el código la meta información para el mapeo. Un ejemplo típico de uso de anotations para definir las persistencia de un objeto consistiría en algo así:


@Entity
@Table( name="users" )
public class User implements Serializable
{ ...
@Id @NotNull @Length(min=5, max=15)
public String getUsername()
{ ...


Esta tabla de salvación para los advenedizos programadores a los que el XML para el mapeo les produce sarpullido, es a la larga un arma de doble filo, pues en entornos corporativos en donde los datos de negocio y por ende las tablas y el modelo de datos en donde se alojan no son exclusivos de una sola aplicación, y en donde no es excepcional que cambie el modelo de datos, obligará a recompilar la aplicación cuando, en el caso de usar un XML, únicamente se tendría que cambiar este. Esto no quita que las anotaciones java sean muy útiles y adecuadas para proporcionar otro tipo de meta información que no puede cambiar puesto que depende de la lógica implementada, como atributos y características o restricciones invariantes, pero no el nombre de la tabla o de la columna en donde se persistirá el objeto. Y lo mismo ocurre cuando se comienza a desarrollar una aplicación y el modelo de datos todavía no está estable, el cambio en un subsistema forzará la recompilación de otros asociados, esta molestia se evidencía en grandes sistemas con varios equipos de trabajo. Afortunadamente EJB3 provee de un mecanismo para, mediante un XML de mapeo, imponer su mapeo sobre las anotations.
Otra ventaja del fichero de mapeo XML está en tener centralizada dicha información y poderla revisar por el analista, o compartir y reutilizar para otros proyectos.
La ventaja de tener todo el mapeo en anotations no sólo puede dar mayor facilidad al programador, al tener toda la información en el editor, sino que puede acabar convirtiéndose en una fuente de problemas, más que en una utilidad real.

Hibernate tiene, de momento, licencia LGPL.
Y por último ¿He escrito "JBoss ha publicado como GA..." ? quería decir, "Red Hat Middleware, LLC"..

Posted by Feliciano Borrego in Java at 20061022 Comentarios[1]