JEE 5 - EJB3

EJB 3.0
JSR 220
Emmerson Miranda
SCJP 1.5
SCWCD J2EE 1.5
Blog : http://emmersonmiranda.blogspot.com/

Introducción
Emmerson Miranda
SCJP 1.5
SCWCD J2EE 1.5

 Uso de anotaciones para anotar los EJB, esto reduce el número de clases
e instancias necesarias, además de eliminar la necesidad de crear
descriptores de despliegue.
 “configuration by exception” es decir proporciona especificaciones por
defecto para las opciones mas comunes.
 Encapsulación de los accesos JNDI usando los mecanismos de
anotaciones, inyección de dependencias y búsquedas simples.
 Las interfaces de negocio requeridas para los beans de session ahora se
basan en POJIs (Plain Old Java Interfaces)

 Simplificación de la persistencia de entidades mediante JPA.
 Eliminación de todas las interfaces requeridas para las entidades
persistentes.
 Uso de anotaciones y descriptores XML para las entidades persistentes
(tablas y sus relaciones)
 Reduce la necesidad de uso de las excepciones checked.

 Son interfaces entre nuestros componentes y las funcionalidades de
bajo nivel de un plataforma específica (que soporta el componente).
 Todo componente web, enterprise bean, application client; necesita ser
ensamblado como un modulo JEE y desplegado en el contenedor antes
de ser ejecutado.
 El proceso de ensamblado requiere especificar la configuración para
cada componente mediante ficheros XML.
 Configurando el contenedor se personaliza el soporte proporcionado
por el servidor JEE, incluyendo servicios como seguridad,
administración de transacciones, búsquedas JNDI y conectividad
remota.

 El modelo de seguridad Java EE nos permite configurar los
componentes Web o EJB de para que puedan ser utilizados por
usuarios autorizados.
 El modelo transaccional nos permite especificar las relaciones entre los
métodos para realizar una transacción, de esta manera múltiples
métodos pueden ser tratados como una unidad.
 JNDI proporciona una interfaz unificada para la búsqueda de múltiples
servicios empresariales, de esta manera los diversos componentes
pueden acceder a estos servicios.
 El modelo de conectividad remota administra las comunicaciones a
bajo nivel entre los clientes y los beans empresariales.

 Los contenedores también manejan los servicios no-configurables
como los :
 Beans empresariales
 Ciclo de vida de los servlets
 Pool de conexiones a bases de datos
 Persistencia de datos
 Acceso a las APIS de la plataforma Java EE

 Servidor EE y contenedores

 Java EE Server
 Proporciona contenedores Web y EJB
 EJB Container
 Administra la ejecución de los beans empresariales para aplicaciones Java EE
 Web Container
 Administra la ejecución de los servlets y las JSP para aplicaciones Java EE
 Application client Container
 Administra la ejecución de los componentes de la aplicación cliente (en el cliente)
 Applet Container
 Administra la ejecución de los applets, consiste en un navegador con el plug-in de
Java

 APIs de la plataforma J2EE

Aplicaciones distribuidas
Multicapa
Emmerson Miranda
SCJP 1.5
SCWCD J2EE 1.5

 La plataforma Java EE usa el modelo de aplicaciones distribuidas
multicapa para las aplicaciones empresariales.
 La lógica de la aplicación se divide en capas según su función.
 Descomposición de las capas:
 Client tier .- Se ejecuta en la maquina del cliente
 Web tier .- Se ejecuta en el servidor JEE
 Business tier .- Se ejecuta en el servidor JEE
 EIS(Enterprise Information System) tier.- Software que se ejecuta en
el servidor EIS

 Los clientes se pueden comunicar con la capa de negocio, directa o
indirectamente

 La capa Enterprise Information System maneja el software EIS e
incluye la infraestructura del sistema como:
 Enterprise resource planning (ERP)
 Proceso de transacciones mainframe
 Sistemas de bases de datos
 Otros sistemas de información heredados.

Beans empresariales
Emmerson Miranda
SCJP 1.5
SCWCD J2EE 1.5

 Simplifican el desarrollo de aplicaciones distribuidas extensas.
 Los desarrolladores se pueden centrar únicamente en desarrollar los
requerimientos funcionales, ya que el contenedor le proporciona acceso a
los servicios de bajo nivel(transacciones, autorización …).
 Ya que se centran en la lógica de negocio, los desarrolladores del lado
cliente se pueden centrar únicamente en la presentación del cliente
(olvidándose por ejemplo de los accesos a las bases de datos o reglas de
negocio)
 Ya que los EJB son componentes portables, el que compone o ensambla la
aplicación puede construir nuevas aplicaciones utilizando los bean
existentes. Estas aplicaciones se pueden ejecutar en cualquier servidor
compatible, siempre y cuando se utilice el API estándar.

 Se puede empezar a considerar el uso de EJBs en una aplicación si
esta tiene alguno de los siguientes requerimientos:
 La aplicación necesita ser escalable, para soportar un numero
creciente de usuarios y así poder distribuir los componentes entre
múltiples maquinas y cuya localización sea transparente para los
clientes.
 Asegurar la integridad de los datos utilizando transacciones
 La aplicación puede tener una variedad de clientes; con solo unas
pocas líneas de código los clientes remotos pueden localizar
fácilmente los beans empresariales.

 Representa un cliente simple dentro del servidor de aplicaciones; para
acceder a una aplicación desplegada en un servidor, el cliente invoca
los métodos de un bean de session.
 Son creados por un cliente y usualmente existe solo durante la
duración de una session cliente-servidor.
 Pueden ser transaccionales, pero no son persistentes (sus datos no se
guardan en una base de datos), por tanto si el sistema falla sus datos
se pierden.
 Son de dos tipos; stateful y stateless
 Cuando el cliente termina los bean de sesion terminan.

 El estado de un objeto es o esta compuesto por los valores de sus
variables de instancia.
 En un stateful, las variables de instancia representan el estado de un
bean durante una session de un cliente.
 El estado del bean se mantiene entre las distintas invocaciones de sus
métodos (cada stateful se asocia a un solo cliente).
 Debido a que el cliente interactúa con su bean, su estado se suele
llamar “conversational state”
 Cuando el cliente elimina el bean o termina, el bean finaliza y su estado
se pierde.

 No mantiene el “conversational state” con el cliente.
 Cuando un cliente invoca los métodos de un bean stateless, el estado
de las variables de instancia del bean se mantiene solo durante la
duración de la ejecución del método
 Los clientes pueden cambiar los estados de los beans stateless que se
encuentran en el pool, utilizándose en la siguiente invocación del bean.
 Todas las instancias de los beans stateless son equivalentes,
permitiendo así al contenedor EJB asignar una instancia a cualquier
cliente, es decir, el estado de un stateless se puede aplicar a todos los
clientes..

 Debido a que pueden soportar un amplio número de clientes, ofrece
mejor escalabilidad para aplicaciones con un amplio número de
clientes.
 Pueden implementar web services, pero los otros tipos de EJB no.

 Si en cualquier momento solo un cliente a de acceder a una
determinada instancia de un bean.
 El estado del bean no ha de ser persistente, existiendo solo durante un
periodo corto de tiempo.
 El bean implementa un web service.

 Los beans stateful son apropiados si se cumple una de las siguientes
condiciones:
 El estado del bean representa la interacción entre el bean y un
cliente concreto.
 El bean necesita almacenar información entre las distintas
invocaciones de métodos
 El bean media entre el cliente y otros componentes de la aplicación,
dando una vista simplificada al cliente.
 Detrás de escena, el bean maneja el flujo de trabajo de muchos
beans empresariales.

 Para mejorar el rendimiento, se pueden elegir beans stateless si:
 El estado del bean no tiene información para un cliente específico.
 En una sola invocación de un método, el bean realiza tareas
genéricas para todos los clientes (Ejemplo: enviar un mail de
confirmación de pedidos)

 Es un bean empresarial que permiten procesar mensajes
asíncronamente.
 Normalmente actual como un escuchador de mensajes (Message
Listener)
 Los mensajes pueden ser enviados por cualquier componente Java EE
 Aplicación cliente
 Otro bean empresarial
 Componente web
 Aplicación JMS
 Sistemas que no utilizan la tecnología Java EE
 Pueden procesar mensajes JMS o de otro tipo

 Sus variables de instancia pueden mantener el estado durante el
proceso de los mensajes de los clientes (por ejemplo una conexión a
base de datos, un objeto de referencia a otro EJB, etc.)
 Los clientes no pueden invocarlos directamente, la única forma que
tienen de contactar con ellos es enviando mensajes a las colas a las
cuales están escuchando.
 Cada vez que llega un mensaje, el contenedor invoca el método
onMessage del MDB para procesarlo. El método onMessage puede
utilizar métodos helper o invocar beans de session para procesar la
información y/o almacenarla en la bbdd.
 Un mensaje puede ser entregado en el contexto de una transacción,
así si esta es cancelada, el mensaje es nuevamente re-entregado.

 Se ejecutan cada vez que se recibe un mensaje
 Son invocados asíncronamente
 Relativamente tienen una vida corta
 No representan datos de la base de datos, pero pueden acceder y
modificarlos.
 Son Stateless

 Los clientes no pueden acceder a los MDBs utilizando interfaces.
 Los MDB solo tienen una clase a diferencia de los beans de Session
 Parecidos entre los MDB y los beans de Session :
 Los MDB no almacenan información, ni estado conversacional con
clientes específicos
 Todas las instancias de los MDB son equivalentes, siendo el
contenedor EJB el que asigna un mensaje a cualquier instancia
MDB.
 Un MDB puede procesar mensajes de múltiples clientes

 Los beans de session permiten enviar mensajes JMS de manera
síncrona, pero no asíncrona.
 Para recibir mensajes asíncronamente hay que usar MDBs

 Son representaciones explícitas de datos o colecciones de estos, tales
como filas de bases de datos.
 Son persistentes y duran lo mismo que los datos en una base de datos.
 La clave primaria identifica una única instancia
 Son transaccionales y recuperables si el sistema falla.
 Desde EJB 3.0 los beans de entidad son POJOs (Plain Old Java
Objects) y soportan

 Utilizan anotaciones de Java incluso para su mapeo relacional
 Soportan herencia y polimorfismo
 Tienen un modelo simple de persistencia para las operaciones CRUD
usando el EntityManager.
 Capacidad de consultas mejora.

 Utilizar entity beans si los datos se han de guardar en algún almacén
de datos, estos pueden ser consultados y actualizados por múltiples
usuarios.

 Ya que un EJB esta compuesto de muchas partes, se usan las
siguientes convenciones de nombres para las aplicaciones.
Parte Sintaxis Ejemplo
Enterprise bean name nombreBean CalculadoraBean
Enterprise bean class nombreBean CalculadoraBean
Business interface nombre Calculadora

 Las siguientes anotaciones pueden ser usadas en EJB 3.0
Anotación Descripción
@Stateless Marca un bean como stateless
@Stateful Marca un bean como stateful
@MessageDriver Marca un bean como MDB
@PostConstruct,
@PreDestroy,
@PostActivate,
@PrePassivate
Marcan los métodos dentro del bean,
permitiendo asociarlos a su ciclo de vida.
@RolesAllowed,
@PermitAll, @DenyAll
Declara permisos a nivel de métodos

@RunAs Indica la identidad principal con la que se
ejecutará el método
@Timeout Indica el tiempo máximo de ejecución de
un método
@TransactionAttribute Aplica un atributo que indica el tipo de
transacción que se aplica a una interfaz o
métodos individuales en la clase del bean
@TransactionManagement Indica si el bean será CMP o BMP
@Resource Permite la inyección de recursos
(SessionContext, DataSource,
QueueConnectionFactory, Queue …)

@EJB Usado por los clientes para hacer referencia a
las interfaces de negocio de un EJB
@PersistenceContext Usado para inyectar un EntityManager
@PersistenceUnit Usado para inyectar un EntityManagerFactory
@Entity Marca una clase como una Entity bean.
@Table Especifica la tabla primaria del Entity bean
@Column Asocia una propiedad con una columna
@Id Especifica la clave primaria de una entidad

@ManyToOne Define la relación many-to-one con otros beans
@ManyToMany Define la relación many-to-many con otros beans
@OneToMany Define la relación one-to-many con otros beans
@OneToOne Define la relación one-to-one con otros beans
@JoinColumn Define una asociacion con otra entidad
@SecundaryTable Permite especificar una tabla secundaria, para
indicar que los datos de la entidad se pueden
almacenar en diferentes tablas.

Acceso a los EJB
Emmerson Miranda
SCJP 1.5
SCWCD J2EE 1.5

 Los MDB no disponen de interfaces de acceso para clientes.
 El acceso de los clientes puede local, remoto o web service.
 Los clientes solo pueden acceder a los métodos del EJB que están
definidos en sus interfaces de negocio (estos actúan como vistas del
bean).
 El resto de detalles no son visibles para los clientes
 Un buen diseño basado en interfaces simplifica el desarrollo y
mantenimiento de las aplicaciones Java EE.
 Protegen de los cambios de implementación y de las complejidades propias de la
capa de los EJB

 Se pueden ejecutar en maquina distinta y distinta JMV que el EJB al
cual accede.
 Puede ser un cliente web, una aplicación de escritorio u otro EJB.
 La localización del EJB es transparente.
 La interfaz remota de un EJB define los métodos accesibles para un
bean.

 Para que un EJB permita acceso remoto
 la interfaz que implementa tiene que tener la anotación @Remote
@Remote
public interface InterfaceName { ... }
 O también utilizar @Remote en el bean
@Remote(InterfaceName.class)
public class BeanName implements InterfaceName { ... }

 Deben ejecutarse en la misma JVM que el EJB al cual se accede.
 Puede ser un componente web u otro EJB.
 Para un cliente local, la localización del bean no es transparente.
 La interfaz local de un EJB define los métodos accesibles para un
bean.
 Todas las interfaces de negocio son por defecto local

 Para que un EJB permita acceso local
 la interfaz que implementa tiene que tener la anotación @Local
@Local
public interface InterfaceName { ... }
 O también utilizar @Local en el bean
@Local(InterfaceName.class)
public class BeanName implements InterfaceName { ... }

 Rendimiento
 A causa de la latencia de red los EJB locales son mas rápidos que
los remotos.
 Si los componentes se distribuirán entre diferentes servidores, el
EJB debe ser remoto, pudiendo mejorar el rendimiento de las
aplicaciones
 Distribución de los componentes
 En una aplicación distribuida, los componentes web pueden
ejecutarse en diferentes servidores los cuales deben acceder a los
EJB, para este caso los beans empresariales deben permitir acceso
remoto.

 Tipos de cliente
 Si el EJB será accedido por diversos tipos de aplicaciones, debe
permitir acceso remoto.
 Si los clientes son componentes Web o EJBs, el acceso depende
del tipo de distribución que se decida dar a los componentes.
 Acoplamiento fuerte o pobre de los beans relacionados
 En caso de acoplamiento fuerte el acceso local es un buen
candidato, ya que da mejor rendimiento.

 Un cliente ws puede acceder a una aplicación JEE de dos formas:
 Web Services creados con JAX-WS
 Pueden invocar métodos de beans stateless (los MDB no)
 Cualquier cliente ws puede acceder a un bean stateless,
independientemente del lenguaje en el que se implemente (el cliente).
 Tanto los EJB y los componentes web pueden ser clientes de ws
 Por defecto todos los métodos del bean son accesibles, excepto si
alguno de ellos lleva la anotación @WebMethod, en cuyo caso dejan
de serlo (es decir solo serán accesibles aquellos que tengan dicha
anotación)

 Los parámetros de las llamadas remotas son mas aislados que los de
las llamadas locales.
 En las llamadas remotas, el cliente y el bean utilizan copias distintas
del objeto pasado por parámetro (por tanto un cambio en cualquiera de
las partes no afecta a la otra).
 Protege los datos del bean si el cliente modifica accidentalmente los datos.
 En las llamadas locales, el cliente y el bean utilizan la misma copia.
 Al igual que en las llamadas remotas, los clientes de ws trabajan con
copias diferentes de los parámetros.

Composición
Emmerson Miranda
SCJP 1.5
SCWCD J2EE 1.5
Blog : http://emmersonmiranda.blogspot.com/ - Mail

 Un EJB esta compuesto de:
 Enterprise bean class .- Es la clase que implementa los métodos de
negocio definidos en las interfaces y los métodos que involucran al
ciclo de vida de los ejb.
 Business interfaces .- Define los métodos que el bean empresarial
necesita implementar (@Local, @Remote)
 Helper clases .- Otro tipo de clases que utiliza el EJB, como por
ejemplo excepciones y clases de utilidad.
 Descriptor de despliegue XML (opcional), los cuales pueden sobre
escribir los metadatos definidos con las anotaciones de la clase del
bean.

 Los ficheros que componen un EJB pueden ser ensamblados en un
fichero .jar; el cual es portable y se pueden usar en diferentes
aplicaciones.

Ciclos de vida
Emmerson Miranda
SCJP 1.5
SCWCD J2EE 1.5

 Cada tipo de bean empresarial tiene un ciclo de vida diferente
 Activation / Passivation
 Técnica mediante la cual el contenedor EJB puede elegir serializar
temporalmente un bean y almacenarlo en el sistema de ficheros del
servidor de aplicaciones u otro sistema de persistencia, para poder
posteriormente volver a recrear el estado del bean.
 Esta técnica permite un óptimo manejo de recursos para la
aplicación.

 El cliente inicia el ciclo de vida al obtener una referencia al bean
 El contenedor realiza la inyección de dependencia
 El contenedor invoca el método @PostConstruct si lo hubiera.
 A partir de este punto el bean esta listo para que el cliente pueda
invocar los métodos de negocio.
 El contendor puede decidir si “deactivate” o “passivate” el bean.
 El método @PrePassivate, es llamado antes que sea
almacenado en el almacén persistente




 Cuando el cliente invoca un método de negocio de un bean que
esta en estado “passive” ,el contenedor activa el bean llamando
al método @PostActivate si lo hubiera.
 Al final del ciclo de vida el cliente invoca el método @Remove, y el
contenedor llama al método @PreDestroy si lo hubiera.
 La instancia queda lista para el recolector de basura

 El cliente inicia el ciclo de vida al obtener una referencia al bean
 El contenedor realiza la inyección de dependencia
 El contenedor invoca el método @PostConstruct si lo hubiera.
 A partir de este punto el bean esta listo para que el cliente pueda
invocar los métodos de negocio (no se puede serializar).
 Cuando el cliente se desconecta la session, el contenedor invoca el
método @PreDestroy si lo hubiera.

 El contenedor crea un conjunto de instancias y los almacena en el pool,
cada una de las instancias realiza las siguientes tareas:
 Si el MDB usa inyección de dependencia, el contenedor inyecta las
referencias
 El contendor invoca el método @PostConstuct si lo hubiera.
 Cuando llega un mensaje el contenedor recoge una instancia del pool e
invoca su método onMessage pasandole el mensaje como parámetro.
 Al finalizar la vida del MDB el contenedor llama al método @PreDestroy
si lo hubiera.

 http://jcp.org/en/jsr/detail?id=220
 Enterprise JavaBeans 3.0 Final Release
 ejbcore .- ejb-3_0-fr-spec-ejbcore.pdf
 Persistence .- ejb-3_0-fr-spec-persistence.pdf
 Simplified.- ejb-3_0-fr-spec-simplified.pdf

JEE 5 - EJB3

Más contenido relacionado

La actualidad más candente (20)

Similar a JEE 5 - EJB3 (20)

Más de Emmerson Miranda (7)

Último (20)

JEE 5 - EJB3

Notas del editor