Comparativa entre Hibernate y EJB3 en la Capa de
Persistencia

El presente documento
pretende dar algunas luces a la comparativa entre la opción de
usar Hibernate y/ó EJB3 para la capa de persistencia¹
en los desarrollos de aplicaciones empresariales bajo un entorno JEE.
Las dos primeras secciones son un recordatorio de que es Hibernate y
que es EJB respectivamente, luego se orienta la situación
actual y finalmente se presenta una tabla que resume en forma de
comparación las características de Hibernate versus las
características de EJB3 para la capa de persistencia.

Hibernate²

Hibernate es una
herramienta ORM completa que ha conseguido en un tiempo record una
excelente reputación en la comunidad de desarrollo
posicionándose claramente como el producto OpenSource³
líder en este campo gracias a sus prestaciones, buena
documentación y estabilidad. Es valorado por muchos incluso
como solución superior a productos comerciales dentro de su
enfoque, siendo una muestra clara de su reputación y soporte
la reciente integración dentro del grupo JBOSS⁴
que seguramente generará iniciativas muy interesantes para el
uso de Hibernate dentro de este servidor de aplicaciones.

Hibernate parte de una
filosofía de mapear objetos Java «normales», también
conocidos en la comunidad como «POJO’s⁵»
(Plain Old Java Objects). No contempla la posibilidad de automatizar
directamente la persistencia de Entity Beans tipo BMP (es decir,
generar automáticamente este tipo de objetos), aunque aún
así es posible combinar Hibernate con este tipo de beans
utilizando los patrones para la delegación de persistencia en
POJO’s.

Una característica
de la filosofía de diseño de Hibernate ha de ser
destacada especialmente, dada su gran importancia: puede utilizar los
objetos Java definidos por el usuario tal cual, es decir, no utiliza
técnicas como generación de código a partir de
descriptores del modelo de datos o manipulación de bytecodes
en tiempo de compilación (técnica conocida por su
amplio uso en JDO), ni obliga a implementar interfaces determinados,
ni heredar de una superclase. Utiliza en vez de ello el mecanismo de
reflexión de Java. Hibernate trata con la reflexión de
Java y el aumento de clases en tiempo de ejecución utilizando
una librería de generación de código Java muy
poderosa y de alto rendimiento llamada CGLIB. CGLIB se utiliza para
extender clases Java e implementar interfaces Java en tiempo de
ejecución.

EJB⁶

EJB (Enterprise Java
Beans) es un marco de trabajo para el desarrollo de aplicaciones
empresariales en Java, el modelo de EJB es propuesto a través
de un JSR (Java Specification Requerimient) es decir es una
especificación que debe ser implementada por cualquier
proveedor de servidor de aplicaciones que desee ser compatible con la
misma.

La especificación
de EJB define una arquitectura para el desarrollo y despliegue de
aplicaciones basadas en objetos distribuidos transaccionales,
software de componentes del lado del servidor. Las organizaciones
pueden construir sus propios componentes o comprarlos a vendedores de
terceras partes. Estos componentes del lado del servidor, llamados
Beans Enterprise, son objetos distribuidos que están
localizados en contenedores de JavaBean Enterprise y proporcionan
servicios remotos para clientes distribuidos a lo largo de la red.

La especificación
de Enterprise Java Beans define una arquitectura para un sistema
transaccional de objetos distribuidos basado en componentes. La
especificación manda un modelo de programación; es
decir, convenciones o protocolos y un conjunto de clases e interfaces
que crean el API EJB. Este modelo de programación proporciona
a los desarrolladores de Beans y a los vendedores de servidores EJB
un conjunto de contratos que definen una plataforma de desarrollo
común. El objetivo de estos contratos es asegurar la
portabilidad a través de los vendedores y el soporte de un
rico conjunto de funcionalidades.

Los EJB representan la
base del modelo de negocio, definido en términos de un
conjunto de componentes colaborativos. Los EJB se utilizan para
forzar las reglas de negocio, para encapsular la lógica de
negocio y para acoplar el modelo de negocio con la aplicación
empresarial.

Para crear un componente
EJB del lado del servidor, un desarrollador de bean enterprise
proporciona dos interfaces que definen los métodos de negocio
del bean, además de la implementación real de la clase
bean. Entonces el cliente usa un interfaz público del bean
para crear, manipular, y eliminar beans del servidor EJB. La clase de
implementación, será llamada clase del bean, es
ejemplarizada en tiempo de ejecución y se convierte en un
objeto distribuido.

Para crear un EJB⁷,
necesita escribir tres elementos de código java:

• Una interfaz Home,
  utilizada para gestionar el ciclo de vida de los EJB (contiene los
  métodos create, locate y remove)

• Una interfaz Remote,
  utilizada para definir los métodos de negocio.

• Implementar Enterprise
  Beans.

Además hay que
escribir un documento XML llamado descriptor⁸
de la distribución que especifica los detalles de cómo
deben ser gestionados los EJB; este fichero contiene información
sobre la configuración, administración y gestión
de recursos.

Los beans enterprise
viven en un contenedor EJB y son accedidos por aplicaciones clientes
a través de la red usando sus interfaces remoto y local
(home). Estos interfaces exponen las capacidades del bean y
proporcionan todos los métodos necesarios para crear,
actualizar, borrar e interactuar con el bean.

EJB3⁹

EJB 3.0 (la versión
actual de EJB) incluye

• El nuevo «API de
  Persistencia de Java»

• Un modelo más
  sencillo para la implementación de fachadas

• Por compatibilidad,
  incluye las APIs del modelo anterior (EJB 2.1)

Nuevo API de Persistencia Java

• Inspirado en Hibernate,
  TopLink y JDO

• Mapeador
  objeto/relacional al estilo Hibernate/TopLink

• En consecuencia, no
  oculta que el tipo de BD sea relacional

• Actualmente
  Hibernate y TopLink implementan el API de Persistencia de Java

• Se
  puede usar en entornos J2SE (fuera de un contenedor J2EE) y sin el
  resto de componentes de EJB

• Consta de

• Anotaciones

• El API propiamente
  dicha

• EJB-QL

• Anotaciones

• El
  desarrollador puede anotar las clases persistentes (llamadas
  «entidades») para que la implementación del API de
  Persistencia sepa cómo mapear las instancias a la BD (e.g.
  indica el nombre de la tabla, los nombres de las columnas a las que
  mapear los atributos, etc.)

• El API propiamente dicha

  • javax.persistence

  • Objetos principales

• EntityManager:
  permite crear, encontrar por clave primera, y eliminar objetos
  persistentes, y crea objetos Query

• Query: permite lanzar
  consultas en EJB-QL

• Internamente
  las implementaciones usan el API de JDBC (transparentemente al
  programador)

• EJB-QL (EJB Query
  Language)

  • Lenguaje
    de consultas de búsqueda y borrados/actualizaciones en masa

  • La
    implementación traduce al SQL de la BD que se esté
    usando

Implementación de
Fachadas

• Pueden ser locales o
  remotas

• Ocultan las APIs de
  transacciones y seguridad al desarrollador

• Las versiones anteriores
  de EJB también proporcionaban lo anterior, pero con un modelo
  de programación más complejo

• Tipos de fachadas

• Session Beans

• Message-Driven
  Beans

• Session Beans

• Fachadas «normales»
  (operaciones síncronas)

• Hay que definir una
  interfaz y una implementación

• Variantes

• Stateless Session Beans
  (SLSB)

• Stateful Session Beans
  (SFSB)

Situación actual

El modelo de programación
propuesto por la versión 2.1 (y anteriores) de EJB conllevaba
una serie de inconvenientes que limitaron mucho el uso y aceptación
de esta especificación y motivó la aparición de
muchas soluciones Open Source que suplían las carencias y
dificultades que presentaba EJB 2.1. En este ámbito, las
soluciones Open Source que más han marcado el desarrollo
empresarial dentro de la plataforma Java han sido Hibernate, y Spring
Framework, y en la nueva versión de Java Enterprise Edition se
han incorporado muchas de las características de estos
frameworks para procurar a los desarrolladores una plataforma de
desarrollo bastante más sencilla que su predecesora versión
1.4.

Hibernate es, como ya se
mencionó, un framework¹⁰
para el manejo de persistencia. Hasta hace poco era un estándar
de facto de la industria pues nació fuera de las
especificaciones de SUN pero su facilidad de uso y su gran desempeño
hicieron que tuviera una acogida realmente excepcional llegando a ser
el framework de persistencia de mayor uso en el mundo java. La
principal particularidad de Hibernate es que permite la persistencia
de objetos java simples conocidos como POJO’s

La especificación
de EJB3 reconoce las ventajas de Hibernate y hace eco de mantener un
mapeo objeto/relacional transparente. En esta especificación
se estandarizaron los APIs de persistencia JPA y JDO (Java
Persistence API y Java Data Objects), de esta forma la nueva
especificación se convierte en una especie de clon de las
mejores características de Hibernate (no en vano el creador de
Hibernate Gavin
King ha participado también en la especificación
de JPA), a las que se sumaron lo mejor y más rescatable de JPA
y JDO teniendo como resultado que la implementación de la capa
de persistencia de EJB3 es drásticamente diferente a su par en
la especificación EJB 2.1. Y desde el lado del mundo Open
Source el reconocimiento fue mutuo porque Hibernate 3.2 en su Entity
Manager implementa el ciclo de vida y las reglas definidas por la
especificación de EJB3 convirtiéndose en una
implementación más de JPA. Además aparecen en
Hibernate el soporte a las anotaciones de JPA de tal forma que en la
parte de persistencia puede pasarse sin mayores problemas de
Hibernate a EJB3, ahora el cambio puede ser prácticamente
transparente.

Como dato adicional cabe
resaltar que la versión actual de Hibernate 3.2 ha sido
certificada mediante el Sun Technology
Compatibility Kit (TCK) como compatible con la especificación
Java Persistence API (JPA).

Tabla de comparación de Hibernate y EJB3 en la
capa de persistencia

Conclusiones

• EJB3 no es Hibernate, el
  primero es un marco de trabajo para el desarrollo de aplicaciones
  empresariales en Java, mientras que el segundo es un framework
  únicamente para la capa de persistencia de datos.

• En este momento una
  comparación de EJB3 y Hibernate únicamente en la parte
  de persistencia resulta prácticamente un empate, quizás
  Hibernate resulta un poco ganador por ser un producto más
  maduro y con mucho más uso en la actualidad.

• Cuando Hibernate
  implementa EJB3, en Hibernate 3.2 la comparación pierde peso
  pues Hibernate 3.2 se convierte en una implementación más
  de JPA (EJB3).

• Si hablamos de curva de
  aprendizaje y rapidez de desarrollo, personalmente veo a EJB3 como
  un claro ganador, la curva es corta, las ventajas evidentes y los
  tiempos de desarrollo, líneas de código y archivos que
  se necesitan para que la aplicación funcione se reducen
  considerablemente con EJB3.

• Se necesitan más
  comparativas entre EJB3 y otros frameworks como por ejemplo una
  comparativa entre Spring + Hibernate para cubrir todo el espectro de
  las aplicaciones JEE, sobre todo en lo referente al rendimiento de
  los EJB de sesión ya sean con estado (stateful) o sin estado
  (stateless) pues al menos en teoría la instanciación
  de los EJB’s en sesión va a seguir siendo más pesada
  que una aplicación liviana desarrollada con Spring, sin
  embargo debe pensarse en otros aspectos como la seguridad y el
  manejo de la transaccionabilidad para poder finalmente indicar que
  es mejor para un desarrollo de una aplicación profesional.

• Como acotación a
  la conclusión anterior el modelo de POJO’s en el que se
  basa EJB3 hace que sea posible tener aplicaciones EJB3 livianas
  (ligthweigth applications) que pueden competir en rendimiento
  (tiempo de respuesta, carga, optimización del ciclo del
  garbage collector) con las aplicaciones que se desarrollan con
  frameworks como Spring, aunque personalmente aún no conozco
  ni he encontrado comparativas que demuestren que esta afirmación
  sea completamente acertada.

• Una ventaja adicional de
  EJB3 es que provee todo el entorno de trabajo para el desarrollo de
  aplicaciones empresariales, evitando la compleja tarea de integrar
  diferentes frameworks para cada capa distinta de la aplicación.
  

• Me atrevo a hacer un
  pronóstico, no pasará mucho tiempo antes de que Spring
  y otros frameworks similares se reconviertan internamente para
  cumplir con la especificación.

Bibliografía

1. Persistencia de los
   Objetos Java utilizando Base de Datos Relacionales, Galeano
   Cristian, Goette Emmanuel

2. BIPunto Weblog,
   Hibernate JPA

3. Sizing
   Up Open Source Java Persistence, Jim White, http://www.devx.com/
   

4. Comentarios de Alejandro
   Pérez, Autentia

5. Apuntes de Integración
   de Sistemas, Fernando Bellas

6. JBOSS
   Books, What is a Lightweight Web
   Application, http://docs.jboss.com/books/lightweight/pt01.html