DESARROLLADO POR:
Consultor tecnológico de desarrollo de proyectos informáticos.
Ingeniero Técnico en Telecomunicaciones
Puedes encontrarme en Autentia: Ofrecemos servicios de soporte a desarrollo, factoría y formación
Somos expertos en Java/J2EE
Fecha de publicación del tutorial: 2007-05-07
12.306
12.306
Regístrate para votar
INTRODUCCIÓN
Han
pasado muchos años desde que los EJBs hicieron su
aparición para hacer "decían" nuestra vida más
sencilla.
La verdad es que un framework que nos aportaba transaccionalidad distribuida, seguridad, persitencia manejada por el contenedor etc... (eso por definición) y además, clustering, tolerancia a fallos y balanceo de carga (eso por implicación de los servidores de aplicaciones) pues sonaba muy bien.
Pero la realidad es que a la hora de ponernos a trabajar con ellos, siempre suponía un handicap el terrible engorro que suponía desarrollar este tipo de componentes. Tener que definir los descriptores de los ejbs (el de J2EE más el propio del fabricante), algunos de los cuales eran una auténtica tortura (a mi especialmente la forma de definir la persistencia de los Entities me crea pesadillas nocturnas), por no hablar de cuando había que compilarlos previamente para generar los stubs... (menos mal que apareció el Proxy Dinámico).
Es cierto que han aparecido herramientas para facilitarnos o para ahorrarnos errores como XDoclet etc... , pero a mi personalmente (excluyendo los MDBs) me parecía un horror.
La aparición de frameworks como Spring ha hecho mucho daño a los EJBs, porque para que me voy a complicar la vida, si al fin y al cabo, pocas veces se usa realmente transacciones distribuidas.
En fin, que parecía que los EJBs estaban condenados a desaparecer enterrados bajos sus descriptores, cuando de repente aparece EJB 3.0 ....
La pregunta que lanzo a la audiencia es: ¿ Es posible seguir teniendo la funcionalidad prometida por los EJBs de una manera sencilla (que hasta yo sea capaz de trabajar con ellos) ?
Pues parece que si, y por lo que he visto hasta ahora es una realidad y no ciencia ficción: EJB 3.0 Resurrection.
SOY UN ESCÉPTICO: ¿ POR QUÉ VOLVER A USAR EJBs ?
La primera razón es la que más me gusta, aunque seguro que alguno aqui se me muere de risa:
Defino un Interfaz (El POJI)
@Remote
public interface POJIHello {
public void dimeAlgo();
}
Defino el Bean que lo define (El POJO)
@Stateless
public class POJOHello implements POJIHello {
public void dimeAlgo() {
System.out.println("Algo");
}
}
Empaquétalo en un jar, y ya está, tu primer EJB 3.0
¿ Y LAS COSAS NUEVAS ?
Alguna ya la vemos en el ejemplo anterior, el uso de anotaciones, pero vamos a ver algunas más:
En resumen, EJB 3.0 se ha convertido en:
EJB 3.0 = (Lo bueno de EJB 2.1) - (Lo malo de EJB 2.1) + Spring + Hibernate
¿ COMO DEBERÍA MIGRAR DE EJB 2.X A 3.0 ?
Algunos pasos serían:
En próximos tutoriales os enseñaré a trabajar con los EJBs 3.0 y veremos muchas de las cosas nuevas.
La verdad es que un framework que nos aportaba transaccionalidad distribuida, seguridad, persitencia manejada por el contenedor etc... (eso por definición) y además, clustering, tolerancia a fallos y balanceo de carga (eso por implicación de los servidores de aplicaciones) pues sonaba muy bien.
Pero la realidad es que a la hora de ponernos a trabajar con ellos, siempre suponía un handicap el terrible engorro que suponía desarrollar este tipo de componentes. Tener que definir los descriptores de los ejbs (el de J2EE más el propio del fabricante), algunos de los cuales eran una auténtica tortura (a mi especialmente la forma de definir la persistencia de los Entities me crea pesadillas nocturnas), por no hablar de cuando había que compilarlos previamente para generar los stubs... (menos mal que apareció el Proxy Dinámico).
Es cierto que han aparecido herramientas para facilitarnos o para ahorrarnos errores como XDoclet etc... , pero a mi personalmente (excluyendo los MDBs) me parecía un horror.
La aparición de frameworks como Spring ha hecho mucho daño a los EJBs, porque para que me voy a complicar la vida, si al fin y al cabo, pocas veces se usa realmente transacciones distribuidas.
En fin, que parecía que los EJBs estaban condenados a desaparecer enterrados bajos sus descriptores, cuando de repente aparece EJB 3.0 ....
La pregunta que lanzo a la audiencia es: ¿ Es posible seguir teniendo la funcionalidad prometida por los EJBs de una manera sencilla (que hasta yo sea capaz de trabajar con ellos) ?
Pues parece que si, y por lo que he visto hasta ahora es una realidad y no ciencia ficción: EJB 3.0 Resurrection.
SOY UN ESCÉPTICO: ¿ POR QUÉ VOLVER A USAR EJBs ?
La primera razón es la que más me gusta, aunque seguro que alguno aqui se me muere de risa:
- Porque son fáciles de usar:
- Los EJBs se convierten en POJOs y los interfaces en POJIs
- Puedes mandar los descriptores a la basura (si quieres) porque aparecen las anotaciones.
- La forma de declarar la persistencia en los Entities es juego de niños (se parece sospechosamente a Hibernate)
- Porque seguimos teniendo la misma funcionalidad (Transaccionalidad, Seguridad, persistencia ... ), y alguna más
- Porque es un estándar abierto.
- Porque hay mucha gente implicada en que esto salga bien.
Defino un Interfaz (El POJI)
@Remote
public interface POJIHello {
public void dimeAlgo();
}
Defino el Bean que lo define (El POJO)
@Stateless
public class POJOHello implements POJIHello {
public void dimeAlgo() {
System.out.println("Algo");
}
}
Empaquétalo en un jar, y ya está, tu primer EJB 3.0
¿ Y LAS COSAS NUEVAS ?
Alguna ya la vemos en el ejemplo anterior, el uso de anotaciones, pero vamos a ver algunas más:
- Inyección de dependencias: Podemos ahora acceder a otros EJBs o recursos simplemente indicándole al contenedor que inyecte las referencias que necesitamos, sin tener que usar JNDI
- Se simplifica mucho la forma de persistir los Entities
- Se define la persistencia mediante anotaciones en los Entities (de una manera similar a Hibernate)
- No se accede directamente a los Entities, sino que se persisten a través de un interfaz (EntityManager) , usando ORM
- Los Entities son ahora POJOs, con lo que pueden ser usados como DTOs.
- Se pueden crear temporizadores usando TimerService.
- Los EJBs de sesión sin estado pueden usarse como EndPoint de un Webservice de una manera muy sencilla.
- Aparece el concepto de AOP e interceptores.
En resumen, EJB 3.0 se ha convertido en:
EJB 3.0 = (Lo bueno de EJB 2.1) - (Lo malo de EJB 2.1) + Spring + Hibernate
¿ COMO DEBERÍA MIGRAR DE EJB 2.X A 3.0 ?
Algunos pasos serían:
- Usar Java 5 por el tema de las anotaciones
- Los Bean de sesión:
- No necesitan implementar SessionBean. Basta con anotarlos con:
- @Stateless (sin estado)
- @Stateful (con estado)
- No necesitamos crear los métodos ejbCreate en los Bean ni los métodos del ciclo de vida.
- Los métodos del ciclo de vida se anotan con:
- @PostCreate
- @PostActivate
- @PreDestroy
- @PrePassivate
- No necesitamos definir los interfaces Home ni Local Home
- Los interfaces se sustituyen por POJIs:
- @Local
- @Remote
- No necesitamos descriptor de despliegue.
- Los Entities
- No necesitan implementar EntityBean, Basta con anotarlos con:
- @Entity
- No necesitan el método create, ni los métodos del ciclo de vida.
- No necesitan descriptor de despliegue. No necesitan descriptores de persitencia, se define mediante anotaciones.
- La persitencia se maneja a través de EntityManager.
En próximos tutoriales os enseñaré a trabajar con los EJBs 3.0 y veremos muchas de las cosas nuevas.
Anímate y coméntanos lo que pienses sobre este TUTORIAL:
Puedes opinar o comentar cualquier sugerencia que quieras comunicarnos sobre este tutorial; con tu ayuda, podemos ofrecerte un mejor servicio.
Comentarios
-
gustavo2009-08-04 - 01:56:07 PMbuenisimo me dejo muchas cosas fuera de dudas............
-
Alberto2007-07-12 - 05:46:21 PM
Excelente explicación.
