Pregunta 1196, Bloque 4: Alternativas a EJB

[gabiotillo]

En la siguiente pregunta

1196) ¿Cuál de los siguientes puede ser una alternativa a EJB?
a) Hibernate
b) JDBC
c) Ninguna de las anteriores
d) la opción a) y b)

Se da como válida d). Ver a Hibernate como alternativa a EJB, aunque un poco cogido por los pelos, pero puedo entenderlo. ¿Pero alguien puede explicarme porque JDBC es una alternativa a EJB?

[nirvana]

Yo habria dicho que ninguna
salvo que se este pensando en la gestion de datos
porque entonces tanto JDBC como Hibernate cuadraría

para mi un EJB no tiene que acceder a la BD como hacen las otras dos tecnologias. Es puramente de proceso.

[iskandarcali]

Efectivamente, para mi tampoco es correcto puesto que simplemente es un componente para encapsular lógica de negocio mientras que hibernate y jdbc tienen otros propósitos.

Si estoy equivocado, os agradecería que me lo comentarais.

Un saludo

[Cansino]

Coincido en que la pregunta no está bien planteada. Pero una aclaración, los EJB no son solamente para encapsular componentes de negocio. EJB define 3 tipos de componente:
- Session Beans: Los componentes de negocio.
- Entity beans: representan entidades de dominio (típicamente objetos que se hacen persistir sobre tablas relacionales).
- Message Driven Beans: Componentes también de negocio que interactúan utilizando el estándar de mensajería de Sun (JMS).

Si la pregunta hubiese especificado "Entity Beans", hibernate sí que se puede considerar una alternativa a éstos. De hecho es la alternativa que se ha impuesto en la industria. Hasta tal punto, que los Entity Beans de EJB 3.0 (nueva especificación de la JEE 1.5), mimetizan los fundamentos de Hibernate y han dado lugar a una API: La "Java Persistence API", que se espera evolucione independiente de EJB.

JDBC yo no lo consideraría una alternativa, porque simplemente se sitúa en otro nivel de abstracción muy por debajo de un sistema de mapeo objeto/relacional (como en EJB 3.0 e Hibernate).

La verdad que desconozco el origen de esta pregunta. Quizás está copiada de algún examen y el que la sacó no recordaba con exactitud su redacción. A mi me suena al fracaso que se acabó por aceptar hace poco de la tecnología EJB. La que iba a ser la especificación estrella de J2EE (los EJB) acabó siendo la tecnología J2EE menos utilizada. La razón era su complejidad y que era enormemente intrusiva para el desarrollador. Otras, fundamentalmente los Servlets y JSP sí que tuvieron mucho éxito.

Struts, al igual que hibernate, ha sido otro framework que ha tenido una gran aceptación en la comunidad de desarrolladores y se construye sobre Servlets y JSP.

Así, Hibernate y Struts se utilizaron en la práctica muchísimo más que las alternativas estándares de Sun (JSF, JDO, EJB). Se comenzó a hablar y a escribir sobre utilizar "J2EE without EJBs". Sun ha reaccionado y ha introducido un enfoque totalmente diferente en todas las especificaciones de JEE 5.0, adoptando enfoques que ya han tenido éxito en las propuestas de la comunidad. El caso de la persistencia de los EJBs se basa en Hibernate, como he dicho.

En resumen, la pregunta creo que está mal planteada, pero conviene conocer por dónde podían ir los tiros de la misma.

Efectivamente, para mi tampoco es correcto puesto que simplemente es un componente para encapsular lógica de negocio mientras que hibernate y jdbc tienen otros propósitos.

Si estoy equivocado, os agradecería que me lo comentarais.

Un saludo

[ferdavid]

Enorme Cansino.

Has conseguido que hasta yo, que ando bastante pez en estos temas, me entere.
Lo dicho, perfecto.

[iskandarcali]

Muchas gracias por la aclaración, me ha ayudado a comprender mejor el tema.

Un saludo

[Txingu1]

Muy brillante, Cansino. Gracias por la explicación.

Saludos.

[gabiotillo]

Realmente enorme, cansino. Yo por la wiki había mas o menos entendido el tema, pero esto lo aclara más. Efectivamente lo de Hibernate era traido por los pelos pero lo de JDBC nastideplasti.

Gracias a todos.

[nirvana]

ciertamente ha sido un grandisima explicacion.
Gracias, Cansino