Referencia de EJB3

Los Enterprise JavaBeans han sido objeto de controversia desde el nacimiento de su segunda especificación hasta el punto que se abandono el estándar de forma mayoritaria por parte de los desarrolladores debido a la complejidad de los mismos.

Sin embargo, la tercera especificación conocida como EJB3 se presenta como un modelo de arquitectura escalable mucho menos compleja.Tiene como objetivo prioritario hacer sencillo el desarrollo de acuerdo a Java EE 5. La simplificación de la API de EJB 3 permite a los desarrolladores programar los componentes EJB como objetos ordinarios de Java con interfaces Java normales de negocio y no como componentes de peso pesado.

Ambos, componentes y código de cliente se han simplificado, y las mismas tareas pueden llevarse a cabo de una manera más sencilla, con menos líneas de código. Debido a que es mucho más simple, EJB 3.0 es también mucho más rápido para aprender a utilizar que EJB 2.1.

Problemas conocidos con EJB 2.X

La motivación de una nueva especificación para EJB surge de las limitaciones presentadas por las versiones anteriores. Entre otras, encontramos:

• Los descriptores son muy complejos. Es necesario crear múltiples descriptores de despliegue XML para un solo EJB.
• Se crean múltiples métodos callbacks usualmente inutilizados.
• Se deben crear las interfaces: remote y local, las interfaces home: remote y local, y finalmente la clase Bean.
• Deficiente manejo de excepciones. Se tienen que lanzar (throw) y atrapar (catch) gestionando varios tipos de excepciones en ocasiones innecesarias.
• Imposibilidad de testea) EJB fuera del contexto del contenedor de EJB, desde componentes como entity beans (container-managed) que son clases abstractas.
• EJB-QL tiene limitaciones en funcionalidad y dificultades de uso (principalmente en funciones de sumarización para agrupamientos, causa que propicio la aparición de extensiones propietarias del lenguaje EJB-QL). Búsqueda de otras alternativas como Toplink e Hibernate.

Características y Ventajas de EJB3

Las principales ventajas de EJB3 son:

• Permite un desarrollo mas intuitivo y sencillo de los EJB. EL objetivo prioritario de Java EE 5 es la facilidad de desarrollo. Con Java EE 5, se ha reducido la cantidad de código necesaria eliminando la gran cantidad de código repetido que se integraban en las aplicaciones y potenciando un aumento de la legibilidad y reutilización de código. Con el uso de las anotaciones se ha reducido el trabajo necesario para definir de que los descriptores de despliegue.
• EJB 3.0 hace que la programación con tecnología Enterprise JavaBeans simple mediante el uso de Plain Old Java Objects (POJOs)
• Adopta la persistencia bajo JPA, lo que lo acerca a frameworks como Hibernate e iBatis para le manejo de la persistencia. El API Java Persistence incorpora soporte para muchas de las características que los desarrolladores de EJB han estado pidiendo, incluyendo soporte para modelado de objetos mejorado, la herencia y polimorfismo, un lenguaje de consulta ampliada, metadatos para la especificación de mapeo objeto / relacional.
• Se introduce la inyección de dependencias para facilitar el uso de EJBs, recursos y variables de entorno.
• Soporte para métodos de ciclo de vida mejorados, y de clases listener para callbacks.
• Se pueden crear métodos para la intercepción.
• Búsqueda e invocación de métodos simplificada.

Nuevo modelo de Programación POJO

Un POJO (Plain Old Java Object) u objeto plano Java es un archivo java bean sin considerar las anotaciones. En la nueva especificación, la programación de EJB está dirigida por el desarrollo de POJOs. Para el caso de los beans de entidad, ya no es necesaria (opcional) la programación de una interfaz. Para los beans de sesión y los MDB si que es necesaria.

Cuando no se implementa una interfaz manualmente, el contenedor lo hace automáticamente, tomando las siguientes consideraciones: todos aquellos métodos declarados como public serán automáticamente incorporados en la interface.

Controladores en EJB3

Pueden ser locales o remotas. Ocultan las APIs de transacciones y seguridad al desarrollador Las versiones anteriores de EJB (1.x y 2.x) también proporcionaban lo anterior, pero con un modelo de programación más complejo. Existen dos tipos de controladores en EJB3 que son:

• Session Beans
• Message-Driven Beans

Sessions Beans

Los beans de sesión son componentes Java que se ejecutan en cualquiera de los contenedores de EJB autónomo o de los contenedores de EJB que forman parte del estándar de Java Platform, Enterprise Edition (Java EE) . Estos componentes de Java se suelen utilizar para modelar una tarea de usuario o de casos de uso, tales como el ingreso de información al cliente o la aplicación de un proceso que mantiene un estado conversación con una aplicación cliente. Los beans de sesión puede contener la lógica de negocio para muchos tipos de aplicaciones, tales como recursos humanos, entrada de pedidos y solicitudes de informes de gastos. Los beans de sesión pueden ser

• Sin estado(Stateless Session Beans (SLSB)): Este tipo de bean no mantiene ningún estado conversacional en nombre de una aplicación cliente.
• Estado (Stateful Session Beans (SFSB)): Este tipo de bean mantiene el estado, y un caso particular del bean se asocia con una solicitud de cliente específica. Los bean con estado puede ser vistos como una extensión a los programas cliente que se ejecutan en el servidor.

Los beans de sesión se utilizan para escribir la lógica de negocio, mantener un estado de conversación para el cliente, y el modelo de procesos de back-end o tareas del usuario que realizan operaciones de una o más empresas. Ejemplos típicos son los siguientes:

• Un bean de sesión en una aplicación de los recursos humanos que crea un nuevo empleado y le asigna al empleado a un departamento en particular
• Un bean de sesión en una aplicación de informes de gastos que crea un nuevo informe de gastos

Message-Drived Beans

Este tipo de beans basan su funcionamiento en el procesamiento asíncrono de mensajes. Para ello, utilizando el servicio JMS (Java Message Service), funciona a través del uso de sistemas de colas de mensajería. Estas colas reciben las peticiones de los diferentes clientes y son controladas mediante los Message Drived Bean, que son los encargados de procesar los mensajes existentes en cada cola y , en función del mensaje procesado, ejecutar los servicios pertinentes.

Este tipo de beans se aproximan más a la forma conceptual de los Stateless Session Bean en el sentido que son beans que no deben almacenar estado alguno. Cuando un mensaje llega a la cola el contenedor hace una llamada al método onMessage del Message Driven Bean y en este método el bean debería invocar a métodos de otros sesión bean o realizar la lógica de negocio de debiera ejecutar ( es más conveniente no tener aquí lógica de negocio, sino hacer invocaciones a métodos de otras clases que sí se encarguen de realizar lógica de negocio ). Para declarar un MDB sólo hemos de establecer la anotación @MessageDriven a una clase que implemente la interface MessageListener, e indicar el nombre de la cola del contenedor ( la cuál es accesible vía JNDI ) que va a controlar el MDB. Veamos un ejemplo :

@MessageDriven( mappedName = "jms/Queue" )
public class AsynchronousService implements MessageListener {

    public void onMessage( Message message ) {
        TextMessage textMessage = (TextMessage)message;
        System.out.println( textMessage.getText() );
    }
}

Tipos de beans de la especificación EJB3

En la especificación EJB3 los cuatro tipos de EJB sufren algunos cambios. Una de las grandes ventajas es que todos los objetos de servicios son POJOs (objetos Java planos), como por ejemplo los session beans, o los message-driven beans. Ninguno de los cuatro tipos requiere home e interface.

Stateless Session Beans

Beans de sesión sin estado se compone de los siguientes elementos:

• Interfaz de negocio, que contienen la declaración de los métodos de negocio que van a ser visible a las aplicaciones cliente
• Una clase de bean, que contiene la implementación de métodos negocio que dan soporte a la ejecución

Interfaz de negocio de un bean de sesión sin estado

Una interfaz de sesión de trabajo sin estado es una interfaz estándar de Java que no le ofrece ninguna interfaz específica de EJB. Esta interfaz tiene una lista de definiciones de métodos de negocio que estará disponible para la aplicación del cliente. Cada bean de sesión debe tener una interfaz de negocio que pueden ser implementadas por la clase bean, generado en tiempo de diseño con herramientas como Oracle JDeveloper, NetBeans, o el eclipse, o generados en tiempo de despliegue por el contenedor EJB. Las interfaces de negocios pueden utilizar las anotaciones, así, como se describe en la siguiente lista:

• La anotación @Remote puede utilizarse para referirse a la interfaz de negocio a distancia.
• La anotación @Local puede ser usado para denotar la interfaz de negocio local.

Si no se especifica la anotación en la interfaz, entonces por defecto, el interfaz local.

Si su arquitectura tiene una condición por la cual la aplicación cliente tiene que ejecutarse en una máquina diferente JavaVirtual (JVM) de la que se utiliza para ejecutar los beans de sesión en un contenedor EJB, entonces necesita para utilizar la interfaz remota. La JVM distinta, puede ubicarse en la misma máquina física o en máquinas separadas. Si su arquitectura de aplicaciones va a utilizar la misma JVM, tanto para la aplicación de cliente y los beans de sesión,se debe utilizar la interfaz local.

Clase Bean

Hay que asegurar que los métodos implementados en la clase bean debe corresponder a los métodos de negocios declarado en el interfaces remotas o locales. Ellos emparejan basándose en la convención de que tienen el mismo nombre y firma del método. Otros métodos de la clase bean que no cuentan con la declaración correspondiente en las interfaces de negocio serán privados para los métodos de la clase bean. Un stateless session bean se define solo añadiendo la anotación @Stateless.

@Stateless
public class TraderBean implements Trader{
   public void buy (String symbol, int quantity){
     System.out.println("Buying "+quantity+ " of "+ symbol);
   }
   public void sell (String symbol, int quantity);{
     System.out.println("Selling "+quantity+ " of "+ symbol);
   }
}

Métodos Callback

Habrá algunos casos o casos de uso en el que la aplicación que utiliza los beans de sesión requiere un control preciso sobre cosas como la creación de un objeto, la eliminación de objetos, y así sucesivamente. Por ejemplo, el bean de sesión SearchFacade posible que tenga que realizar alguna base de datos de inicialización cuando se crea, o cerca de algunas conexiones de base de datos cuando se destruye. La aplicación puede hacerse con el control preciso sobre las diferentes etapas del ciclo de vida del bean a través de métodos conocidos como métodos de devolución de llamada(callback). Un método de devolución de llamada puede ser cualquier método en el bean de sesión que tiene anotaciones de devolución de llamada. El contenedor EJB llama a estos métodos en las fases adecuadas del ciclo de vida del bean ( creación y destrucción).

A continuación se presentan los dos tipos de anotaciones de devoluciones de llamada para beans de sesión sin estado:

• PostConstruct: Se la designa con la anotación @PostContruct. Cualquier método de la clase de bean se puede marcar con esta anotación. ocurre después de cualquier inyección de dependencia por parte del contenedor y antes de la invocación del primer método de negocio en el bean
• PreDestroy: Se la designa con la anotación PreDestroy. Una vez más, cualquier método en la clase bean se puede marcar con esta anotación. Ocurre al momento en que la instancia de bean es destruído.

Stateful Session Beans

Al igual que los beans de sesión sin estado, los beans con estado comprenden una clase bean y una interfaz de negocio. Una sesión se caracteriza por mantener un estado interno. El cliente puede invocar llamadas a métodos de un mismo bean stub. Estas llamadas son dirigidas a la misma instancia del bean en el contenedor. Por lo tanto todos los valores de los atributos en la instancia del bean se mantienen mientras el cliente mantenga la referencia al bean stub.

Interfaz de negocio

Las interfaces de negocio para beans de sesión con estado son similares a aquellas definidas para los beans de sesión sin estado, y se anotan en la misma forma, usando anotaciones para definir las interfaces locales y remotos+

Clase Bean

Una clase de bean de sesión con estado es cualquier clase estándar de Java que tiene una anotación @Stateful. Si se utilizan los descriptores de despliegue en lugar de anotaciones, la clase bean debe designarse como un bean de sesión con estado. En el caso de modo mixto, en el que está utilizando descriptores de anotaciones e implementación, la anotación @Stateful debe especificar si las anotaciones de cualquier otra clase se especifican en la clase.

@Stateful
public class TraderBean implements Trader, Serializable {
  public String symbol = "";
  public int quantity = 0;

  public void buy (String symbol, int quantity){
    System.out.println("Buying "+quantity+ " of "+ symbol);
  }
  public void sell (String symbol, int quantity);{
    System.out.println("Selling "+quantity+ " of "+ symbol);
  }
  public String getSymbol(){ return symbol; }
  public int getQuantity(){ return quantity; }
  ...
}

Métodos Callback

Los métodos deben ser públicos, sin retorno (void), y sin parámetros.Ademas de los métodos presentados en los beans de sesión sin estado, aparecen tres nuevos tipos de métodos de devoluciones de llamada

• @PrePassivate: invocado antes de que el contenedor desactive (passivave) el bean, el contenedor elimina temporalmente el bean y lo salva en memoria secundaria (javax.ejb.PrePassivate)
• @PostActivate: invocado después de que el contenedor mueve el bean de memoria secundaria a estado activo (active) (javax.ejb.PostActivate)
• @Init: designa métodos de inicialización para un session bean.

EntityBeans

Un Entity Bean es una clase ( POJO ) que representa una tabla de una base de datos, y cada instancia de esta clase representa un registro de la tabla, es decir, con los entity beans lo que conseguimos es crear un mapeo entre las propiedades de una clase y los campos de una tabla. Además de este mapeo también vamos a poder especificar las relaciones que tienen las clases entre sí ( uno a uno, uno a muchos, muchos a uno y muchos a muchos ).

Todo Entity Bean debe de tener una clave primaria que identifica a ese registro de forma única dentro de la tabla. Todas estas configuraciones las vamos a realizar a través de anotaciones, y el API que se encarga de gestionar todos los aspectos relativos a la persistencia es JPA ( Java Persistent API ).

La anotación asociada a este tipo de EJB es el @Entity y todas sus propiedades y campos en la clase entity bean no marcadas con la anotación @Transient son consideradas persistentes (mapeadas en BBDD).

Entity Class

Una clase entity bean se denota con la anotación @Entity. Debe tener un constructor sin argumentos, además puede tener más de un constructor con parámetros. El constructor que no tiene parámetros debe ser definido public o protected (quedar accesible).

Message-Driven Beans

Este tipo de beans esta pensados para la mensajería asincrónica. Son unos beans con una estrecha relación con JMS (Java Messaging Service). De hecho la mayoría de los MBD son consumidores de mensajes JMS. Dado que para trabajar con ellos se usan clases de la API JMS.

Los MDB son desplegados en un Servidor de Aplicaciones, y asociados a un destino JMS. Al llegar un mensaje a dicho destino, se ejecuta automáticamente el método onMessage del MDB, en donde se recibe por parámetro el mensaje que llegó, y se pueden entonces realizar las acciones correspondientes.

Interfaz de negocio

La interfaz de negocio es la interfaz message-listener que es determinada por el tipo de mensajería en uso para el bean. Cada MDB debe implementar una interfaz message-listener apropiada para el tipo de mensajería que éste soporta, o podría designar su interfaz message-listener usando la anotación @MessageDriven.

Clase Bean

La clase bean MDB será señalada con la anotación @MessageDriven que especifica la cola de mensajes que el MDB monitorea. Esta clase necesita implementar la interfaz MessageListener, que define sólo al método onMessage(). Cuando un mensaje llega a la cola de mensajes del MDB el contenedor llama al método onMessage() de esta clase bean y le pasa el mensaje recibido mediante un parámetro.

Para enviar un mensaje, se necesita referenciar al MDB, el cliente usa el API estándar JMS para obtener la cola de mensajes mediante su nombre JNDI (cola/mdb) y entonces el envía el mensaje a la cola.

Métodos Callback

Se soportan dos tipos de métodos de devolución de llamada: PostConstruct y PreDestroy .

Transacciones

Como definición básica, una transacción es un conjunto de tareas que deben ser tratados como unidad inseparable. Esto significa que cada tarea que forma parte de la transacción debe tener éxito para que la operación tenga éxito. Si cualquiera de las tareas no se cumple, la operación falla.

Además a esta propuesta de valor de todo o nada, las transacciones deben garantizar un grado de fiabilidad y robustez. Una transacción con éxito (commited) se ha comprometido, lo que significa sus resultados se hacen permanentes, mientras que una transacción que se revierte (rolling back), es como si no hubiera existido.

Las propiedades ACID

La sigla ACID significa atomicidad, coherencia, aislamiento y durabilidad. Todos los sistemas transaccionales se dice que exhiben estas cuatro características. Examinaremos cada uno de estas características.

Atomicidad

Las transacciones son atómicas por naturaleza; o bien se confirman o se deshacen juntos. En términos de codificación, que se agrupa en un cuerpo de código arbitrario en el marco de una transacción. Si algo inesperado e irrecuperable ocurre durante la ejecución del código, el resultado de la tentativa de ejecución es completamente deshecho de modo que no tiene ningún efecto en el sistema. De lo contrario, los resultados de una ejecución exitosa llega a ser permanente.

Consistencia

Esta es la más delicada de las cuatro propiedades, porque implica más que escribir código. Esta es la forma más común de describir la propiedad de coherencia: si el sistema se encuentra en un estado coherente con las reglas de negocio antes de una transacción comienza, si no permanece en un estado coherente después de la transacción se revierte o compromete.

Un corolario de esta afirmación es que el sistema no necesita estar en un estado coherente durante la transacción. Piense en una transacción como una caja de arena, mientras usted asegurare de que todas las reglas de negocio en el sistema permanecerán intactas después de que se ejecuta la última línea de código en una transacción, no importa si está en un estado incoherente en un momento arbitrario de la transacción.

En el mundo real, el establecimiento de normas y restricciones en la base de datos (como las claves principales, relaciones de clave externa, y el campo restricciones) garantiza la coherencia de manera que las transacciones encontrarse con condiciones de error son rechazados y el sistema se devuelve a su estado previo a la transacción.

Aislamiento

Si usted entiende la sincronización de subprocesos o el bloqueo de la base de datos , ya sabe lo que es el aislamiento. En esencia, el administrador de transacciones se asegura de que nadie toca sus datos mientras está en la transacción.

Este concepto es especialmente importante en sistemas concurrentes donde cualquier número de procesos pueden estar tratando de manipular los mismos datos en un momento dado. Por lo general, el aislamiento es garantizado por el uso de "cerrojos" de bases de datos de bajo nivel . El administrador de transacciones inserta algún tipo de bloqueo en los datos accedidos por una transacción de modo que ningún otro proceso puede modificarlos hasta que la transacción esté terminada.

Durabilidad

La durabilidad de transacciones asegura ,que una vez cometida, es permanente. Esto se suele implementar mediante el uso de registros de transacciones en el servidor de base de datos. En esencia, la base de datos mantiene un registro actualizado de todos los cambios realizados en los datos por una transacción antes de que lo comete. Esto significa que incluso si se produce un error en el servidor durante una confirmación, una vez que la base de datos se recupera de los cambios de error puede ser revertido para volver a aplicar correctamente. Los cambios realizados durante la transacción se aplican de nuevo por la ejecución de las entradas correspondientes del registro de transacciones.

Manejo de transacciones en EJB

El soporte a la gestión de transacciones en EJB se proporciona a través de la API de transacción de Java (JTA). De hecho, en su mayor parte, como un desarrollador de EJB probablemente tendrá que conocer una sola interfaz de JTA: javax.transaction.UserTransaction. Esto es debido a que el contenedor se encarga de la mayoría de los detalles detrás de la gestión de transacciones las escenas. Como desarrollador de EJB, sólo tiene que decirle al contenedor cuando comienza la transacción y cuando termina y si debe retroceder o finalizar.

Hay dos formas de utilización de las transacciones en EJB. Ambos proporcionan abstracciones sobre JTA,una menor y otra un mayor grado. La primera es manejo declarativo de transacciones a través de transacciones gestionadas por contenedor (CMT), lo que se puede hacer a través de anotaciones o del descriptor de despliegue.

Por otra parte, transacciones gestionadas por beans (BMT) es preciso gestionarlas transacciones de forma programática. Es importante señalar que en esta versión de EJB, solo los bean de sesión y los bean de mensajes ofrecen soporte a ambos tipos de gestión de transacciones. La API JPA de EJB 3 no depende directamente de la CMT o bien BMT, pero de forma transparente puede conectarse en cualquier entorno transaccional, mientras que utiliza dentro de un contenedor Java EE.

Transacciones manejadas en el contenedor

En CMT, el contenedor, inicia, realiza commits o rollbacks sobre transacciones en nuestro nombre Los límites de la transaccion en las declarativas están marcados por el inicio y fin de los métodos de negocio de EJB. El contenedor comienza una transacción JTA antes de que se llame a un método, invoca al método y dependiendo de lo que ocurra en la llamada, realiza un commit o deshace la transacción.

Todo lo que debemos de hacer es comunicarle al contenedor como manejar la transacción usando anotaciones o descriptores de fichero y preguntar por hacer rollback cuando sean necesarios. Por defecto, el contenedor asume que esta utilizando CMT en todos los métodos de negocio.

La anotación @TransactionManagement

Esta anotación especifica cuando se usa CMT o BMT. En el caso de utilizar CMT especificamos el valor TransactionManagementType.CONTAINER para indicar que el contenedor es el encargado de manejar la transacción.

Si queremos manejar transacciones de forma programática, debemos especificar como valor TransactionManagementType.BEAN

La anotación @TransactionAttribute

Aunque el contenedor es el que realiza la mayor parte de la carga en la transacción CMT, todavía necesitas decirle al contenedor como debe manejar las transacciones. Para entender lo que esto significa, considere el hecho de que una transacción que envuelve a un método de un bean puede ser inicializada por el contenedor de forma específica cuando se produce una llamada al método. La anotación @TransactionAttribute le dice al contenedor como manejar la situación. Mediante esta anotación podemos definir si se aplica de forma individual aun método de un bean o a todos los métodos del mismo. Si una anotación se aplica a un bean , todos los métodos de negocio heredan el valor específico del atributo transacción.

Persistencia con EJB3 y JPA

Se han introducido cambios para mejorar el tratamiento con respecto a la persistencia por parte de EJB3. A continuación se resumen las mejoras conseguidas:

• Los beans de entidad CMP son ahora POJOs y pueden ser probados o usados fuera del contenedor.
• Se introduce el API EntityManager para la ejecución de operaciones CRUD sobre entidades.
• 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.
• Mejora enormemente EJB-QL y añade soporte para la ejecución de SQL nativo.

El Java Persistence API (JPA) es la solución a la capa de persistencia propuestas por la plataforma Java EE. Los cambios introducidos para la persistencia dentro de EJB3 son bastante significativos. De hecho, aparte de algunos nombres de patrones y conceptos, JPA tiene muy poco en común con el modelo de bean de entidad de EJB2. JPA no sigue el principio del modelo contenedor, en su lugar, se sigue un paradigma similar a JDBC, Javamail o JMS. La interfaz EntityManager define la API para la persistencia mientras que las entidades de JPA especifica como mapea la aplicación los datos y las relaciones en los bases de datos.

Al contrario que EJB2, JPA es una tecnología basada en POJO. Esto es, se pueden guardar los datos mantenidos en un objeto dentro de la base de datos, nuestros objetos ya no requieren la implementación de una interfaz que extienda a la clase. De hecho, los objetos persistidos no necesitan contener instrucciones de JPA. Todo lo que se necesita hacer en el código es mantener el modelo como POJO y usar anotaciones o el descriptor XML para dar al proveedor de persistencia la siguiente información:

• Que son cada objeto del dominio (usando, por ejemplo anotaciones @Entity y @Embedded)
• Como identifcar unicamente a un objeto persistido del dominio (por ejemplo, usando @Id)
• Que relaciones existen entre objetos (por ejemplo, usando las anotaciones @OneToOne, @OneToMany, y @ManyToMany)
• Como se mapea el objeto de dominio alas tableas de la base de datos( usando algunas anotaciones como @Table, @Column, o @JoinColumn)

La interfaz EntityManager

En cierto sentido, el EntityManager es el puente entre los mundos OO y relacional. Cuando se solicita que sea creada una entidad de dominio , el EntityManager es el encargado de trasladar la entidad a un registro de base de datos nueva. Cuando se solicita que una entidad esté actualizado, es el encargado de localizar los datos relacionales que corresponde a la entidad y los actualiza. Asimismo, el EntityManager elimina los datos relacionales cuando se solicita que se elimine la entidad se suprime.

Desde el otro punto de vista, cunado su petición es que una entidad sea almacenada ne la base de datos, Entitymanager crea el objeto entidad y lo rellena con su datos relacionales. Ademas de proveer de estas operaciones , el EntityManager trata de mantener sincronizadas las entidades con la base de datos. A continuación una tabla resumen de la interfaz:

Uso de los interceptores

EJB 3 da soporte al uso de los interceptores. Un interceptor tiene la función específica de detectar una llama a un método de negocio o detectar un evento callback (de vuelta atrás) del ciclo de vida. Un interceptor puede ser un método que se encuentre definido en la clase bean o como una clase aparte. Se permite definir interceptores mediante el uso de anotaciones, en este caso se utiliza @Interceptors.

El uso de los interceptores en los session beans y/o message driven beans. Tiene como característica carecer de estado. Además, el ciclo de vida de una instancia de interceptor es la misma que el de la instancia del bean asociado a él. Una clase interceptor soporta inyección de dependencia.

La interfaz InvocationContext

Es el medio para almacenar información entre los métodos de un interceptor y además entre interceptores. Esta información no es compartida a través de los métodos de negocio o eventos callback del ciclo de vida.

public interface InvocationContext
{
  public Object getTarget();
  public Method getMethod();
  public Object[] getParameters();
  public void setParameters(Object[] params);
  public java.util.Map<String, Object> getContextData();
  public Object proceed() throws Exception;
}

• getTarget() : Devuelve el método de la instancia bean en que se llama al interceptor.
• Si setParameters() ha sido llamado, getParameters() devuelve los valores de los parámetros configurados. El tipo de cada parámetro necesita ser compatible con los tipos para el método de negocio.
• Proceed() : causa la invocación del próximo método. Retorna el resultado de esa invocación.
  • Si el método de negocio devuelve void entonces proceed retorna null.
  • Para un método callback de ciclo de vida, si no hay métodos callback definidos en el bean, entonces proceed retorna null.