1. Enterprise Java Beans 3.0
Introducción
El objetivo de Enterprise JavaBeans (EJB) 3.0 es simplificar el desarrollo de
aplicaciones Java y estandarizar el API de persistencia para la plataforma Java.
EJB 3.0 está cambiando drásticamente el modelo de programación de EJBs.
Algunas de las nuevas características clave son:
Cambios generales:
• EJB 3.0 elimina la necesidad de las interfaces home y de componente, y el
requisito de que las clases bean implementen la interfaz
javax.ejb.EnterpriseBean. Los EJBs pasan a ser ahora POJOs.
• Simplificación de la configuración a través de valores por defecto y del uso de
anotaciones de metadatos en lugar de descriptores de despliegue.
• Se soporta la inyección de dependencias para utilizar EJBs, recursos y variables
de entorno.
• Soporte métodos de ciclo de vida mejorados, y de clases listener para callbacks.
• Soporte de métodos de intercepción.
• Búsqueda e invocación de métodos simplificada.
API de persistencia / Beans de entidad:
1. Los beans de entidad CMP son ahora POJOs y pueden ser probados o usados
fuera del contenedor.
2. Se introduce el API EntityManager para la ejecución de operaciones CRUD
sobre entidades.
3. Se estandariza un mecanismo de mapeo objeto-relacional a través de anotaciones
de metadatos. Versiones futuras de la especificación soportarán XML para este
mapeo objeto-relacional.
4. Mejora enormemente EJB-QL y añade soporte para la ejecución de SQL nativo.
EJB 3.0 hace más fácil el desarrollo de aplicaciones por que:
• Elimina la necesidad de construir interfaces EJB y descriptores de despliegue
innecesarios, y en lugar de esto, permite que los desarrolladores los generen
especificando anotaciones (similar a XDoclet). Esta aproximación libera a los
desarrolladores de crear descriptores de despliegue y de crear interfaces para los
componentes
• Simplifica los EJBs para asemejarse a los POJOs o Java Beans.
• Elimina la necesidad de tener interfaces de componentes para los EJBs.
• Los beans de entidad no requieren ninguna interfaz de componente.
• Los beans de entidad utilizarán ahora una interfaz POJO.
• Elimina la necesidad de implementar métodos callback de ciclo de vida
innecesarios.

2. Inyección de dependencias en EJB 3.0
Es difícil llegar a una definición simple para el concepto de inyección de dependencias.
En términos simples, la inyección de dependencias hace más fácil el uso de recursos
como DataSources, EJBs, contextos, etc.
En J2EE 1.4, el utilizar recursos u otro EJB desde aplicaciones EJB es complejo y
propenso a errores. Tienes que definir dependencias utilizando resource-ref o ejb-ref y
hacer una búsqueda JNDI.
En contraste, con EJB 3.0, puedes simplemente definir la dependencia en el EJB o
recurso.
Ejemplo:
@EJB AdminService bean;
public void privilegedTask() {
bean.adminTask();
}
Compatibilidad con EJB 2.x
EJB 3.0 requiere compatibilidad e interoperabilidad con EJB 2.x; las aplicaciones EJB
2.x funcionan en contenedores compatibles con EJB 3.0. El modelo de programación
para los EJB ha cambiado drásticamente entre EJB 2.x y EJB 3.0, por lo que migrar una
aplicación a la nueva especificación no resulta trivial.
Los vendedores de herramientas y de servidores de aplicaciones proporcionarán
herramientas y utilidades para hacer la migración más fácil.
Por ejemplo, la implementación previa de Oracle de EJB 3.0 soporta el concepto de
migración incremental.

3. Que se puede Hacer Con EJB3
EJB es el único estándar Java que se ocupa de la lógica de negocio del lado del servidor,
y esto es fundamental para J2EE. El comité de especificación de EJB reconoce que EJB
se quedó corto en alcanzar algunas de sus ambiciosas metas, y necesitó de una
modernización. Esta modernización está muy enfocada en la facilidad de uso,
principalmente mediante la simplificación de los requerimientos para los
desarrolladores.
Sin embargo, el comité de especificación también ha identificado un número de mejoras
funcionales críticas que facilitan el uso y la eliminación de ciertos anti-patrones J2EE.
Afortunadamente, la comunidad Java conoce ahora mucho más los problemas
relacionados a la construcción de aplicaciones web y empresariales que hace cinco años.
El comité de especificación pensó mucho como simplificar ciertos casos de usos
generales extremadamente comunes, como por ejemplo:
Actualizando datos
1. recuperar un dato
2. mostrarlo en pantalla
3. aceptar la entrada del usuario
4. actualizar el dato
5. comunicar el éxito al usuario
Ingresando nuevos datos
1. recuperar un dato
2. mostrarlo en pantalla
3. aceptar la entrada del usuario
4. crear un nuevo dato, con una asociación al primer dato
5. comunicar el éxito al usuario
Cada uno de estos casos involucra dos ciclos request/response de aplicación completos.
Ambos demuestran que el bloqueo optimista es esencial en una aplicación que requiere
alta concurrencia (ambos casos necesitarían ser implementados como una sola
comunicación atravesando dos transacciones ACID de base de datos distintas).
Un caso de uso adicional muy común, que es especialmente difícil de hacer en EJB 2.1,
dadas las limitaciones del lenguaje de consultas (EJB-QL) es el siguiente:
Listando datos
1. recuperar una lista de datos sumarizada o agrupada
2. mostrarla al usuario

4. Uso de anotaciones
Lo mas llamativo, inicialmente, son las anotaciones. No se necesita ningún deployment
descriptor. EJB 3.0 permite elegir entre el uso de anotaciones y descriptores de
despliegue en XML, pero lo esperado es que las anotaciones serán el caso mas común.
@Entity
public class Item {
private Long id;
private User seller;
private Collection<Bid> bids = new ArrayList<Bid>();
private String description;
private String shortDescription;
private Date auctionEnd;
private int version;
public Item(User seller, String desc, String shortDesc, Date end) {
this.seller = seller;
this.description = desc;
this.shortDescription = shortDesc;
this.auctionEnd = end;
}
protected Item() {}
@Id(generate=AUTO)
public Long getId() {
return id;
}
protected void setId(Long id) {
this.id = id;
}
@Column(length=500)
public String getDescription() {
return description;
}
public void setDescription(String description) {
this.description = description;
}
public Date getAuctionEnd() {
return auctionEnd;
}
protected void setAuctionEnd(Date end) {
this.auctionEnd = end;
}
@Column(length=100)
public String getShortDescription() {
return shortDescription;
}
public void setShortDescription(String shortDescription) {

5. this.shortDescription = shortDescription;
}
@JoinColumn(nullable=false, updatable=false)
public User getSeller() {
return seller;
}
protected void setSeller(User seller) {
this.seller = seller;
}
@OneToMany(cascade=ALL)
protected Collection<Bid> getBids() {
return bids;
}
protected void setBids(Collection<Bid> bids) {
this.bids = bids;
}
@Version
public int getVersion() {
return version;
}
protected void setVersion(int version) {
this.version = version;
}
public Bid bid(BigDecimal amount, User bidder) {
Bid newBid = new Bid(this, amount, bidder);
bids.add(newBid);
return bid;
}
}
La anotación @Entity le dice al contenedor que una clase es un CPM entity bean.
Las anotaciones opcionales @Column definen los mappings de las columnas para las
propiedades persistentes (si estuviéramos con los mappings de datos antiguos,
podríamos definir los nombres de las columnas en estas anotaciones).
Las anotaciones @Id seleccionan la propiedad de clave primaria del entity bean.
Las anotaciones opcionales @OneToMany definen asociaciones de uno a muchos, y
especifican un estilo de cascada de ALL.
La anotación opcional @JoinColumn define un mapping de columna para una
asociación. En este caso, obliga a la asociación a ser obligatoria e inmutable.
La anotación @Version define la propiedad utilizada por el contenedor para su bloqueo.
Quizás lo más importante a tener en cuenta aquí es que casi todas las anotaciones son
opcionales. EJB3 utiliza una configuración por excepciones, es decir que la

6. especificación define valores por defecto útiles y lógicos y así no es necesario
especificar anotaciones para el caso normal. Por ejemplo, no hemos incluido ninguna
anotación en una de las propiedades persistentes.
También llamativo es que, además de las anotaciones, Item no depende de clases o
interfaces en javax.ejb. Esto fue una meta prioritaria de EJB3, y ayuda
significativamente a reducir el "ruido".
Los entity beans no necesitan una interface local o remota, lo que también reduce el
ruido.
Ahora nuestras clases del modelo de dominio son simples JavaBeans. Esto significa que
son testeables fuera del contenedor EJB.
Ahora, miremos nuestro primer caso de uso, actualizando un Item. Asumiremos una
arquitectura co-localizada, e implementaremos nuestra lógica de negocio en un stateless
session bean con una interface de negocio local.
Una interface de negocio define operaciones visibles al cliente (vuestros session beans
pueden tener tantas interfaces de negocio como quieran). Definiremos la interface local
Auction (Subasta) asi:
public interface Auction {
public Item getItemById(Long itemId);
public void updateItem(Item item);
}
Las interfaces de negocio son locales por defecto, por lo tanto no es necesaria ninguna
anotación @Local.
Dado que nuestro entity bean Item es también un JavaBean, podemos pasarlo
directamente a una JSP (por ejemplo).
La clase bean AuctionImpl implementa esta interface:
@Stateless
public class AuctionImpl implements Auction {
@Inject public EntityManager em;
public Item getItemById(Long itemId) {
return em.find(Item.class, itemId);
}
public void updateItem(Item item) {
em.merge(item);
}
}
La anotación @Inject se utiliza para indicar que un campo de un session bean es
actualizado por el contenedor. En EJB3.0, los session beans no necesitan utilizar JNDI
para obtener referencias a recursos u otros EJBs. En este caso, el contenedor inyecta una

7. referencia al EntityManager, la interface para operaciones relacionadas con la
persistencia en entity beans.
El contenedor se encarga del bloqueo optimista en forma transparente.
Supongamos que nuestro Cliente es un servlet. El código para mostrar un Item sería
algo como esto:
Long itemId = new Long( request.getParameter("itemId") );
Auction auction = (Auction) new InitialContext().lookup("Auction");
Item item = auction.getItemById(itemId);
session.setAttribute("item", item);
Dado que el entity bean es solo un simple JavaBean, la JSP puede utilizarlo
directamente. El segundo request, que actualiza el Item, podría ser algo asi:
Item item = (Item) session.getAttribute("item");
item.setDescription( request.getParameter("description") );
item.setShortDescription( request.getParameter("shortDescription") );
Auction auction = (Auction) new InitialContext().lookup("Auction");
auction.updateItem(item);
Por lo tanto, un resumen de las simplificaciones sería:
• Las anotaciones reemplazan a los complejos descriptores de despliege en XML
• Eliminación de las home interfaces
• Eliminación de dependencias a clases e interfaces en javax.ejb
• Los entity beans son ahora simples JavaBeans, sin interfaces locales o remotas
• La inyección de dependencia reemplaza a las búsquedas JNDI