El documento describe diferentes modelos de componentes en Java, incluyendo JavaBeans, EJBs, servlets y mensajes impulsados por eventos. Explica que un componente es una unidad de software reutilizable con un contrato bien definido. Los EJBs, incluidos los beans de sesión y los beans impulsados por mensajes, son los componentes estándar en Java EE. Los servlets permiten desarrollar aplicaciones web dinámicas almacenando estado conversacional en sesiones HTTP.

1. JPA
Abimael Desales López
www.facebook.com/JavaDevelopersMexico

2. Modelos de Componentes de
Aplicaciones
Componente es una unidad de software reutilizable,
autocontenida que puede ser integrada en una aplicación.
Los clientes interactúan con los componentes vía un contrato
bien definido. En Java, la forma más simple de componente
de software es el JavaBean, comúnmente referido sólo como
un bean. Los beans son componentes son implementados en
términos de una sola clase cuyo contrato está definido por
los patrones de nombrado de los métodos en el bean. Los
patrones de nombrados de JavaBean son tan comunes ahora
que es fácil olvidar que fueron originalmente intentados para
darle a los constructores de interfaces de usuario una forma
estándar de tratar con componentes de terceras partes.

3. Modelos de Componentes de
Aplicaciones
El modelo estándar de componentes para Java EE es el
modelo EJB, el cual define formas para empaquetar, deployar,
e interactuar con servicios de negocio autocontenidos. El tipo
de EJB determina el contrato requerido para interactuar con
él. Los beans de sesión utilizan interfaces Java estándar para
definir el conjunto de métodos de negocio que pueden ser
invocados en ellos, mientras que el comportamiento de un
bean message-driven está determinado por el tipo y formato
de los mensajes que el bean está diseñado para recibir.
Usar componentes requiere organizar la aplicación en capas,
con servicios de negocio viviendo en el modelo del
componente y servicios de presentación en la capa superior
de él.

4. Modelos de Componentes de
Aplicaciones
Beneficios que un conjunto de servicios de negocios bien
definidos trae a una aplicación:
 Débil acoplamiento. Usar componentes para implementar
servicios fomenta el débil acoplamiento entre las capas de una
aplicación. La implementación de un componente puede
cambiar sin impacto alguno a los clientes u otros componentes
que dependan de él.
 Gestión de dependencias: Las dependencias para un
componente pueden ser declaradas en metadatos y
automáticamente resueltas por el contenedor.
 Gestión del ciclo de vida: El ciclo de vida de un componente es
bien definido y gestionado por el servidor de la aplicación.
Implementaciones del componente pueden participar en
operaciones del ciclo de vida para adquirir y liberar recursos, o
ejecutar otro comportamiento de inicialización o shutdown.

5. Modelos de Componentes de
Aplicaciones
 Servicios del contenedor declarativos: Los métodos de negocio
para componentes son interceptados por el servidor de la
aplicación con el fin de aplicar servicios tales como
concurrencia, gestión de transacciones, seguridad, y
remoting.
 Portabilidad: Los componentes que se apegan al estándar
Java EE y que son deployados a servidores basados en
estándares pueden ser más fácilmente portados de un
servidor que cumpla a otro.
 Escalabilidad y confiabilidad: Los servidores de aplicación
están diseñados para asegurar que los componentes son
gestionados eficientemente y con un ojo en la escalabilidad.
Dependiendo del tipo de componente y configuración del
servidor, las operaciones de negocio implementadas usando
componentes pueden reintentar llamadas fallidas a métodos o
aún conmutar a otro servidor en un clúster.

6. Modelos de Componentes de
Aplicaciones
Beans de Sesión
Los beans de sesión son una tecnología de componentes
diseñada para encapsular servicios de negocio. Las operaciones
soportadas por el servicio usualmente son definidas usando una
interface Java regular, a la que se le refiere como la interface de
negocio del bean de sesión. La implementación del bean es un
poco más que una clase Java regular que implementa la
interface de negocio si una está presente. Y aún, por virtud de
ser parte del modelo de componentes EJB, el bean tiene acceso
a un amplio rango de servicios de contenedor que puede
aprovechar para implementar el servicio de negocio. Una vez
que un cliente adquiere una referencia a un bean de sesión del
servidor, inicia una sesión con el bean y puede invocar
operaciones de negocio en él.
Hay tres tipos de bean de sesión: stateless, stateful y singleton.

7. Modelos de Componentes de
Aplicaciones
Beans de Sesión Stateless
Como lo mencionamos, un bean de sesión se establece para
completar una operación en el tiempo de vida de un sólo
método. Los beans stateless pueden implementar muchas
operaciones de negocio, pero cada método no puede asumir
que algún otro fue invocado antes de él.
Este es por mucho la forma más común de implementación
de servicio de negocio. Los beans de sesión stateless están
diseñados para llevar operaciones independientes de forma
muy eficiente. Los beans de sesión estateless pueden escalar
a grandes cantidades de clientes con mínimo impacto a
recursos del servidor en general.

8. Modelos de Componentes de
Aplicaciones
Definiendo un Bean de Sesión Stateless
Un bean de sesión es definido en dos partes:
 Cero o más interfaces de negocio que definen qué métodos
un cliente puede invocar en el bean. Cuando ninguna
interface es definida entonces el conjunto de métodos
públicos en la clase de implementación del bean forman
una interface lógica cliente.
 Una clase que implementa estas interfaces, llamada la
clase bean, la cual es marcada con la anotación @stateless.
La mayoría de los beans de sesión tienen una interface de
negocio, pero no hay restricción en el número de interfaces
que un bean de sesión puede exponer a sus clientes.

9. Modelos de Componentes de
Aplicaciones
Cuando el servidor encuentra la anotación @Stateless, sabe
tratar a la clase bean como un bean de sesión. Configurará el
bean en el contenedor EJB y lo hará disponible para usar por
otros componentes en la aplicación. La anotación @Stateless
y otras anotaciones escritas aquí están definidas ya sea en el
package javax.ejb o javax.annotation.
Veamos una implementación completa de un bean de sesión
stateless. El lista 1 muestra la interface de negocio que será
soportada por este bean de sesión. En este ejemplo el
servicio consiste de un sólo método, sayHello(), que acepta
un argumento String correspondiente al nombre de una
persona y retorna una respuesta String. No hay anotación o
interface padre para indicar que es una interface de negocio.

10. Modelos de Componentes de
Aplicaciones
Cuando es implementada por el bean de sesión, será
automáticamente tratada como una interface de negocio
local, significando que es accesible sólo a clientes en el
mismo servidor de aplicaciones. Para enfatizar que una
interface es una interface de negocio local, la anotación
@Local puede ser opcionalmente agregada a la interface.
Listado 1 La Interface de Negocio para un Bean de Sesion
public interface HelloService {
public String sayHello(String name);
}
Ahora vamos a considerar la implementación. la cual se
muestra en el listado 2.

11. Modelos de Componentes de
Aplicaciones
Esta es una clase Java regular que implementa la interface
de negocio HelloService. La única cosa que es única sobre
esta clase es la anotación @Stateless que la marca como un
bean de sesión stateless. El método de negocio es
implementado sin alguna restricción o requerimientos
especiales.
Listado 3.1 La clase Bean implementando la Interface HelloService
@Stateless
public class HelloServiceBean implements HelloService {
public String sayHello(String name) {
return "Hello, " + name;
}
}

12. Modelos de Componentes de
Aplicaciones
Callbacks del Ciclo de Vida
A diferencia de las clase Java regular usadas en código de la
aplicación, el servidor administra el ciclo de vida de un bean
de sesión stateless (lo cual afecta la implementación en dos
formas).
Primero, el servidor decide cuando crear y remover
instancias del bean. La aplicación no tiene control sobre
cuándo o cómo muchas instancias de un bean de sesión
stateless particular son creadas o alrededor de cuánto ellas
permanecerán.

13. Modelos de Componentes de
Aplicaciones
Segundo, el servidor tiene que inicializar servicios para el
bean después de que es construido, pero antes de que la
lógica de negocios del bean sea invocada. De forma similar,
el bean podría tener que adquirir un recurso cómo lo es una
fuente de datos JDBC antes de que los métodos de negocio
puedan ser usados. Sin embargo, para que el bean adquiera
un recurso, el servidor debe primero haber completado de
inicializar sus servicios para el bean. Esto limita la utilidad del
constructor para la clase debido a que el bean no tendrá
acceso a algunos recursos hasta que la inicialización del
servidor se haya completado.
Para permitir que el servidor y el bean puedan llevar a cabo
sus requerimientos de inicialización, los EJBs soportan

14. Modelos de Componentes de
Aplicaciones
métodos callback de ciclo de vida que son invocados por el
servidor en varios puntos en el ciclo de vida del bean. Para
los beans de sesión stateless, hay dos callbacks de ciclo de
vida: PostConstruct y PreDestroy. El servidor invocará la
callback PostConstruct tan pronto como hayan completado la
inicialización de todos los servicios del contenedor para el
bean. En efecto, esto remplaza al constructor como el lugar
para lógica de inicialización debido a que es sólo aquí que los
servicios del contenedor garantizan su disponibilidad. El
servidor invoca la callback PreDestroy inmediatamente antes
de que el servidor libere la instancia del bean para ser
recolectado. Algunos recursos adquiridos durante
PostConstruct que requieren shutdown explícito deben ser
liberados durante PreDestroy.

15. Modelos de Componentes de
Aplicaciones
Listado 3. Usando la Callback PostConstruct para adquirir un Logger
@Stateless
public class LoggerBean implements Logger {
private Logger logger;
@PostConstruct
public void init() {
logger = Logger.getLogger("notification");
}
public void logMessage(String message) {
logger.info(message);
}
}

16. Modelos de Componentes de
Aplicaciones
Interfaces de Negocio Remotas
Hasta aquí, sólo hemos discutido los beans de sesión que
usan una interface de negocio local. Local en este caso
significa que una dependencia en el bean de sesión puede ser
declarada sólo por componentes Java EE que están corriendo
juntos en la misma instancia del servidor de aplicación. No es
posible usar un bean de sesión con una interface local desde
un cliente remoto, por ejemplo.
Para acomodar los clientes remotos, los beans de sesión
pueden marcar su interface de negocio con la anotación
@Remote para declarar que debe ser usable remotamente.
Marcar una interface como siendo remota es equivalente a
tener que extender la interface java.rmi.Remote.

17. Modelos de Componentes de
Aplicaciones
La referencia al bean que es adquirido por un cliente no es
más una referencia local en el servidor sino un stub de
Invocación Remota de Método (RMI) que invocará
operaciones en el bean de sesión desde a través de la red.
No se requiere soporte especial en la clase bean para usar
interfaces remotas.
Listado 4. Una Interface de Negocio Remota
@Remote
public interface HelloServiceRemote {
public String sayHello(String name);
}

18. Modelos de Componentes de
Aplicaciones
Hacer a una interface remota tiene sus consecuencias en
términos de performance y cómo son manejados los
argumentos a métodos de negocio. Las interfaces de negocio
remotas pueden ser usadas localmente en un servidor
corriendo, pero haciéndolo así podría resultar en sobrecarga
de red si la llamada al método es enrutada a través de la
capa RMI. Los argumentos a métodos en interfaces remotas
son también pasados por valor en vez de pasados por
referencia. Esto significa que el argumento es serializado aún
cuando el cliente es local al bean de sesión. Las interfaces
locales para clientes locales son generalmente un mejor
approach. Las interfaces locales preservan las semánticas de
las llamadas a métodos Java regulares y evitan los costos
asociados con la red y RMI.

19. Modelos de Componentes de
Aplicaciones
Beans Message-Driven

20. Modelos de Componentes de
Aplicaciones

21. Modelos de Componentes de
Aplicaciones
Servlets
Los servlets son una tecnología de componentes diseñada para
servir las necesidades de los desarrollers web quienes necesitan
responder a solicitudes HTTP y generar contenido dinámico en
retorno. Los servlets son la tecnología más vieja y más popular
introducida como parte de la plataforma Java EE. Ellos son la
base para tecnologías como Java Server Pages (JSP) y la
columna vertebral de frameworks web como Java Server Faces
(JSF).
Debido a su cumplimiento en el protocolo HTTP, el web es
inherentemente un estado medio. Al igual que los beans de
sesión stateless, un cliente hace una request, el servidor dispara
el método de servicio apropiado en el servlet, y se genera
contenido y es retornado al cliente. Cada request es
completamente independiente a la última.

22. Modelos de Componentes de
Aplicaciones
Esto presenta un reto debido a que muchas aplicaciones web
involucran alguna clase de conversación entre el cliente y el
servidor en la cual las acciones previas del usuario influyen en
los resultados retornados en las siguientes páginas.
Los servlets resuelven el problema del estado conversacional
con la sesión. No nos confundamos con el bean de sesión, la
sesión HTTP es un map de datos asociados con un id de sesión.
Cuando la aplicación solicita que una sesión será creada, el
servidor genera un nuevo id y retorna un objeto HTTPSesion que
la aplicación puede usar para almacenar pares de datos
clave/valor. Luego usa técnicas como cookies de navegador para
ligar el id de sesión con el cliente, ligándolos en una
conversación. Para las aplicaciones web, el cliente es
completamente ignorante del estado conversacional que es
rastreado por el servidor.

23. Modelos de Componentes de
Aplicaciones
Usar la sesión HTTP de forma efectiva es un elemento
importante del desarrollo de servlets. El listado 11 demuestra
los pasos requeridos para solicitar una sesión y almacenar los
datos conversacionales en ella. En este ejemplo, suponiendo
que el usuario se ha logueado, el servidor almacena el id de
usuario en la sesión, haciéndolo disponible para uso en todas
las solicitudes siguientes por el mismo cliente. La llamada a
getSession() en el objeto HttpServletRequest() retornará ya
sea la sesión activa o creará una nueva si no existe una. Una
vez creada, la sesión actúa como un map, con pares
clave/valor asignados y retomados con los métodos
setAttribute() y getAttribute(), respectivamente.

24. Modelos de Componentes de
Aplicaciones
Listado 11. Manteniendo Estado Conversacional con un Servlet
public class LoginServlet extends HttpServlet {
protected void doPost(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
String userId = request.getParameter("user");
HttpSession session = request.getSession();
session.setAttribute("user", userId);
// ...
}
}

25. Modelos de Componentes de
Aplicaciones
Gestión de Dependencias
La lógica de negocio de un componente Java EE no siempre es
autocontenida. La implementación depende de otros recursos
hosteados por ser servidor de aplicaciones. Esto podría incluir
recursos del servidor como fuentes de datos JDBC o colas de
mensajes JMS, o recursos definidos por la aplicación como beans
de sesión o entity manager para una unidad de persistencia
específica.
Para manejar estas dependencias, los componentes Java EE
soportan la noción de referencias a recursos que son definidas
en metadatos para el componente. Una referencia es un link
nombrado a un recurso que puede ser dinámicamente resuelto
en tiempo de ejecución desde el código de la aplicación o
resuelto automáticamente por el contenedor cuando la instancia
del componente es creado.

26. Modelos de Componentes de
Aplicaciones
Una referencia consiste de dos partes: un nombre y un destino.
El nombre es usado por el código de la aplicación para resolver
la referencia dinámicamente, mientras que el servidor usa la
información destino para encontrar el recurso por el que la
aplicación está buscando. El tipo de recurso a ser localizado
determina el tipo de información requerida para hacer match
con el destino. Cada referencia a recurso requiere un conjunto
diferente de información específica al tipo de recurso al que se
refiere.
Una referencia es declarada usando una de las anotaciones de
referencia a recursos: @Resource, @EJB, @PersistenceContext,
o @PersistenceUnit. Las anotaciones pueden ser puestas en una
clase, campo, o método setter. La elección de la ubicación
determina el nombre default de la referencia, y si el servidor
resuelve o no automáticamente la referencia.

27. Modelos de Componentes de
Aplicaciones
Búsqueda de Dependencias

28. Modelos de Componentes de
Aplicaciones

29. Modelos de Componentes de
Aplicaciones
Inyección de Dependencias

30. Modelos de Componentes de
Aplicaciones

31. Modelos de Componentes de
Aplicaciones
Declarando Dependencias
Las siguientes secciones describen algunas de las
anotaciones definidas por las especificaciones Java EE y EJB.
Cada anotación tiene un atributo name para especificar
opcionalmente el nombre de la referencia para la
dependencia. Otros atributos en la anotación son específicos
al tipo de recurso que necesita ser adquirido.
Referenciando un Persistence Context
En el entorno Java EE, la anotación @PersistenceContext
puede usarse para declarar una dependencia en un contexto
de persistencia y tiene el entity manager para ese contexto
de persistencia adquirido automáticamente.

32. Modelos de Componentes de
Aplicaciones
El listado 16 demuestra el uso de la anotación
@PersistenceContext para adquirir un entity manager a
través de inyección de dependencias. El elemento unitName
especifica el nombre de la unidad de persistencia en la cual el
contexto de persistencia estará basado.
Listado 16. Inyectando la Instancia a un EntityManager
@Stateless
public class EmployeeServiceBean implements EmployeeService {
@PersistenceContext(unitName="EmployeeService")
EntityManager em;
// ...
}

33. Modelos de Componentes de
Aplicaciones
Después de los warnings sobre usar un campo estático en un
bean de sesión stateless, podrías estar preguntándote como
es que este código es legal. Después de todo, los entity
manager deben mantener su propio estado para ser capaces
de gestionar un contexto de persistencia específico. Las
buenas nuevas es que la especificación fue diseñada con la
integración de Java EE en mente, de forma que lo que es
inyectado en el Listado 16 no es la instancia a un entity
manager. El valor inyectado en el bean es un proxy
gestionado por el contenedor que adquiere y libera contextos
de persistencia a mitad del código de la aplicación. Es seguro
asumir que el valor inyectado “hará las cosas bien”.

34. Modelos de Componentes de
Aplicaciones
Referenciando a una Persistence Unit
El EntityManagerFactory para una unidad de persistencia
puede ser referenciado usando la anotación
@PersistenceUnit. Al igual que la anotación
@PersistenceContext, el elemento unitName identifica la
unidad de persistencia para la instancia EntityManagerfactory
que queremos accesar. Si el nombre de la unidad de
persistencia no es especificado en la anotación, es específico
del proveedor cómo será determinado.
El listado 17 demuestra la inyección de la instancia de una
EntityManagerFactory en un bean de sesión stateful. El bean
luego crea la instancia de un EntityManager de la factory
usando la callback de ciclo de vida PostConstruct.

35. Modelos de Componentes de
Aplicaciones
Listado 17. Inyectando una Instancia de EntityManagerFactory
@Stateful
public class EmployeeServiceBean implements EmployeeService {
@PersistenceUnit(unitName="EmployeeService")
private EntityManagerFactory emf;
private EntityManager em;
@PostConstruct
public void init() {
em = emf.createEntityManager();
}
// ...
}
La EntityManagerFactory para una unidad de persistencia casi
no es usada en el entorno Java EE debido a que los entity
managers son más fáciles de adquirir y usar.

36. Modelos de Componentes de
Aplicaciones
Referenciando Enterprise JavaBeans

37. Modelos de Componentes de
Aplicaciones

38. Modelos de Componentes de
Aplicaciones
Auditando Recursos del Servidor

39. Modelos de Componentes de
Aplicaciones

40. Modelos de Componentes de
Aplicaciones
Gestión de Transacciones
Más que cualquier otro tipo de aplicación empresarial, las
aplicaciones que usan persistencia requieren atención
cuidadosa a temas de gestión de transacciones. Cuándo
inician las transacciones, cuándo terminan, y cómo los entity
managers participan en las transacciones gestionadas por el
contenedor son todos los tópicos esenciales para
desarrolladores que usan JPA.
Una transacción es una abstracción que es usada para
agrupar una serie de operaciones. Una vez agrupadas, el
conjunto de operaciones es tratada como una sola unidad, y
todas las operaciones deben producirse o ninguna de ellas se
producirá. La consecuencia de que sólo algunas de las

41. Modelos de Componentes de
Aplicaciones
operaciones fueran exitosas produciría una vista
inconsistente de los datos que sería perjudicial o indeseable a
la aplicación. El término usado para describir si las
operaciones proceden juntas o no en todo es llamado
atomicidad y es argumentablemente la más importante de
las cuatro propiedades básicas que son usadas para
caracterizar como se comportan las transacciones. Es
fundamental comprender estas cuatro propiedades para
comprender las transacciones. La siguiente lista resume
estas propiedades:
 Atomicidad: Ya sea que todas las operaciones en una transacción
sean exitosas o ninguna de ellas. El éxito de cada operación
individual está atada al éxito del grupo completo

42. Modelos de Componentes de
Aplicaciones
 Consistencia: El estado resultante al final de una transacción se
adhiere a un conjunto de reglas que definen aceptabilidad de los
datos. Los datos en el sistema entero son legales o válidos con
respecto al resto de los datos en el sistema.
 Aislamiento: Los cambios hechos en una transacción son visibles
sólo a la transacción que está haciendo los cambios. Una vez que
una transacción emite los cambios, ellos son atómicamente
visibles a otras transacciones.
 Durabilidad: Los cambios hechos a una transacción perduran más
allá de que se haya completado la transacción.
Una transacción que reúne todos estos requerimientos se dice que
es una transacción ACID (el término familiar ACID es obtenido de
combinar las primeras letras de cada una de las cuatro
propiedades).

43. Modelos de Componentes de
Aplicaciones
Transacciones empresariales en Java EE
Las transacciones realmente existen en diferentes niveles del
servidor en el servidor de aplicación empresarial. La más
baja y más básica transacción está en el nivel del recurso, el
cual en nuestra discusión se asume que es base de datos
relacional presentado por una DataSource. Esta es llamada
una transacción de recurso-local y es equivalente a una
transacción de base de datos. Estos tipos de transacciones
son manipuladas interactuando directamente con la
DataSource JDBC que es obtenida del servidor de
aplicaciones. Las transacciones de recursos locales son
usadas de forma mucho más infrecuente que las
transacciones gestionadas por el contenedor.

44. Modelos de Componentes de
Aplicaciones
Demarcación de Transacciones
Cada transacción tiene un inicio y un final. Iniciar una
transacción permitirá subsecuentes operaciones para llegar a
ser una parte de la misma transacción hasta que la
transacción se haya completado. Las transacciones pueden
ser completadas en una o dos formas. Ellas pueden ser
emitidas, causando que todos los cambios sean persistidos al
almacén de datos, o retraídas, indicando que los cambios
deben ser descartados. El acto de causar que una transacción
inicie o se complete es titulado demarcación de transacción.
Esta es una parte crítica de escribir aplicaciones
empresariales, debido a que hacer la demarcación de
transacciones de forma incorrecta es una de las fuentes más
comunes de degradación del performance.

45. Modelos de Componentes de
Aplicaciones
Las transacciones de recursos locales son demarcadas
explícitamente siempre por la aplicación, mientras que las
transacciones de contenedor pueden ser demarcadas
automáticamente por el contenedor o usar una interfaz JTA
que soporte la demarcación controlada por la aplicación. En
el primer caso, cuando el contenedor toma la responsabilidad
de demarcación de transacción, la llamamos gestión de
transacción manejada por el contenedor, pero cuando la
aplicación es responsable para la demarcación, la llamamos
gestión de transacción manejada por el bean.
Los EJBs pueden usar transacciones gestionadas por el
contenedor o transacciones gestionadas por el bean. El estilo
de gestión de transacción default para un componente EJB es
gestionada por el contenedor.

46. Modelos de Componentes de
Aplicaciones
Para configurar un EJB para tener un sus transacciones
demarcadas de una forma a otra, la anotación
@TransactionManagement debe ser especificada en la clase
bean de sesión o message-driven. El tipo enumerado
TransactionMangementType define BEAN para transacciones
gestionadas por bean y CONTAINER para transacciones
gestionadas por el contenedor.
Transacciones Gestionadas por el Contenedor
La forma más común para demarcar transacciones es usar
transacciones gestionadas por el contenedor (CMTs), las
cuales le evitan a la aplicación el esfuerzo y código para
iniciar y emitir transacciones explícitamente.

47. Modelos de Componentes de
Aplicaciones
Los requerimientos de transacción son determinados por
metadatos en beans de sesión y message-driven y son
configurables en la granularidad de ejecución de método. Por
ejemplo, un bean de sesión puede declarar que siempre que
cualquier método específico en ese bean sea invocado, el
contenedor debe asegurar que una transacción haya iniciado
antes de que el método inicie. El contenedor también sería
responsable para emitir la transacción después de completado el
método.
Es común para un bean invocar a otro bean desde uno o más de
sus métodos. En este caso, una transacción que puede haber
sido iniciada llamando al método no habría sido emitida debido a
que el método llamante no se habrá completado hasta que su
llamada al segundo bean se haya completado. Esto es porque
necesitamos configuraciones para definir como el contenedor
debe comportarse cuando un método es invocado en un
contexto transaccional específico.

48. Modelos de Componentes de
Aplicaciones
Por ejemplo, si una transacción ya está en progreso cuando
un método es llamado, podría esperarse que el contenedor
sólo hiciera uso de esa transacción, mientras que podría ser
dirigido para iniciar una transacción nueva si ninguna
transacción está activa. Estas configuraciones son llamadas
atributos de transacción, y ellas determinan exactamente
cual es el comportamiento transaccional gestionado por el
contenedor.
Los selecciones de atributos de transacción definidos son los
siguientes:
 MANDATORY: Si este atributo es especificado para un
método, se espera que una transacción ya haya sido
iniciada y esté activa cuando el método es llamado. Si
ninguna transacción está activa, se lanza una excepción.

49. Modelos de Componentes de
Aplicaciones
Este atributo es muy pocas veces usado, pero puede ser una
herramienta de desarrollo para atrapar errores de demarcación
de transacción cuando se espera que una transacción ya debe
haber sido iniciada.
 REQUIRED: Este atributo es el caso más común, en el cual un
método se espera que esté en una transacción. El contenedor
proporciona una garantía que una transacción esté activa para
el método. Si una está activa, se usa; si no existe una, se crea
una nueva transacción para la ejecución del método.
 REQUIRES_NEW: Este atributo es usado cuando el método
siempre necesita estar en su propia transacción; esto es, el
método debe ser emitido o retraído independientemente de
métodos más arriba de la pila de llamadas. Debe ser usado
con precaución debido a que puede llevar a sobrecarga
excesiva de transacciones.

50. Modelos de Componentes de
Aplicaciones
 SUPPORTS: Los métodos marcados con SUPPORTS no son
dependientes de una transacción, pero tolerarán correr
dentro de una si existe. Este es un indicador que no son
accesados recursos transaccionales en el método.
 NOT SUPPORTED: Un método marcado a transacciones not
support causará que el contenedor suspenda la transacción
actual si una está activa cuando el método es llamado.
Implica que el método no ejecute operaciones
transaccionales, pero podría fallar en otras formas que
podrían afectar indeseablemente la salida de una
transacción. Este es un atributo no muy usado
comúnmente.

51. Modelos de Componentes de
Aplicaciones
 NEVER: Un método marcado a never soporta transacciones
que causarán que el contenedor lance una excepción si una
transacción está activa cuando el método es llamado. Este
atributo es muy raramente usado, pero puede ser una
herramienta de desarrollo para cachar errores de
demarcación de transacciones cuando se espera que las
transacciones ya deben haber sido completadas.
En cualquier momento que el contenedor inicie una
transacción para un método, el contenedor asume también
intentar emitir la transacción al final del método. Cada vez
que la transacción actual deba ser suspendida, el contenedor
es responsable para reanudar la transacción suspendida en la
conclusión del método.

52. Modelos de Componentes de
Aplicaciones
El atributo transaction para un método puede ser indicado
anotando una clase bean de sesión o message-driven, o uno
de sus métodos que es parte de la interface de negocio, con
la anotación @TransactionAttribute. Esta anotación requiere
un sólo argumento del tipo enumerado
TransactionAttirbuteType, los valores del cual son definidos
en la lista anterior. Anotar la clase bean causará que el
atributo transaction aplique a todos los métodos de negocio
en la clase, mientras que anotar un método aplica el atributo
sólo al método. Si ambas anotaciones a nivel de clase y de
método existen, la anotación a nivel de método toma
precedencia. En ausencia de anotaciones
@TransactionAttribute a nivel de clase o de método, el
atributo default de REQUIRED será aplicado.

53. Modelos de Componentes de
Aplicaciones
Usando Componentes JEE

54. Modelos de Componentes de
Aplicaciones

55. Modelos de Componentes de
Aplicaciones
GRACIAS
Dudas y comentarios a la página o al correo:
it.adesales@gmail.com
Es un placer escribir para ustedes