Cristhian Herrera

Residencia: Quito (Ecuador)

Cristhian.Herrera@gmail.com / cherrera@kruger.com.ec

Cuento con experiencia en el área de desarrollo de software y en la docencia académica. Dentro de la construcción de software he manejado las etapas de: análisis, diseño, personalización e implementación de aplicaciones bajo ambientes Cliente / Servidor e Internet.

Ver todos los tutoriales del autor

Fecha de publicación del tutorial: 2007-08-16

Tutorial visitado 26.916 veces Descargar en PDF
Comparativa entre Hibernate y EJB3

Artículos sobre JEE

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 persistencia1 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.


Hibernate2

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 OpenSource3 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 JBOSS4 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's5" (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.

EJB6

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 EJB7, 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 descriptor8 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.

EJB39

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 framework10 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



Hibernate

EJB3

Estándar

Hibernate 3.2 es una implementación del estándar.

Estándar de SUN


Cada proveedor debe proporcionar una implementación.


Portabilidad

Se depende de que JBOSS es el único proveedor y se necesita siempre llevar los jars11 de Hibernate en los proyectos ó en el classpath12 para que nuestra aplicación funcione cuando se trabaja en otro servidor de aplicaciones.


Cualquier desarrollo con EJB 3 debe ejecutarse en un servidor de aplicaciones certificado para EJB3 sin realizar cambios en la misma.

Curva de aprendizaje

Muy corta, fácil de aprender.


Aunque realmente son pocos los profesionales que realmente usan Hibernate en todo su potencial.

En EJB3 es similar a Hibernate


Se debe resaltar que EJB3 tiene un ámbito mucho más amplio que sólo la capa de persistencia.


En versiones anteriores de EJB la comparación favorecía a Hibernate.


Dependencia de otros proyectos

Hibernate se encarga únicamente de la capa de persistencia, debe soportarse con otros proyectos Open Source como Spring para cubrir otros aspectos del desarrollo de una aplicación empresarial JEE.


Una implementación de la especificación EJB3 cubre todos los aspectos del desarrollo de una aplicación empresarial JEE.


EJB3 = Hibernate + Spring + ...

Aceptación de la industria

Completamente aceptado por la industria.


Existe un gran número de desarrolladores JAVA en el mundo entero que apoyan a Hibernate.

Existe un fuerte movimiento de los grandes competidores de la industria para adaptar EJB3.

Se pueden mencionar a SUN, JBOSS, Oracle, IBM como los más fuertes impulsadores del uso de EJB3. Cada uno de ellos está proveyendo en sus servidores de aplicaciones la respectiva implementación de soporte para EJB3.


Al momento de escribir estas líneas, únicamente conozco que SUN App Server, JBOSS, Oracle Aplication Server y JONAS están ya oficialmente certificados para EJB3.


El número de desarrolladores que están empleando EJB3 se está incrementando con mucha rapidez, pues agrupa a una buena parte de quienes usaban JPA y JDO y también a un gran número de jóvenes programadores que empezaron en java con la versión JEE 5.0


Un punto adicional es que JBOSS incentiva el uso de EJB3 aún siendo JBOSS el propietario de Hibernate.


Comparativas de rendimiento

No necesariamente el mejor frente a otros competidores como JPOX (JDO), IBatis, Castor, TopLink o JDBC.


Sin embargo los resultados con Hibernate siempre estaban entre los mejores en cualquier comparativa.


Frente a versiones anteriores de EJB, era indudablemente mejor usar Hibernate

Las versiones predecesoras no gozaban de buenas referencias dejando a EJB en mala posición frente a las demás alternativas.


Aún no existen suficientes comparativas y resultados frente a las otras opciones, sin embargo debe reconocerse que EJB3 nace con JEE 5.0 el mismo que viene optimizado y es un 60% más rápido y eficiente que JDK 1.4


Al hablar de Hibernate 3.2 y EJB 3 en la parte de persistencia no debería haber razón de una comparativa pues el primero es una implementación del segundo.


Generación de código

Mediante plug-ins para Eclipse y otros IDES.


Generación con XDoclet

JDeveloper proporciona soporte para generación de código de EJB3.


Mediante plug-ins para Eclipse y otros IDES.


Generación con XDoclet


Archivos de Mapeo (XML)

Opcional en la versión actual


Obligatorio en versiones anteriores


Opcional en EJB3


Obligatorio en versiones anteriores

Simplicidad

Sencillamente siempre fue simple.

EJB3 reduce el número de clases y número de interfaces que los programadores deben programar ó implementar.


Reduce el número de artefactos (archivos de configuración, descriptores de despliegue) que se requieren para que la aplicación funcione.


Evita los antipatrones.


Mapeo Objeto/Relacional

Soporta el mapeo de relaciones complejas de objetos


Soporte de claves simples y compuestas


Soporte de claves simples y compuestas


Mapeo de superclases y relaciones de herencia de clases


Uso de Lazy / Eager para carga liviana y pesada de objetos relacionados


Actualizaciones y eliminación de datos en cascada


Soporta el mapeo de relaciones complejas de objetos


Soporte de claves simples y compuestas


Mapeo directo de propiedades y columnas


Mapeo de superclases y relaciones de herencia de clases


Uso de Lazy / Eager para carga liviana y pesada de objetos relacionados


Actualizaciones y eliminación de datos en cascada

Configuración de acceso a base de datos

Se tiene un Hibernate Dialect para cada motor de base de datos.


Debe especificar el dialecto de la base de datos (Oracle, DB2, etc)


Puede usar su propio archivo de configuración o hacer uso de la configuración de otro framework como Spring.


La configuración de acceso a datos también puede hacerse mediante JNDI para nombrar un datasource.


Requiere de la configuración de un datasource con un nombre JNDI (Java Naming and Directory Interface) para la conexión a la base de datos.


En el datasource se debe especificar el driver de base de datos que se empleará para la conexión así como otros datos como usuarios y claves y el uso o no de un pool de conexiones.

Trabajar fuera del contenedor de aplicaciones (stand alone)

Hibernate puede trabajar sin un servidor de aplicaciones, tanto en desarrollos de aplicaciones livianas, como en desarrollos de aplicaciones complejas.

JPA y la persistencia en EJB3 también se puede emplear sin un servidor de aplicaciones.


Toda la especificación de EJB3 puede trabajar sin un servidor de aplicaciones gracias a desarrollos como Embedded JBoss


POJOS

Soportados

Soportados en capa de persistencia (Entity Beans)


Soportados en capa de negocio (Session Beans y Message Driver Beans)


En resumen se tiene un amplio soporte a los POJO's en todas las capas del desarrollo de una aplicación JEE.


Los POJOS también pueden ser testeados fuera del contenedor de aplicaciones.

Uso de las Anotaciones

Soportada anotaciones


Anotaciones JEE 5.0 y superiores


Anotaciones JPA


Anotaciones Hibernate


Soportadas anotaciones


Anotaciones JEE 5.0 y superiores

Anotaciones JPA


Anotaciones EJB

HQL

Soportado


Consultas simples y complejas

Joins (inners joins y outer joins)


Característica de "Criteria" y composición de objetos


Proyecciones y Agrupaciones



EJBQL


Soportado


Consultas simples y complejas

Joins (inners joins y outer joins)


Subconsultas en las cláusulas (WHERE y HAVING)


Funciones en consultas (de cadenas, aritméticas, agregadas)


Característica de "Criteria" y composición de objetos


Proyecciones y Agrupaciones


Querys nativos

Soportados


Soportados

Objetos distribuidos


Soportados



Reflexión (Reflection)

Soportado



Soportado

Inyección de dependencias

Soportados mediante extensiones de Hibernate y mediante el uso de otros frameworks como Spring


Soportados nativamente como parte de la especificación.

Manejo de Transacciones

Soportadas mediante extensiones de Hibernate y mediante el uso de otros frameworks como Spring

Soportadas nativamente como parte de la especificación.


Por defecto los métodos de un EJB de sesión son requeridos, es decir son transaccionados


Manejo de seguridad

Soportada mediante extensiones de Hibernate y mediante el uso de otros frameworks como Spring.


Soportada nativamente como parte de la especificación.

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

1 En el modelo de desarrollo de aplicaciones en capas, la capa de persistencia hace referencia a la parte de la lógica que se ocupa de interactuar con un motor de base de datos y de garantizar que la información pueda almacenarse y recuperarse de forma transparente y óptima para el usuario final.

2 Sección tomada de primera referencia bibliográfica.

3 Open Source (Código Abierto) corriente que avala la libre compartición y uso del código fuente de las aplicaciones, estableciendo un modelo de negocio de enorme éxito, pues el rédito no está en vender el software sino en darle soporte, en compartir la experiencia de los desarrolladores y en la mejora constante de los desarrollos.

4 Grupo Open Source que popularizó un servidor de aplicaciones con su mismo nombre JBOSS, la empresa acaba de ser adsorbida por Red Hat y el grupo se ha hecho cargo de Hibernate adaptándolo como su producto ORM para la persistencia de datos.

5 Un POJO es una clase JAVA, en su forma más pura, y básicamente consta de un conjunto de atributos y métodos de obtención y establecimiento (métodos getters y setters) para cada uno de los atributos definidos para la clase.

6 Sección tomada de primera referencia bibliográfica

7 En la especificación EJB3 las interfaces local y remota son opcionales, puede declararse la una o la otra ó ambas ya no se obliga a tener las dos, y se reduce y simplifica el código con las anotaciones.

8 En la especificación EJB 3 el descriptor de la aplicación se puede reemplazar con anotaciones

9 Sección tomada de la quinta referencia de la bibliografía.

10 Framework ó marco de trabajo, es básicamente la agrupación de un conjunto de utilidades y mejores prácticas para emplearlos como acelerador para otros desarrollos. Los frameworks se escriben en base a la aplicación explícita de ciertos patrones de diseño, como por ejemplo el modelo MVC y pretenden resolver ciertos problemas comunes y a la par brindarle al desarrollo un conjunto fuerte de utilidades que le permitan hacer su trabajo en forma más rápida y eficiente.

11 JAR es el acrónimo para Java Application Resource, un jar es archivo en el cual se distribuyen librerías (clases Java) para que puedan ser usadas por otras aplicaciones.

12 El classpath de una aplicación java es la ruta o directorio donde puede encontrar a las clases que necesita para poder funcionar.

Ing. Cristhian Kirs Herrera Basurto 11

A continuación puedes evaluarlo:

Regístrate para evaluarlo

Por favor, vota +1 o compártelo si te pareció interesante

Share |
Anímate y coméntanos lo que pienses sobre este TUTORIAL:

Fecha publicación: 2009-05-21-03:57:20

Autor:

[Egard] Un buen punto de referencia cuando se va a entrar a una tecnologia nueva, en este caso para la capa de persistencia, o se quiere definir la arquitectua de una aplicacion nueva. Aunque a veces el tema se torna demasiado tecnico. Hubiese sido util algunos ejemplos sencillos de como se hace cada cosa. De todos modos un buen tutorial como guia para tomar una decision de arquitectura.