WorkS

avanzado </
de <EJB 3.0
Material de consulta

WorkS 1
 Indice
Introduccin .................................................................................................... 4
Introduccin a JEE ............................................................................................................ 4

Definicin ........................................................................................................... 4

Especificaciones................................................................................................. 4

Ventajas .............................................................................................................. 4

Desventajas ........................................................................................................ 8

Application Server ............................................................................................ 5

Qu es un EJB? ................................................................................................................... 5

Session Beans ........................................................................................................................ 5

Que es un session bean? ................................................................................... 5

Tipos de Session Bean ...................................................................................... 6

Stateful Session Beans.................................................................................................................. 6

Stateless Session Beans................................................................................................................ 6

Cundo usar un session bean? ........................................................................ 6

Accediendo a los Session Beans mediante Interfaces................................... 7

Remote Clients.............................................................................................................................. 7

Local Clients................................................................................................................................... 8

Qu utilizar? Acceso remoto o local?................................................................................... 8

Acceso sobre los parmetros de los mtodos ...................................................................... 9

Contenido de un Enterprise bean ................................................................... 9

Ciclo de Vida de un EJB .................................................................................. 10

Ciclo de vida de un Stateful Session Bean.............................................................................10

Ciclo de vida de un Stateless Session Bean ..........................................................................10

WorkS 2
Message-Driven Beans .................................................................................................11

Qu son? ......................................................................................................... 11

Qu hace Diferente a un Message con respecto un Session? .................... 11

Cundo se usan?............................................................................................. 12

Naming Conventions ....................................................................................................13

Servicios del contenedor ...........................................................................................13

JNDI .................................................................................................................. 13

Pool de conexiones.......................................................................................... 13

Transacciones .................................................................................................. 14

Qu es una transaccin? ...................................................................................................14

Transacciones container-managed ................................................................ 14

Atributos de la transaccin ......................................................................................................15

Required........................................................................................................................................15

RequiresNew ...............................................................................................................................16

Mandatory ....................................................................................................................................16

NotSupported .............................................................................................................................16

Supports........................................................................................................................................17

Never.............................................................................................................................................17

Configurando el atributo de las transacciones.....................................................................17

Haciendo Rollback a una transaccin manejada por el contenedor...............................18

Transacciones Bean-Managed................................................................ 18

JTA Transactions ..........................................................................................................................19

Terminar un mtodo sin ejecutar commit ............................................................................19

Fuentes y referencias..................................................................................................................20

Versiones.......................................................................................................................................21

WorkS 3
Introduccin
EJB 3.0 es una profunda revisin y simplificacin de lo que es la especificacin de EJB, que est dado dentro
del marco de JEE.
Como primera medida repasaremos qu es JEE y luego nos centraremos en las particularidades de EJB 3.0

Introduccin a JEE
Java Enterprise Edition (JEE) no es un lenguaje particular de Java, sino que es una plataforma que habilita
soluciones para desarrollo, uso efectivo y manejo de multicapas en aplicaciones centralizadas en el servidor.
La principal funcionalidad es utilizarlo en desarrollos de aplicaciones empresariales, debido a que comprenden
un conjunto de especificaciones y funcionalidades orientadas a negocios. Entre sus ventajas se encuentran la
gran robustez, fiabilidad, estabilidad y seguridad.

Definicin
JEE define un estndar para el desarrollo de aplicaciones empresariales multicapa creada y distribuida por Sun
Microsystems. El objetivo principal es simplificar las aplicaciones empresariales basndolas en componentes
modulares y estandarizados, proveyendo un completo conjunto de servicios a estos componentes y
manejando muchas de las funciones de la aplicacin de forma automtica, sin necesidad de una programacin
compleja.

Especificaciones
JEE aprovecha muchas de las caractersticas de la plataforma Java, como ser la portabilidad (write once, run
anywhere) y se basa en varias especificaciones que ya son estndar en el mercado, como ser: JDBC, RMI, JMS,
XML, Web Services, etc.
Sobre esta base, JEE define la especificacin de varios tipos de componentes que permiten a cualquier
contenedor JEE brindar las caractersticas de una aplicacin empresarial.
Estas especificaciones son:
Componentes de Negocio: Enterprise Java Beans (EJB)
Componentes Web: Java Servlet, JavaServer Faces, and JavaServer Pages (JSP)
Clientes: programas java stand alone y Applets

El estndar JEE incluye todas las especificaciones y pruebas de conformidad que permiten la portabilidad de
las aplicaciones a travs de la amplia gama de sistemas empresariales compatibles con JEE.

Ventajas
Simplifica la complejidad de construir aplicaciones n-tier
Permite lidiar con fuertes requerimientos no funcionales
Distribucin * Tolerancia a fallas
Estandariza una API comn entre componentes y servidores de aplicacin
Los servidores de aplicacin y contenedores proveen los servicios del framework
Escalabilidad
Permite trabajar transparentemente con transacciones

WorkS 4
Desventajas
Balas de plata (the silver bullet problem)
Empresas Buzzword Compliant
Gerentes Buzzword Compliant
El fenmeno (casi-mito) de las RADs
Dimensin de un proyecto JEE real
Falta de profesionales debidamente capacitados
Decisiones de Arquitectura

Application Server
Para poder ejecutar una aplicacin JEE es necesario contar con un container o application server que sea
JEE compliant. En el mercado existen bastantes opciones entre las cuales elegir, incluyendo a JBoss como la
opcin open source y a BEA Weblogic Server como la opcin comercial.

Que es un EJB?
Los EJB o Enterprise Java Beans son componentes JEE que se ejecutan dentro de un container EJB, un entorno
de ejecucin dentro de un Application Server. El contenedor de EJB provee servicios al usuario, los cuales
expone de manera transparente, como ser: Transacciones, Seguridad, etc.
Los Entreprise Java Beans son componentes del lado del servidor que encapsulan la lgica del negocio de una
aplicacin.

Los Entreprise Java Beans simplifican el desarrollo de aplicaciones de gran porte que deben ser distribuidas;
esto se logra gracias a que los servicios de transacciones, seguridad y distribucin son administrados por el
container y no por el programador, logrando as facilitar la administracin de los EJB.
Gracias a que los EJB representan la lgica del negocio, la capa de presentacin puede ser desarrollada por
otro equipo de profesionales expertos, sin necesidad de conocer la lgica que existe dentro de los beans EJB.
Esto tiene como consecuencia que la capa de presentacin puede desarrollarse tanto en HTML, como en una
aplicacin para dispositivos pequeos.

Session Beans
Qu es un session bean?

Un session Bean representa un nico cliente dentro de un Application Server. Comnmente, un cliente
invoca un mtodo de un session bean y este ejecuta las tareas de negocio, ocultndole al cliente la
implementacin (ya sea de la lgica del negocio como tambin de la complejidad de la comunicacin
remota).

WorkS 5
Un Session Bean no es compartido, solamente puede pertenecer a un solo cliente y no es persistente.
Cuando el cliente termina la sesin, el EJB es desasociado del cliente y termina.

Tipos de Session Bean

Existen 2 tipos de Session beans: stateful y stateless

Stateful Session Beans

El estado de un objeto consiste en los valores de sus variables de instancia. En un Stateful Session bean, la
variable de instancia representa el estado de una nica sesin. Debido a que el cliente interacta con el bean,
el estado es comnmente denominado estado conversacional.

El estado es mantenido a lo largo de la sesin del cliente. Si el cliente elimina el bean o lo termina, la sesin
termina y el estado desaparece.

Stateless Session Beans

Un stateless session bean no mantiene un estado conversacional con el cliente. Cuando un cliente invoca
un mtodo en un bean stateless, el bean puede contener valores en sus variables de instancia especficas al
cliente, pero solo durante la invocacin al mtodo. Cuando la llamada al mtodo finaliza, el estado se pierde.

Debido a que los stateless beans soportan mltiples clientes, ofrecen una mejor escalabilidad para las
aplicaciones que requieren un gran nmero de clientes concurrentes.

Los session beans stateless pueden implementar web services, mientras que los otros tipos de EJB no.

Cundo usar un session bean?

En general, se debera usar un session bean cuando:

En un momento determinado, solo un cliente tiene acceso a la instancia del bean.

El estado del bean no es persistente, existiendo solamente por un periodo 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 interaccin entre el bean y un cliente especfico.

El bean necesita mantener informacin acerca del cliente a travs de varias invocaciones a varios mtodos.
El bean intermedia entre el cliente y otro componente de la aplicacin, presentando al cliente una vista
simplificada.
El bean maneja el workflow de varias aplicaciones.

WorkS 6
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 especficos del cliente.

En una invocacin a un mtodo, el bean ejecuta tareas especficas para todos los clientes.

Accediendo a los Session Beans mediante Interfaces

Un cliente puede acceder a un session Bean solo mediante los mtodos que define la interfaz business del
bean. La interfaz business define la vista del bean hacia el cliente mientras que los aspectos de implementacin
y deployment se mantienen ocultos para el cliente.

Hay que tener en cuenta la simplicidad a la hora de definir la interfaz de un bean. Si mantenemos una interfaz
simplificada, facilitaremos la manutencin de las aplicaciones JEE. Una interfaz sencilla no solo protege al cliente
de la complejidad interna, sino que facilita realizar cambios al EJB sin que estos vean su interfaz afectada. Si
bien esta buena prctica aplica a todo el desarrollo de software, es de especial inters en el desarrollo de EJB,
debido a la propiedad distributiva del mismo.

Los Session Beans pueden tener ms de una interfaz business. Los Session Beans deberan (no estn obligados)
a implementar su interfaz o interfaces business.

Cuando se est diseando una aplicacin JEE, una de las primeras decisiones que se realizan es si el tipo de
cliente que acceder al enterprise bean ser remoto, local o web-service.

Remote Clients
Un Cliente remoto de un enterprise bean tiene las siguientes facilidades:

Puede ejecutarse tanto en una JVM distinta como en una mquina distinta.
Puede ser un componente web, una aplicacin o incluso otro enterprise bean.
Para un cliente remoto, la ubicacin del enterprise bean es transparente.

Para crear un enterprise bean que permita acceso remoto, se debe realizar alguna de las siguientes cosas:

1. Decorar la interfaz business del enterprise bean con la anotacin @Remote

@Remote
public interface InterfaceName {
.
}
2. Decorar la clase bean con la anotacin @Remote, especificando la interfaz business
@Remote(InterfaceName.class)
public class BeanName implements InterfaceName {

WorkS 7
La interfaz remota define los mtodos business y los del ciclo de vida que son especficos del bean. Por
ejemplo, la interfaz remota de un bean llamado BankAccountBean puede tener mtodos llamados depositar
y acreditar.

Local Clients
Un cliente local posee las siguientes caractersticas:
Debe ejecutar en la misma JVM que el enterprise bean que accede.
Puede ser un componente web u otro entreprise bean.
Para el cliente local, la ubicacin del enterprise bean que accede no es transparente.

La interfaz local de negocios (local business interface) define los mtodos de negocio y del ciclo de vida.
Si la interfaz business del bean no es decorada con la anotacin @Local o @Remote y el la clase bean no
especifica la interfaz utilizando @Local o @Remote, la interfaz business es, por defecto, una interfaz local.
Para construir un enterprise bean que permita solo acceso local, se deber realizar alguna de las siguientes
acciones:

Decorar la interfaz business del enterprise bean con la anotacin @Local:

@Local
public interface InterfaceName {

Especificar la interfaz decorando la clase del bean con la anotacin @Local y especificar el nombre de la
interfaz. Por ejemplo:
@Local(InterfaceName.class)
public class BeanName implements InterfaceName {

Qu utilizar? Acceso remoto o local?

Decidir si permitiremos acceso remoto o local depende principalmente de los siguientes factores:

Nivel de acoplamiento de los beans relacionados: los beans fuertemente acoplados dependen unos de
otros. Este tipo de beans deberan tener acceso local ya que generan una nica unidad lgica.

Tipo de cliente: si el enterprise bean es accedido por aplicaciones clientes, entonces, debera definirse
como remoto. En un entorno de produccin, este cliente corre usualmente en una mquina distinta que el
Application Server.

WorkS 8
Distribucin de componentes: las aplicaciones JEE son escalables porque permiten que sus componentes
sean distribuidos entre distintas maquinas. En una aplicacin distribuida, por ejemplo, el componente web
puede estar ejecutndose en una maquina distinta que el enterprise bean que accede. En un escenario
distribuido, los enterprise bean deberan permitir acceso remoto.

Performance: debido a distintos factores de la red, como ser latencia de la misma, las llamadas remotas
pueden ser mucho ms lentas que las llamadas locales. Por otro lado, si se distribuyen los componentes en
los distintos servidores se puede mejorar la perfomance general de la aplicacin. Siempre se tiene que tener
en mente cmo afectar el diseo de nuestra aplicacin a la performance.

Si no se est seguro de qu tipo de acceso debe tener un enterprise bean, lo recomendable es que se
seleccione acceso remoto. Esto nos da flexibilidad si en el futuro los componentes deben ser distribuidos.

Aunque poco comn, es posible permitir que un bean tenga acceso local y remoto. Si este es el caso, la clase
deber especificar la interfaz business utilizando las anotaciones @Remote y @Local, . La misma interfaz
business no puede ser decorada con @Remote y @Local al mismo tiempo.

Acceso sobre los parmetros de los mtodos

El tipo de acceso afecta los parmetros del mtodo del bean que es llamado por el cliente.
Los parmetros de una llamada remota son ms aislados que las de una llamada local. Con las llamadas
remotas, el cliente y el bean operan en distintas copias del objeto que es enviado por parmetro.
En las llamadas locales, tanto el cliente como el bean pueden modificar el mismo objeto parmetro. En
general, no se debera utilizar este efecto de lado para el correcto funcionamiento de nuestro componente.

Contenido de un Enterprise bean

Para desarrollar un enterprise bean, se deben proveer los siguientes archivos:

Clase enterprise bean: implementa los mtodos definidos en la interfaz de negocios y las llamadas a los
mtodos del ciclo de vida.

Interfaz Business: la interfaz business define los mtodos que debe implementar la clase enterprise bean.

Clases Helper: otras clases tiles para el enterprise bean.

WorkS 9
Todos estos archivos deben ser empaquetados en un archivo EJB JAR. Un archivo EJB JAR es portable y
puede ser usado en diferentes aplicaciones. Para ensamblar una aplicacin JEE, se deben empaquetar uno o
ms mdulos en un archivo EAR.

Un archivo EJB JAR debe tener la siguiente estructura:

Ciclo de Vida de un EJB

Un Enterprise Bean transita varios estados durante su ciclo de vida. Cada tipo de Enterprise Bean tiene un
ciclo de vida distinto.

Ciclo de vida de un Stateful Session Bean

La siguiente figura muestra los estados que un session bean transita durante su ciclo de vida. El cliente inicia
el ciclo de vida obteniendo una referencia al stateful session bean. El contenedor inyecta las dependencias
y luego invoca al mtodo anotado con @PostConstruct, si existe.

WorkS 10
Mientras est en la etapa ready, el contenedor EJB puede decidir pasivar el bean, moviendo de la memoria
al almacenamiento secundario (usualmente, el disco rgido). El contenedor EJB invoca el mtodo anotado con
@PrePassivate, si existe, inmediatamente antes de pasivarlo. Si el cliente invoca un mtodo business mientras
el EJB est en el estado pasivado, el contenedor ejecutar el mtodo anotado con @PostActivate, si existe, y
luego mueve al bean al estado ready.
Al final del ciclo de vida, el cliente invoca al mtodo anotado con @Remove, y el contenedor EJB ejecuta al
mtodo anotado con @PreDestroy, si existe. Luego de esto, el bean est listo para ser recolectado por el
GC.

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 continuacin muestra las etapas de un session bean stateless.

El cliente inicia el ciclo de vida cuando obtiene una referencia al bean stateless. El contenedor inyecta las
dependencias y luego invoca al mtodo anotado con @PostConstruct, si existe.
Al final del ciclo de vida, el contenedor EJB llama al mtodo anotado con @PreDestroy, si existe. Luego de
esto, la instancia del bean est lista para ser recolectada por el GC.

Message-Driven Beans
Qu son?
Un message Driven Bean es un Enterprise Bean que permite a las aplicaciones JEE procesar mensajes
asincrnicamente. Normalmente acta como un listener de mensajes JMS, que es lo mismo que un event
listener, pero escuchando mensajes JMS. El mensaje puede ser enviado por cualquier componente JEE, o por
una aplicacin JMS, o un sistema que no use tecnologas JEE.

Qu 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 travs de interfaces. A diferencia
de un session bean, los message beans solamente tienen una clase bean.

WorkS 11
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 mltiples 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.

Los messages bean tienen las siguientes caractersticas:

Se ejecutan con la recepcin de un mensaje de un cliente.
Son invocados asincrnicamente
Su duracin es relativamente corta.
No representan datos.
Pueden ser transaccionales.
Son stateless.

Cuando se recibe un mensaje, el contenedor llama el mtodo onMessage para procesar el mensaje. El mtodo
onMessage normalmente castea el mensaje a alguno de los cinco tipos de mensajes JMS y procesa el mismo.
El mtodo onMessage puede llamar a mtodos helpers, o puede invocar un session bean para procesar la
informacin del mensaje o guardarlo en la base de datos.

Un mensaje puede ser entregado a un message bean dentro de una transaccin, en ese caso, todas las
operaciones del mtodo onMessage son parte de una nica transaccin.

Cundo se usan?
Los session beans permiten enviar mensajes JMS y recibirlos sincrnicamente, pero no asincrnicamente. Para
evitar atar los recursos del servidor, no se debe usar recepciones sincrnicas (las cuales son bloqueantes)
cuando se utilizan mensaje JMS. Para recibir mensajes asincrnicamente, se debe utilizar message Beans.

WorkS 12
Naming Conventions
Debido a que un Enterprise Bean est compuesto de muchas partes, es til (incluso necesario) seguir una
nomenclatura de nombres para la aplicacin. La tabla a que se muestra a continuacin define la convencin
establecida por Sun:

Item Sintaxis Ejemplo

Nombre del EB <nombre>Bean AccountBean

Clase del EB <nombre>Bean AccountBean

Interfaz Business <nombre> AccountBean

Servicios del contenedor

JNDI
En una aplicacin distribuida, los componentes necesitan acceder otros componentes y recursos como son
las bases de datos. Por ejemplo, un servlet puede invocar un mtodo remoto en un enterprise bean que
devuelve informacin de una base de datos. En la plataforma JEE, el servicio de nombres Java Naming and
Directory Interface (JNDI) permite localizar componentes y/o recursos.

Un recurso es un objeto que provee una conexin a un sistema, cada recurso es identificado por un nico
nombre, llamado JNDI name.

El administrador crea recursos en un namespace JNDI. Si la aplicacin utiliza resource injection, el application
server invoca al API JNDI.

Pool de conexiones
Para almacenar, organizar y obtener datos, la mayora de las aplicaciones usa base de datos relacional. Los
componentes JEE pueden acceder a las base de datos relacionales mediante el API JDBC.
En al API JDBC, las base de datos son accedidas usando objetos Data source. Un DataSource posee un
conjunto de propiedades que identifica y describe la fuente de datos que representa.
Las aplicaciones acceden a las fuentes de datos usando una conexin y los objetos DataSource pueden ser
pensados como fabricas de conexiones.
Si un objeto DataSource es registrado en un JNDI, la aplicacin puede usar el API JNDI para acceder al
DataSource.
Los objetos DataSource que implementan pool de conexiones, tambin producen conexiones a una fuente
de datos determinada. El objeto connection que devuelve el DataSource devuelve un proxy de la conexin
fsica. Los pooles de conexiones no tienen efecto sobre el cdigo del desarrollador, excepto, que deben ser
cerradas siempre despus de utilizarlas para que la conexin sea devuelta al pool.

WorkS 13
Transacciones

Qu es una transaccin?
Para emular una transaccin de negocios, un programa debe ejecutar varios pasos. Un programa financiero,
por ejemplo, puede que transfiera fondos de una cuenta a otra utilizando el siguiente pseudocdigo:

Begin transaction
Debit checking account
Credit savings account
Update history log
Commit transaction

O los tres pasos se ejecutan, o ninguno se ejecuta. Si no fuera as, se perdera la integridad de los datos.
Una transaccin puede terminar de dos modos: con un commit o con un rollbak. Cuando la transaccin
termina en un commit, los datos modificados por las sentencias son grabados. Si una sentencia falla, se produce
el rollback, que se encarga de deshacer los efectos de todos los statements anteriores en la transaccin. Ms
all de que falle la transaccin, los datos siempre quedaran ntegros.
En el pseudocdigo mostrado anteriormente, el begin y el commit muestran los lmites de la transaccin.
Cuando se disea un Enterprise Bean, es el desarrollador quien determina los lmites de la transaccin
especificando transacciones, ya sea container-managed o bean-managed.

Transacciones container-managed
En un Enterprise Bean que utilice transacciones container-managed, el contenedor EJB es quien establece
los lmites de la transaccin. Es posible utilizar transacciones container-managed en cualquier tipo de bean:
session o message-driven. Las transacciones container-managed simplifican el desarrollo, debido a que no es
necesario demarcar la transaccin explcitamente.

Por defecto, si no se le establece qu tipo de transaccin se utilizar, se le asignar el tipo container-

managed.

Normalmente el container comienza una transaccin inmediatamente antes de que algn mtodo comience
y esta transaccin es terminada (commit) justo antes de que se abandone el mtodo. Cada mtodo est
asociado a una nica transaccin.

Las transacciones container-managed no requieren que todos los mtodos estn asociados a alguna
transaccin, es el desarrollador quien marca los mtodos que estn asociados a una transaccin.

Los beans que utilicen el tipo de transaccin container-managed no deben usar ningn otro tipo de
transaccin que afecte los lmites de la transaccin del container, por ejemplo: no se deber usar el mtodo
setAutoCommit de java.sql.Connection. Si se necesita control sobre la transaccin, se debern utilizar
transacciones del tipo application-managed.

WorkS 14
Atributos de la transaccin

Los atributos de la transaccin controlan el alcance de la misma. La imagen que se presenta a continuacin
muestra por qu controlar el alcance de una transaccin es importante. En la imagen, el mtodo method-A
comienza una transaccin y luego invoca el mtodo method-B del Bean-2. Cuando el mtodo method-B
ejecuta, este ejecuta dentro de la transaccin iniciada por el mtodo method-A, o lo hace en una nueva
transaccin?
La respuesta depende del tipo de transaccin del mtodo method-B

El atributo de una transaccin puede tomar alguno de los siguientes valores:

Required
RequiresNew
Mandatory
NotSupported
Supports
Never

Required
Si el cliente est ejecutando dentro de una transaccin e invoca el mtodo del Enterprise Bean, el mtodo
ejecuta dentro de la transaccin del cliente. Si el cliente no est dentro de una transaccin, el container es
quien crea una nueva transaccin.

El atributo Required es el atributo implcito para todos los mtodos de los Enterprise Bean que manejan la
transaccin en el contenedor (container-managed).

WorkS 15
RequiresNew

Si el cliente est dentro de una transaccin e invoca el mtodo del Enterprise Bean, el contenedor toma las
siguientes acciones:
1.Suspende la transaccin del cliente
2.Comienza una nueva transaccin
3.Delega la llamada al mtodo
4.Despierta la transaccin del cliente que haba suspendido, luego de que se complete el mtodo.

Si el cliente no est asociado a una transaccin, el contenedor comienza una nueva transaccin antes de que
comience a ejecutar el mtodo.

Se debera utilizar RequiresNew cuando se desee que el mtodo siempre ejecute dentro de una nueva
transaccin.

Mandatory

Si el cliente est ejecutando dentro de una transaccin e invoca el mtodo del enterprise bean, el mtodo
ejecuta dentro de la transaccin del cliente. Si el cliente no esta asociado a una transaccin, el contenedor
lanza una excepcin del tipo TransactionRequiredException.

Es comn el uso de este tipo de transaccin, cuando es necesario que el mtodo del bean se ejecute dentro
de la transaccin del cliente.

NotSupported

Si el cliente esta ejecutando dentro de una transaccin e invoca al mtodo del enterprise bean, el contenedor
suspende la transaccin del cliente antes de invocar al mtodo. Luego de que el mtodo se complete, el
contenedor despierta la transaccin del cliente que haba suspendido anteriormente.

Si el cliente no est asociado a una transaccin el contenedor no comienza una nueva transaccin.

Cuando no se necesite utilizar una transaccin, es altamente recomendable que se utilice este atributo, ya que
crear transacciones trae aparejado un gran overhead para el contenedor.

WorkS 16
Supports

Si el cliente est ejecutando dentro de una transaccin e invoca el mtodo del Enterprise Bean, el mtodo
ejecuta dentro de la transaccin del cliente. Si el cliente no est asociado con una transaccin, el contenedor
no comienza una nueva transaccin.

Debido a que el comportamiento transaccional del mtodo puede variar, se deber utilizar supports con
mucho cuidado.

Never
Si el cliente est ejecutando dentro de una transaccin e invoca al mtodo del enterprise bean, el contenedor
lanzar la excepcin RemoteException. Si el cliente no esta asociado a una transaccin, el contenedor no
comienza una nueva transaccin.

Configurando el atributo de las transacciones

Los atributos de una transaccin son especificados decorando al Enterprise Bean (clase o
mtodos) con la anotacin @TransactionAttribute y asignndole alguna de las constantes de
javax.ejb.TransactionAttributeType.

Si se decora la clase del enterprise bean con @TransactionAttribute, el tipo especificado es aplicado en
todos los mtodos de negocios de la clase.

Decorar con la anotacin @TransactionAttribute solo un mtodo de negocio del enterprise bean, implica
asignar el valor nicamente a ese mtodo.

Si se decora tanto clase como mtodo, la anotacin del mtodo sobrescribe la anotacin de la clase.

Las constantes de TransactionAttributeType encapsulan los atributos mencionados anteriormente:

Required: TransactionAttributeType.REQUIRED
RequiresNew: TransactionAttributeType.REQUIRES_NEW
Mandatory: TransactionAttributeType.MANDATORY
NotSupported: TransactionAttributeType.NOT_SUPPORTED
Supports: TransactionAttributeType.SUPPORTS
Never: TransactionAttributeType.NEVER

WorkS 17
Haciendo Rollback a una transaccin manejada por el contenedor

Existen dos maneras de hacer rollback a una transaccin manejada por el contenedor. La primera, si alguna
sentencia lanza una excepcin, el contenedor har rollback automticamente de la transaccin. La segunda
es invocando al mtodo setRollbackOnly de la interfaz EJBContext. Este mtodo le indica al contenedor
que haga rollback de la transaccin.

Transacciones Bean-Managed
En las transacciones Bean-Managed, el cdigo en el session o message bean es quien marca los limites de
la transaccin. Aunque los beans con transacciones container-managed requieren menos cdigo, tienen
una limitacin: cuando un mtodo est ejecutando, puede ser asociado con una transaccin o con ninguna
transaccin. Si esta limitacin hace que el cdigo del bean de negocio se complique, se deber considerar
utilizar transacciones bean-managed.

El siguiente pseudocdigo muestra el control que se puede obtener utilizando transacciones bean-managed.
Controlando varias opciones, es el pseudocodigo quien decide comenzar o no una transaccin:

begin transaction
...
update table-a
...
if (condition-x)
commit transaction
else if (condition-y)
update table-b
commit transaction
else
rollback transaction
begin transaction
update table-c
commit transaction

WorkS 18
JTA Transactions
JTA es la abreviacin de Java Transaction API. Esta API permite manejar la transaccin de manera independiente.
El Application Server implementa el administrador de transacciones utilizando JTS (Java Transaction Service).
Pero el cdigo del bean no llama a los mtodos JTS directamente, sino que invoca a los mtodos JTA que
luego llaman a los mtodos JTS.

Una transaccin JTA es controlada por el controlador de transacciones JEE. Este controlador posee una
limitacin: no soporta transacciones anidadas; en otras palabras, no se puede iniciar una transaccin hasta que
la transaccin anterior se halla cerrado.

Para marcar los lmites de una transaccin se invocan los mtodos begin, commit y rollback de la interfaz
javax.transaction.UserTransaction.

Terminar un mtodo sin ejecutar commit

En un session bean stateless utilizando transacciones bean-managed, un mtodo de negocio debe ejecutar el
mtodo commit o rollback antes de terminar. En cambio, un session bean stateful no posee esta restriccin.

En un session bean stateful que utiliza transacciones bean-managed, un mtodo de negocio puede terminar
su ejecucin sin llamar al mtodo commit o rollback. Esto sirve para mantener una transaccin entre varios
llamados del cliente.

WorkS 19
Fuentes y referencias
http://www.epidataconsulting.com/tikiwiki/tiki-index.php?page=J2EE
http://www.epidataconsulting.com/tikiwiki/tiki-index.php?page=EJB
http://labs.jboss.com/portal/jbossejb3
http://java.sun.com/javaee/5/docs/tutorial/doc/

WorkS 20
Versin Fecha Autor Observaciones
0.1 27/03/2007 Diego Mornacco Creacin del documento
0.2 05/04/2007 Sergio Gianazza Se llen todo lo referente a los session beans.

WorkS 21