Enterprise Java Beans

¿Qué es un EJB?
 Enterprise Java Beans (EJB) es una plataforma para
construir aplicaciones de negocio portables, reusables
y escalables usando el lenguaje de programación
Java. Desde el punto de vista del desarrollador, un EJB es
una porción de código que se ejecuta en un contenedor
EJB, que no es más que un ambiente especializado
(runtime) que povee determinados componentes de
servicio.
¿Qué es un EJB?
 Los EJBs pueden ser vistos como componentes, desde el
punto de vista que encapsulan comportamiento y permite
reutilizar porciones de código, pero también pueden ser
vistos como un framework, ya que, desplegados en un
contenedor, proveen servicios para el desarrollo de
aplicaciones enterprise, servicios que son invisibles para
el programador y no ensucian la lógica de negocio con
funcionalidades trasversales al modelo de dominio (a
menudo requerimientos no funcionales o aspectos).
¿Qué es un EJB?
  En la especificación 3.0, los EJB no son más que
POJOs (clases planas comunes y corrientes de Java)
con algunos poderes especiales implícitos, que se
activan en runtime cuando son ejecutados en
un contenedor de EJBs.
En Resumen
 Componentes gestionados por un contenedor del servidor
de aplicaciones que permite gestionar el acceso a recursos
(bases de datos, colas de mensajes, ficheros, etc) y
proporcionar servicios (seguridad, transacciones,
mensajería, nombres) de forma sistemática y optimizada
 La utilización de EJB simplifica el desarrollo de
aplicaciones web y permite construir aplicaciones
escalables
Los servicios que debe proveer el contenedor
de EJBs
Los servicios que debe proveer el contenedor
de EJBs
 Los servicios que debe proveer el contenedor de EJBs deben ser
especificados por el programador a través de metadata de
configuración que puede escribirse como:
 Anotaciones de Java5 intercaladas en el código de las clases.
 Descriptores XML (archivos XML separados).
 A partir de EJB 3 se puede usar cualquiera de estas dos técnicas. Las
técnicas no son exclusivas, pueden coexistir anotaciones con
descriptores XML y, en el caso de superponerse la metadata, los
XML tendrán prioridad y podrán sobreescribir las anotaciones.

 Algunos ejemplos de los contenedores más populares que hay

actualmente en el mercado son: Glassfish, de Sun
Microsystem, JBoss Application Server, de Red Hat, BEA Weblogic
Server y Oracle Application Server, ambos
deOracle y WebSphere de IBM.
Anotaciones
 Una anotación transforma un simple POJO en un
EJB.
Especificación de EJBs
 Las EJBs se pueden inyectar en otros objetos gestionados
por el servidor, como los servlets, utilizando la anotación
@EJB
 El objeto en el que se inyecta la EJB se llama cliente
 Las EJBs pueden ejecutarse en el módulo del cliente o en
módulos específicos, que pueden incluso estar en
ordenadores diferentes del del cliente
Tipos de EJBs
 Existen tres tipos de EJBs:

 Session Beans

 Message-Driven Beans (MDBs)

 Entity Beans
Tipos de EJBs
 Session Beans: en una aplicación enterprise típica, dividida
en cuatro grandes capas o layers (presentación, lógica de
negocio (business logic), persistencia y base de datos
(DBMS)), los Session Beans viven en la lógica de negocio.
Hay dos grandes tipos de Session Beans: Stateless y Stateful,
el primero no conserva el estado de ninguno de sus atributos
de la invocación de un método a otro y el segundo conserva
el estado a lo largo de toda una sesión. Los Session Beans
Stateless son los únicos que pueden exponerse como web
services.
Session Beans
 Los Session Beans son invocados por el cliente con el
propósito de ejecutar operaciones de negocio específicas,
como por ejemplo podría ser chequear la historia
crediticia del cliente de un banco. El
nombre sesión implica que la instancia del bean estará
disponible durante una unidad de trabajo (unit of work)
y no sobrevivirá a una caída del servidor. 
 Un bean de sesión sirve para modelar cualquier
funcionalidad lógica de una aplicación.
Session Beans
 EJB de Sesión (Session EJBs): gestionan el flujo de la información en
el servidor. Generalmente sirven a los clientes como una fachada de los
servicios proporcionados por otros componentes disponibles en el
servidor. Puede haber dos tipos:
 Con estado (stateful). En un bean de sesión con estado, las variables de instancia
del bean almacenan datos específicos obtenidos durante la conexión con el
cliente. Cada bean de sesión con estado, por tanto, almacena el estado
conversacional de un cliente que interactúa con el bean. Este estado
conversacional se modifica conforme el cliente va realizando llamadas a los
métodos de negocio del bean. El estado conversacional no se guarda cuando el
cliente termina la sesión.
 Sin estado (stateless). Los beans de sesión sin estado son objetos distribuidos
que carecen de estado asociado permitiendo por tanto que se los acceda
concurrentemente. No se garantiza que los contenidos de las variables de
instancia se conserven entre llamadas al método.
¿Cuando usar un session bean?
 En general, se debería usar un session bean cuando:
 En un momento determinado, sólo un cliente tiene acceso a la instancia del bean.
 El estado del bean no es persistente, existiendo solamente por un período corto
de tiempo (tal vez un par de horas)
 El bean implementa un web service.
 Los Stateful Session Beans son apropiados si se cumple alguna de las siguientes
condiciones:
 El estado del bean representa la interacción entre el bean y un cliente específico.
 El bean necesita mantener información acerca del cliente a través de varias invocaciones
a varios métodos.
 El bean intermedia entre el cliente y otro componente de la aplicación, presentando al
cliente una vista simplificada.
 El bean maneja el workflow de varias aplicaciones.
 Para mejorar la performance, se debe escoger stateless session bean si se cumple alguna
de las siguientes condiciones:
 El estado del bean no tiene datos específicos del cliente
 En una invocación a un método, el bean ejecuta tareas específicas para todos los
clientes.
Session Beans
 Ciclo de vida de un Stateful Session Bean
Ciclo de vida de un Stateful Session Bean
 Mientras este en la etapa “ready”, el contenedor EJB puede decidir pasivar el bean,
moviendo de la memoria al almacenamiento secundario (usualmente, el disco
rígido). El contenedor EJB invoca el método anotado con @PrePassivate, si existe,
inmediatamente antes de pasivarlo. Si el cliente invoca un método business mientras
el EJB esta en el estado pasivado, el contenedor ejecutara el método anotado con
@PostActivate, si existe, y luego mueve al bean al estado “ready”.
 Hay tres maneras de que termine el ciclo de vida de un stateful session bean:
 Que se llame a un método anotado con la anotación @Remove, lo que determina que si se llama a dicho
método, al terminar la ejecución del mismo se destruye el bean. NOTA: la anotación @Remove no
garantiza que el método sea llamado, sólo determina que si se lo llama, una vez terminada su ejecución
se destruya el bean.
 Que se llame al método remove() en un EJBObject creado a partir de la interfaz Adapted Home del
bean.
 Que un método de negocios del bean lance una RuntimeException.
 Al final del ciclo de vida, es decir, al darse cualquiera de estas tres condiciones, el
contenedor EJB ejecuta el método anotado con @PreDestroy, si existe. Luego de
esto, el bean esta listo para ser recolectado por el GC y no puede volver a llamarse
salvo que se cree una nueva instancia del mismo
Session Bean
 Ciclo de vida de un Stateless Session Bean: Debido a
que un bean stateless nunca es pasivado, su ciclo de vida
tiene solo dos etapas: “nonexistent” y “ready”. La figura a
continuación muestra las etapas de un session bean
stateless.
Ciclo de vida de un Stateless Session Bean
 El cliente inicia el ciclo de vida cuando obtiene una
referencia al bean stateless. El contenedor “inyecta” las
dependencias y luego invoca al método anotado con
@PostConstruct, si existe. Al final del ciclo de vida, el
contenedor EJB llama al método anotado con
@PreDestroy, si existe. Luego de esto, la instancia del
bean esta lista para ser recolectada por el GC.
Tipos de EJBs
 Message-Driven Beans (MDBs): también viven en la lógica de
negocio y los servicios que proveen son parecidos a los Session
Beans, con la diferencia de que los MDBs son usados para
invocar métodos de forma asincrónica. Cuando se produce la
invocación de un método de un MDB desde un cliente, la
llamada no bloquea el código del cliente y el mismo puede
seguir con su ejecución, sin tener que esperar indefinidamente
por la respuesta del servidor. Los MDBs encapsulan el popular
servicio de mensajería de Java, JMS. Hay una analogía muy
interesante en el libro que dice que los MDBs son a JMS lo
que JDBC es a SQL.
Message-Driven Beans (MDBs)
 Los MDBs también procesan lógica de negocio, pero un cliente
nunca invoca a un método de un MDB directamente. El
sistema de mensajería asincrónica propone la utilización de una
capa intermedia en la comunicación entre el productor y el
consumidor del mensaje. En EJB 3, esta capa se
llama MOM (Message-oriented middleware).
 Básicamente la MOM es un software que permite funcionar
como servidor de mensajería, reteniendo los mensajes del
productor y enviándolos posteriormente al consumidor en el
momento en que esté disponible para recibirlo. (Es un
funcionamiento similar al de un servidor de correo
electrónico.) Algunos ejemplos típicos de servidores de
mensajería son WebSphere MQ de IBM,SonicMQ, Advanced
Queueing de Oracle y TIBCO.
Message-Driven Beans (MDBs)
Diferencias con los Session Beans
 ¿Que hace Diferente a un Message con respecto un Session?
La mayor de las diferencias es que el cliente no accede a los
message beans a través de interfaces. A diferencia de un
session bean, los message beans solamente tienen una clase
bean.
 Igualmente, en muchas maneras, un message bean se asemeja a
un stateless session bean:
 Un message bean no mantiene estado conversacional
 Todas las instancias de un message bean son equivalentes.
 Un único message bean puede procesar múltiples clientes.

 Una variable de instancia de un message bean puede contener

estados que sean únicos entre los clientes.
 El componente clientes no invoca directamente a los message
beans, sino que lo hacen enviando un mensaje JMS.
Message-Driven Beans (MDBs)
 Un message bean tiene las siguientes características:
 Se ejecutan con la recepción de un mensaje de un cliente.
 Son invocados asincrónicamente
 Su duración es relativamente corta.
 No representan datos.
 Pueden ser transaccionales.
 Son stateless.
 Cuando se recibe un mensaje, el contenedor llama el método
onMessage para procesar el mensaje. El método onMessage
normalmente castea el mensaje a alguno de los 5 tipos de mensajes
JMS y procesa el mismo. El método onMessage puede llamar a
métodos helpers, o puede invocar un session bean para procesar la
información del mensaje o guardarlo en la base de datos.
 Un mensaje puede ser entregado a un message bean dentro de una
transacción, en ese caso, todas las operaciones del método
onMessage son parte de una única transacción.
Message-Driven Beans (MDBs)
¿Cuando se usan?
 Los session beans permiten enviar mensajes JMS y
recibirlos sincrónicamente, pero no asincrónicamente.
Para evitar atar los recursos del servidor, no se debe usar
recepciones sincrónicas (las cuales son bloqueantes)
cuando se utilizan mensaje JMS. Para recibir mensajes
asincrónicamente, se debe utilizar message Beans.
Naming Conventions
 Debido a que un enterprise bean esta compuesto de
muchas partes, es útil (incluso necesario) seguir una
nomenclatura de nombres para la aplicación. La tabla a
que se muestra a continuación define la convención
establecida por Sun:
¿Qué servicios proveen los EJBs?
 Integración: Proveen una forma de acoplar en tiempo de ejecución diferentes componentes,
mediante simple configuración de anotaciones o XMLs. El acoplamiento se puede hacer
mediante Inyección de Dependencia(DI) o usando JNDI, como se hacía en EJB 2 (explicaré
el concepto de Inyección de Dependencia en detalle en el próximo post). La integración es un
servicio que proveen los beans de sesión y los MDBs.
 Pooling: El contenedor de EJBs crea para componentes EJB un pool de instancias que es
compartido por los diferentes clientes. Aunque cada cliente ve como si recibiera siempre
instancias diferentes de los EJB, el contenedor está constantemente reusando objetos para
optimizar memoria. El pooling es un servicio que se aplica a los Stateless Session Beans y a los
MDBs.
 Thread-safely: El programador puede escribir componentes del lado del servidor como si
estuviera trabajando en una aplicación sencilla con un solo thread (hilo). El contenedor se
encarga de que los EJBs tengan el soporte adecuado para una aplicación multi-usuario (como
son en general las aplicaciones enterprise) de forma transparente, asegurando el acceso seguro,
consistente y performante. Aplica a los beans de sesión y a los MDBs.
 Administración de Estados: El contenedor de EJBs almacena y maneja el estado de
un Stateful Session Beande forma transparente, lo que significa que el programador puede
mantener el estado de los miembros de una clase como si estuviera desarrollando una
aplicación desktop ordinaria. El contenedor maneja los detalles de las sesiones.
¿Qué servicios proveen los EJBs?
 Mensajería: Mediante los MDBs es posible desacoplar por completo dos
componentes para que se comuniquen de forma asincrónica, sin reparar demasiado
en los mecanismos de la JMS API que los MDBs encapsulan.
 Transacciones: EJB soporta el manejo de transacciones declarativas que permiten
agregar comportamiento transaccional a un componente simplemente usando
anotaciones o XMLs de configuración. Esto significa que cuando un método de un
EJB (Session Bean o MDB) se completa normalmente, el contenedor se encargará
decommitear la transacción y efectivizar los cambios que se realizaron en los datos
de forma permanente. Si algo fallara durante la ejecución del método (una
excepción o cualquier otro problema), la transacción haría unrollback y es como si
el método jamás se hubiera invocado.
 Seguridad: EJB soporta integración con la Java Authentication and Authorization
Service (JAAS) API, haciendo casi transparente el manejo transversal de la
seguridad. Aplica a todos los Session Beans.
¿Qué servicios proveen los EJBs?
 Interceptors: EJB introduce un framework liviano y simple
para AOP (programación orientada a aspectos). No es tan robusto y completo como
otros, pero es lo suficientemente útil para que sea utilizado por los demás servicios
del contenedor para brindarnos de forma invisible los crosscutting concerns de
seguridad, transacciones, thread-safely. Además, nosotros, como programadores,
podemos agregar nuevos aspectos como logging o auditoria y demás de forma
configurable.
 Acceso Remoto: Es posible acceder de forma remota a distintos EJBs de forma
sencilla, simplemente mediante la Inyección de Dependencia. El procedimiento
para inyectar un componente local o uno remoto es exactamente el mismo,
abstrayéndonos de las complicaciones especificas de RMI o similares. Este servicio
aplica únicamente a los Session Beans.
 Web Services: Un Stateless Session Bean puede publicar sus métodos como web
services mediante una sencilla anotación.
 Persistencia: EJB 3 provee la especificación JPA para el mapeo de objetos
(Entities) a tablas.
 Catching and Performance: JPA provee de forma transparente un importante
número de servicios que permiten usar un caché de entidades en memoria y una
lectura y escritura sobre la base de datos altamente performante.
Funcionamiento de un Enterprise JavaBean
 Los EJB se disponen en un contenedor EJB dentro del servidor de
aplicaciones. La especificación describe cómo el EJB interactúa con
su contenedor y cómo el código cliente interactúa con la
combinación del EJB y el contenedor.
 Cada EJB debe facilitar una clase de implementación Java y
dos interfaces Java. El contenedor EJB creará instancias de la clase
de implementación Java para facilitar la implementación EJB. Las
interfaces Java son utilizadas por el código cliente del EJB. Las dos
interfaces, conocidas como interfaz "home" e interfaz remota,
especifican las firmas de los métodos remotos del EJB. Los métodos
remotos se dividen en dos grupos:
 métodos que no están ligados a una instancia específica, por ejemplo
aquellos utilizados para crear una instancia EJB o para encontrar una
entidad EJB existente. Estos métodos se declaran en la interfaz "home".
 métodos ligados a una instancia específica. Se ubican en la interfaz
remota.
Funcionamiento de un Enterprise JavaBean
 Dado que se trata simplemente de interfaces Java y no de
clases concretas, el contenedor EJB genera clases para
esas interfaces que actuarán como un proxy en el cliente.
El cliente invoca un método en los proxies generados que
a su vez sitúa los argumentos método en un mensaje y
envía dicho mensaje al servidor EJB. Los proxies
usan RMI-IIOP para comunicarse con el servidor EJB.
 El servidor llamará a un método correspondiente a una
instancia de la clase de implementación Java para manejar
la llamada del método remoto.
Interfaz "Home"
 La interfaz "Home" permite al código cliente manipular
métodos de clase del EJB que no están asociados a
ninguna instancia particular. La Interface "Home" permite
crear las instancias de EJB de entidad o sesión a través del
método create que puede ser sobrecargado.
 La especificación EJB 1.1 establece el tipo de métodos de
clase que se pueden definir como métodos que crean un
EJB o para encontrar un EJB existente si es un "bean" de
entidad.
 La especificación EJB 2.0 permite a los desarrolladores de
aplicaciones definir nuevos métodos de clase sin limitarse
a su sola creación o borrado.
Interfaz remota
 La interfaz remota especifica los métodos de instancia
públicos encargados de realizar las operaciones.
 Una sesión bean puede implementar múltiples interfaces,
con cada interfaz apuntada por un tipo de cliente diferente.
La interfaz local es para aquellos clientes que corren en la
misma máquina virtual que el contenedor EJB. La interfaz
remota es para clientes remotos. Frente a una consulta del
cliente, el contenedor retorna un stub serializado del
objeto que implementa la interfaz remota. El stub conoce
cómo pasar llamadas a procedimientos remotos (RPCs) al
servidor. Este tipo de interfaz es también un POJO.
Clase de implementación EJB
 Las clases de implementación EJB las suministran los
desarrolladores de aplicaciones, que facilitan la lógica de
negocio ("business logic") o mantienen los datos
("business data") de la interfaz de objeto, esto es,
implementan todos los métodos especificados por la
interfaz remota y, posiblemente, algunos de los
especificados por la interfaz "home".
Correspondencia entre métodos de
interfaz y métodos de implementación
 Las llamadas al método en la interfaz "home" se remiten
al método correspondiente de la clase de implementación
del bean con el prefijo 'ejb' añadido y con la primera letra
de la interfaz "home" convertida en mayúscula y
manteniendo exactamente el mismo tipo de argumentos.
Por ejemplo:
 create ---> ejbCreate.
 Las llamadas a métodos en la interfaz remota se remiten al
método de implementación correspondiente del mismo
nombre y argumentos en la clase del bean.
Ejemplo de anotación de inyección en un
servlet

public class MiServ extends HttpServlet {

@EJB
private MiEJB miEJBRef;
protected void doGet(…) {
…
miEJBRef.miMetodo();
… }
}
Ejemplo de EJB de sesión
sin estado
package myPack;
Import javax.ejb.Stateless;
@Stateless
public class MyEJB implements MyEJBLocal {
public String myMethod(String myName) {
return “Hello “ + myName;}
}
Estructura de una
aplicación Enterprise