1.

Introduccin a los Enterprise JavaBeans (EJBs)

Los Enterprise JavaBeans son cdigo java del lado del servidor tambin conocido como EJB. Los EJBs son clases
Java con caractersticas que lo hacen mucho ms potente y robusto.
Los mtodos de un EJB son transaccionales
Los mtodos pueden ser Remotos
Facilidad de comunicacin con las bases de datos
Los mtodos pueden ser seguros, contienen la lgica de nuestro negocio.
etc.
Normalmente los EJBs tienen la lgica de negocio de nuestra aplicacin Java y por lo tanto cumplen el Rol de la
capa de servicio de nuestras aplicaciones, segn se estudi en la seccin anterior.
Al da de hoy los EJBs son clases puras de Java, POJOS los cuales al ser desplegados en un servidor de
aplicaciones permiten reducir la complejidad de programacin agregando robustez, reusabilidad y escalabilidad
a nuestras aplicaciones empresariales de misin crtica.
Hoy ms que nunca la versin de EJB 3.1 puede ser programados una vez y ejecutados en cualquier servidor de
aplicaciones Java, nicamente debe de tener soporte para la versin empresarial 6, los EJBs ya han cumplido
ms de una dcada desde su aparicin y al da de hoy son una de las tecnologas ms utilizadas
En la figura podemos observar el cdigo java del lado del servidor, este es un Enterprise Java Beans, el cual
puede ser utilizado por una aplicacin conocida como cliente.
Este cdigo de cliente realiza una peticin a nuestro componente EJB pudiendo ser una llamada local, si se
encuentra dentro del mismo servidor java o una llamada remota si se encuentra fuera del servidor.
Si la llamada es remota se utiliza el protocolo RMI (Remote Method Invocation) es parte del estndar Java SE.
Este es solo un ejemplo de tipo de cliente, sin embargo podemos tener clientes de diferentes tipos como
pueden ser clientes de escritorio, clientes web, o incluso clientes de aplicaciones Mviles.

Caracterices de un EJB
En una arquitectura tpica de java empresaria los EJB juegan el roll de la capa de servicio donde es comn
encontrar muchas de las reglas de negocio de nuestra aplicacin.
Cuando un EJB se ejecuta en un contenedor Java EE que soporta EJBs, el contenedor agrega los siguientes
servicios disponibles:
Servidor de aplicaciones:
o Libre. GlassFish, JBoss
o Paga. WebSphere, Oracle WebLogic
Los EJBs al ejecutarse dentro de un contenedor empresarial tienen a su disposicin varias
caractersticas que pueden utilizar tales como:
o Seguridad
o Llamadas Asncronas
o Llamadas remotas por medio de RMI
o Web Services
o Manejo de Transacciones por medio de JTA
o Inyeccin de dependencias por medio de CDI
o Acceso a Pool de conexiones
o Manejo de concurrencias seguro (Thread-Safety)
o Manejo de tareas programadas (Scheduling)
o Manejo de mensajera
o Interceptores que aplican el concepto de AOP
o etc
Los servidores de aplicaciones java tambin agregan otras caractersticas tales como balance de cargas,
tolerancia a fallos, etc.
Esto permite crear aplicaciones de misin crtica con operaciones 7x24x365 as que independientemente del
tipo de servidor de aplicaciones que utilicemos tendremos todas estas caractersticas disponibles al crear y
desplegar EJB.
2. Configuracin de Enterprise JavaBeans
Configuracin y tipos de EJB que existen
En versiones previas al EJB 3.0 el programador deba de crear varias clases e interfaces para hacer
funcionar una EJB por ejemplo una interface local o remota o ambas, y un archivo de configuracin
XML conocido como deployment descriptor.
A partir de la versin 3.0 se comenz a utilizar las anotaciones para su configuracin y
La versin 3.1 continua agregando y simplificando la integracin de tegnologia empresariales a travs
del concepto de anotaciones, este concepto simplifico en gran medida, el desarrollo de Enterprice
JavaBeans, y en general de toda la tecnologa Java.

La configuracin de un Enterprise JavaBeans a paratir de la versin 3.X queda como sigue:
o Una clase pura de Java conocida como POJO
o A la cual se le agrega una anotacin en la definicin de la misma y esto da como resultado un
EJB en su v3 en adelante.

Tipos de Enterprise JavaBeans:
A esta clasificacin se le conoce como EJB de seccin, un Bean de seccin se invoca por el cliente para ejecutar
una operacin de negocio especfica, y tenemos las siguientes clasificaciones:
@Stateless. No guardan estados del usuario es decir no guardan ningn tipo de informacin despus
de terminada una transaccin o incluso durante la transaccin y se utiliza la anotacin @Stateless
@Stateful. Este tipo de EJB mantiene un estado de la actividad del cliente por ejemplo si se tiene un
carrito de compras, este estado se puede recordar incluso una vez terminada la transaccin pero si el
servidor se reinicia esta informacin se pierde, este tipo de EJB es similar al alcance de sesions de una
aplicacin Web y se utiliza la anotacion @Stateful
@Singleton. Este tipo de Beans utiliza el patrn de diseo singleton lo que significa que solamente
existe una instancia de memoria de esta clase, este tipo de Beans se utiliza mucho para almacenar
informacin que consideramos en cache debido a que esta informacin se va a mantener durante todo
el tiempo que exista este Bean en memoria y podra durar incluso durante todo el ciclo de vida de
nuestra aplicacin

Sin embargo los EJBs que en mayo medida utilizaremos se conocen como Stateless, ya que los Stateful
normalmente ese tipo de requerimientos los resolvemos con la capa Web, utilizando el alcance de sesions.
Y los tipos Stateless nos permitirn ejecutar los mtodos que contienen la lgica del negocio de nuestra
aplicacin y normalmente la lgica de nuestro negocio no guarda ningn tipo de informacin relacionada
con ningn usuario debido a que las reglas de negocio son genricas para todos los usuarios, as que
nuestros ejercicios nos enfocaremos ms a la creacin se sesion Bean de tipo Stateless.

Formas de comunicarnos con un EJB
Vamos a revisar las formas de comunicacin con un eEB
La versin 2 inclua ms conceptos y ms complejidades segn lo hemos comentado.
La versin 3 estos conceptos se han simplificado considerablemente, los EJBs pueden ser configurados de
la siguiente forma con el objetivo de permitir la comunicacin con sus mtodos:
Tenemos el cdigo del cliente
Tenemos el cdigo del lado del servidor, nuestro EJBs.
o Este EJBs puede crear interfaces que pueden ser de tipo local, este tipo de interfaces se
utilizan cuando el cliente se encuentra dentro del mismo servidor Java de esta manera se evita
la sobre carga de procesamiento al utilizar llamadas remotas va RMI.
o Tambin el EJB puede exponer sus mtodos de negocio atraves de una interfaz remota, esta
interfaz se utiliza cuando el cdigo del cliente esta fuera del servidor de aplicaciones Java, es
decir en una Java VM, y por lo tanto debemos hacer llamadas remotas para poder ejecutar los
mtodos del negocio del EJB y a partir de la versin 3.1 se incluy el concepto de No Interface.
Esto es una simplificacin de que ya no se requiere de una interface para establecer la
comunicacin con nuestro EJB, siempre y cuando las llamadas sean locales es decir dentro del
mismo servidor de aplicaciones Java, en resumen tenemos:
La interface local la cual se utiliza cuando el cliente se encuentra dentro del mismo servidor java
Interface Remota: se utiliza cuando el cliente se encuentra fuera del servidor Java.
No interface. Es una variante y simplificacin de los EJB locales, es decir cuando estamos dentro del
mimo servidor java, sin embargo en este caso ya no es necesario definir una interface para poder
comunicarnos con nuestra clase EJB. Si no que directamente podemos hacer uso de los mtodos de
negocio de esta clase java.





Anatoma de un EJB
En la siguiente figura podemos observar la estructura general de un EJB, el cual puede implementar o no una
interface (local o remota), y puede tener uno o ms mtodos de negocio:



Podemos observar que nuestra clase HolaMundoEJB, simplemente agregando la anotacin
@Stateless ya es una EJB de tipo Stateless
Adems puede implementar o no una interface y esta interface tambin puede ser anotada con
anotacin de @remote o @local.
Y adems un EJB puede tener uno o ms mtodos de negocio

Previo a la versin empresarial 5 se requera crear varias clases para hacer funcionar a un EJB como hemos
comentado, a partir de la versin 3 ya no es necesario incluso utilizar el archivo que se conoca como
Descriptor EJB ejb-jar.xml este archivo contena la definicin de los Enterprise java Beans sin embargo con el
uso de anotaciones segn observamos en la figura este tipo de configuracin se ha simplificado enormemente,
aunque el cdigo de la figura mostrado es muy simple debemos hacer nfasis y recordar que un EJB es un
componente que se ejecuta en un contenedor java.
Este ambiente de ejecucin es el que permite agregar las caractersticas empresariales a nuestras clases java
permitiendo realizar llamadas remotas, inyeccin de dependencia, manejos de estado, ciclo de vida, pooling de
objetos, manejo de mensajera, manejo de transacciones, seguridad, soporte de concurrencia, interceptores,
manejo de mtodos asncronos, entre varias caractersticas ms.

Todo esto ocurre simplemente desplegando nuestro EJB en un servidor de aplicaciones java, esto permite que
el programador java se enfoque en los mtodos de negocio, y delegue todas estas caractersticas de
requerimientos empresariales a los servidores java.

3. Inyeccin de Dependencias en Java EE

Crear EJB va JNDI
JNDI es una API que permite encontrar servicios o recursos empresariales en un servidor de aplicaciones Java
Como crear un cliente y comunicarnos con nuestro EJB utilizando la tecnologa de JNDI, JNDI es una API que
permite encontrar servicios o recursos empresariales en un servidor de aplicaciones java en un inicio JNDI era
la nica manera de encontrar los componentes EJBs pero como se introdujo el concepto de EJBs locales y el
manejo de anotaciones existieron otras maneras de ubicar y proporcionar una referencia de los componentes
empresariales que se necesitan, a este concepto se le conoce como inyeccin de dependencias.
Adems previo a la versin 6 empresarial, no exista un nombre estndar para ubicar a los EJBs por medio del
Api de JNDI por lo que cada servidor de aplicaciones java brindaba una sintaxis distinta para ubicar a los
componentes empresariales.
A partir de la versin 6 se introdujo un nombre global para ubicar a estos componentes

Para encontrar un EJB a partir de la versin 3.1 podemos utilizar la siguiente sintaxis:
Java:global[/<app-name>]/<module-name>/<bean-name>[!<fully-qualified-interface-name>]

<app-name> Nombre de la aplicacin si es que se defini
<module-name> Nombre del modulo
<bean-name> Nombre del Bean
<fully-qualified-interface-name> Define el nombre completamente calificado de la clase java

Por ejemplo


Inyeccin de dependencias
En la figura mostrada podemos observar un ejemplo en capas de una arquitectura empresarial, en este
ejemplo la clase cliente en la capa presentacin necesita de un componente EJB en la capa de servicio, el cual
puede estar ubicado en el mismo servidor y podramos hacer una llamada local o fuera del mismo y tendramos
que hacer una llamada remota, adems esta clase EJB necesita implementar esta interface para establecer la
comunicacin y que se pueda ejecutar el cdigo del EJB.



Para que la clase cliente pueda ejecutar el componente EJB el servidor de aplicaciones proporciona una
referencia de dicho objeto, a esto se le conoce como inyeccin de dependencia y si la llamada al componente
JV es remota se recomienda utilizar la anotacin @EJB para realizar la inyeccin de dependencia de esta
referencia. O tambin se requiere inyectar algn recurso empresarial como puede ser un DataSource, la unidad
de persistencia de JPA, un Web Service, si queremos mantener compatibilidad con la versin empresarial 5,
etc.

Y si la llamada es local, es decir dentro del mismo servidor java se recomienda utilizar la anotacin @inject
Cabe destacar que esta es la forma de inyeccin de dependencia que se apoya del concepto de CDI y esta
disponible a partir de la versin Java 6, esta forma es ms flexible y robusta.

Para que el servidor de aplicaciones java reconosca el concepto de CDI se debe de agregar un archivo llamado
Beans.xml



En resumen lo que va a hacer nuestro servidor de aplicaciones es ubicar un objeto ya sea que corresponda con
el nombre o con el tipo del EJB que estamos buscando y va a inyectar la referencia en una propiedad de la clase
cliente y va a inyectar esta referencia que estamos solicitando al servidor de aplicaciones.
Bsicamente este es el concepto de inyeccin de dependencias y lo estaremos utilizando en ejercicios
posteriores.

4. Empaquetamiento y contenedores en Java EE

Java Web Profile
En la figura podemos observar el API de Java EE y en partcula la relacin con el perfil Web el cual tiene acceso
solo a algunas APIs , este web profile o perfil web, podemos observar que es una simplificacin del API
completo del Java Empresarial.

Sin embargo si requerimos del API completo de la versin empresarial podemos observar que tenemos muchas
APIs ms, el perfil Web surgi debido a que muchas de las aplicaciones empresariales no necesitaban de todo
el poder de las API tan robustas con las que cuenta la versin empresarial, por lo tanto solo se agregaron a este
perfil Web las API ms comunes, lo bueno de esto es que podemos utilizar EJB 3,1 en nuestras aplicaciones
Web sin agregar la complejidad de configuracin de los EJBs en versiones anteriores, de echo la versin Java
Empresarial 6 es posible utilizar EJBs locales, sin necesidad de empaquetarlos por separado en un archivo JAR,
si no utilizando nicamente un archivo WAR.

Lo que hay que resaltar de esta figura es que tenemos acceso a las APIs de EJBs, JPA, JTA, CDI, entre otras, si
necesitamos de otras APIs como es JavaMail, WebServises, Manejo asncrono de objetos, entonces ser
necesario utilizar un servidor de aplicaciones completo y no nicamente el perfil WEB.

Seleccionar un tipo de perfil, depender de los requerimientos actuales y futuros de nuestra aplicacin
Empresarial,


Vamos a revisar a continuacin una comparacin de los EJBs y la versin EJB Lite que podemos utilizar en el
Perfil Web, sin duda alguna los componentes predominantes en una aplicacin empresarial son Enterprise
JavaBeans los cuales agregan de manera muy simple conceptos como transaccionalidad, seguridad entre
muchas otras caractersticas que estudiaremos ms adelante, segn la lmina anterior podemos utilizar el
perfil Web de Java empresarial y utilizar EJBs.

Ese tipo de EJBs que podemos utilizar en el perfil Web, se le conoce como EJB Lite, las limitaciones que
tenemos en el perfil web, son la limitantes que tenemos cuando utilizamos EJB por ello el concepto de Lite.

Podemos observar que muchos de los requerimientos empresariales ms comunes si tenemos acceso a estas
APIs as que podemos observar que esto simplifico en gran medida las aplicaciones web que necesitan este tipo
de requerimientos empresariales sin sacrificar el performans ni el rendimiento de nuestras aplicaciones Java.

Empaquetamiento de un EJB
Como cualquier componente empresarial, los EJB tambin deben empaquetarse para ser desplegados en un
servidor Java EE.

Debido a que una aplicacin empresarial incluye distintos tipos de componentes tales como Servlets, paginas
JSF, WebServises, EJB, etc. Estos componentes deben de ser empaquetados para ser desplegados en un
servidor de aplicaciones Java.

En la versin 2 la nica manera de empaquetar un EJB era en un archivo JAR (Java Archive File), y
posteriormente este archivo se empaquetaba en un archivo ms genrico conocido como EAR (Enterprise
Archive File).

Este archivo EAR puede empaquetar a su vez archivos WAR (Web Archive File), en el cual podemos encontrar
el archivo web.xml de configuracin de nuestra aplicacin Web.

Tambin este archivo EAR puede almacenar nuestros archivos EAR los cuales contienen la configuracin de
nuestros EJBs y nuestro archivo ejb-jar.xml en caso de que fuera necesario.

Y por ultimo tenemos tambin la configuracin de nuestras clases de identidad y nuestro archivo de
configuracin persistence.xml.

Sin embargo si utilizamos el perfil web de aplicaciones empresariales podemos empaquetar toda nuestra
aplicacin en un archivo WAR sin la necesidad de generar de generar nuestro archivo EAR. En este archivo
podemos empaquetar cada una de nuestras clases, ya sea Servlets, EJBs, o clases de identidad y tambin
podemos almacenar nuestros archivos de configuracin si es que los tuviramos almacenados. Como puede ser
ejb-jar.xml, persistence.xml y web.xml.

En resumen en versiones anteriores anteriores a la versin 6 necesitabamos empaquetar forzosamente por
separado nuestras clases Java he incluso en nuestra versin 6 si vamos a utilizar llamadas remotas de igual
manera es necesario empaquetar nuestros EJBs de manera
separada. Pero si estamos utilizando la versin 6 y el perfil web
tambin a su vez EJB Lite, entonces podemos utilizar
directamente el empaquetamiento en un archivo de tipo WAR
tambin conocido como WEB Archive File.



Contenedor Embebido Java EE

Un contenedor embebido tiene como finalidad proveer un ambiente de ejecucin Java EE. Atreves de este
contenedor podemos acceder a los servicios como pueden ser servicios transaccionales, de seguridad, de
mensajera, etc.
Una de las grandes ventajas es que todo esto debe de estar soportado dentro de un ambiente Estndar de
Java, por lo que podemos hacer pruebas unitarias y ya no dependemos de un servidor de aplicaciones
completo para Validar si un EJB funciono correctamente, entonces el contenedor embebido bsicamente nos
va a permitir ejecutar EJBs en ambientes estndar de java.



Un ejemplo de esto es el cdigo mostrado a continuacin, la primera lnea de cdigo, crea un nuevo
contenedor EJB, este es precisamente el contenedor embebido y lo podemos inicializar de manera
programtica.
Una vez que este inicializado este contenedor obtenemos el contexto del mismo (Lnea 2)
Una vez con el contexto podemos obtener/solicitar va JNDI un componente EJB (Lnea 3).
Y una vez que ya tenemos este componente EJB podemos mandar a llamar los mtodos de nuestra clase EJB.

Aunque de alguna manera todava son varias lneas de cdigo anteriormente este procedimiento simplemente
no era posible, en versiones previas a la versin Java SE 6 no exista manera de realizar pruebas unitarias de
manera tan sencilla utilizando nuestras clases y en este caso un contenedor embebido de Enterprise JavaBeans.

Este tipo de contenedores los estaremos poniendo en prctica para realizar las pruebas unitarias de nuestros
Enterprise JavaBeans y nos permitir reducir los tiempos de desarrollo y de Testing de nuestras aplicaciones
empresariales.

Ejercicios 3 y 4.
Abrir el documento PDF de ejercicios del curso de Spring Framework.

Realizar las siguientes prcticas
Ejercicio 3. Creacin de nuestro primer EJB y Testing.
Ejercicio 4. Escribiendo un cliente de nuestro EJB.






Ejercicio 3. HolaMundo Con EJB, Maven y Junit

Arquitectura Java EE
En este ejercicio vamos a agregar un EJB de sesin local y sin interface, es decir, nicamente una clase POJO, y
la convertiremos en un EJB de tipo Stateless simplemente agregando la anotacin @Stateless, adems
agregaremos una prueba unitaria para comprobar el funcionamiento de nuestro EJB de Seccin:



Lo que vamos ha hacer es crear del lado del servidor, crear nuestro componente EJB y simplemente va ha ser
una clase de Java y va a ser un EJB de tipo local debido a que va a ser una implementacin sin interface.

Posteriormente vamos a crear nuestro cliente, este cliente puede ser una clase java con un mtodo main o en
nuestro caso una prueba unitaria junit. Y vamos a utilizar el nombre del EJB utilizando la anotacion de JNDI
para ubicar nuestro componente en el servidor y poder recuperar una referencia de una instancia de este EJB.

De esta manera el cliente va a poder hacer uso de los mtodos definidos en el EJB.

Paso 1.
Creamos un nuevo proyecto HolaMundo EJB utilizando MAVEN



Marcamos que sea un proyecto simple, Create a simple Project (skip archetetype selection). Next.
Datos de nuestro proyecto:
Group id: mx.com.gm
Artifact Id: holamundo-ejb
Version: 1.0
Packaging: jar
Damos en Finalizar.

Se crean las carpetas necesarias, ahora modificamos nuestro archivo pom.xml para agregar las libreras de
MAVEN


Paso 2.
Abrimos nuestro archivo pom.xml y agregamos el siguiente contenido despus de la etiqueta de versin. La
ruta del archivo .jar mostrado, depender de la ruta de instalacin de Glassfish, por lo que la debern de
adecuar a su ruta de instalacin.










Podemos darle formato a lo introducido con Ctrl + Shift + F

Y bsicamente lo que estamos haciendo es definir la ubicacin de un JAR conocido como:
glassfish-embedded-static-shell.jar

El cual nos va a permitir, es ejecutar el contenedor embebido de glassfish.
Lo nico que estamos haciendo es definir una variable que vamos a utilizar posteriormente.



Paso 2.1 Agregamos libreras Maven (cont)
Como siguiente paso vamos a agregar las dependencias en nuestro mismo archivo pom.xml y estas
dependencias, se declaran dentro de un tag llamado
<dependencies>

</dependencies>

<properties>
<endorsed.dir>${Project.build.directory}/endorsed</endorsed.dir>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding >
<glassfish.embedded-static-shell.jar>
C:\AppServers\glassfish3.1.2\glassfish3\glassfish\lib\embedded\glassfish-embedded-static-shell.jar
</glassfish.embedded-static-shell.jar>
</properties>


<dependency>
<groupId>org.glassfish.extra</groupid>
<artifactId>glassfish-embedded-static-shell</artifactId>
<version>3.1</version>





















Y todo esto luego de </properties>

En este cdigo hacemos referencia al JAR de glassfish-embedded-static-shell, lo que estamos haciendo aqu es
ubicar el JAR de glassfish que se necesita para iniciar el contenedor embebido.

Posteriormente lo que hacemos es definir un grupo de dependencias las cuales vamos a utilizar el api de java
EE, simplemente agregando esta librera ya tenemos disponible el api de Java EE en nuestro proyecto.

Y finalmente agregamos la dependencia de Junit para poder ejecutar nuestra prueba unitaria.

2.2 como siguiente paso vamos a tomar la definicin de un plug-in para obtener las libreras de glassfish que
vamos a utilizar. Lo agregamos antes de cerrar el tag de </project>
El cual define las libreras de glassfish que estamos utilizando, existen varios repositorios de MAVEN y en el
caso de glassfish podemos encontrar y descargar las libreras que necesitemos para nuestro proyecto.









3. Agregar una nueva Clase HolaMundoEJB dentro de de src/main/java, dentro del paquete beans
Como se puede observar es una clase pura de java
Ahora lo convertiremos en un bean de tipo @Stateless
o La etiqueta nos marcara error, para ello introducimos Ctrl + Shift + O para importar la(s) libreras
necesarias.
o Donde @Stateless es una anotacion pero finalmente es una clase de java.

<pluginRepositories>
<pluginRepository>
<id>maven2-repository.dev.java.net</id>
<name>Java.net Repository for Maven</name>
<url>http://download.java.net/maven/glassfish</url>
</pluginRepository>
</pluginRepositories>

Ahora creamos un mtodo dentro de esa clase llamado sumar, el cual solo se va a encargar de sumar
dos nmeros, algo muy simple pero que nos dejara ver el funcionamiento de HolaMundoEJB.
o Este mtodo ya es transaccional y ya soporta todas las caractersticas de los EJBs.
o Esta es una de las grandes ventajas ya que con una sola etiqueta ya podemos crear nuestro EJB.
o Sin embargo este EJB es simple ya que no est implementando ninguna interface.
o Es un EJB de tipo local y de tipo @Stateless sin interface por ello este cdigo est muy simplificado.

4. Ahora crearemos nuestra prueba unitaria dentro del paquete src/test/java
Empezamos por crear una clase pura, en el paquete ya mencionado
o Le ponemos por nombre HolaMundoEJBTest
o Y este estar dentro del paquete secundario test
Este tendr el siguiente cdigo

Para iniciar nuestra prueba se coloca la etiqueta @Before
o He colocamos un mtodo llamado iniciarContenedor() con extensin a Exeption
o EJBcontainer.createEJBContainer(); Inicializa nuestro contenedor embebido de glassfish
o Con ayuda del contenedor solicitamos el contexto respectivo.
Y finalmente va JNDI podemos solicitar una referencia de nuestro EJB.
o Con ayuda del contexto, utilizando el mtodo lookup, vamos a utilizar un nombre, el cual es un
nombre global y es portable en cualquier servidor EJB.
Al finalizar la lnea nos marcara error por lo que hay que realizar un cast debido a que esto
nos regresa un object (con clic derecho sobre el error).

Y con esto ya tenemos una referencia a nuestro EJB.

Ahora si ya inicializamos nuestra prueba unitaria colocando un @Test
Colocamos un mtodo que sera nuestra prueba, este se expande de Exception.
o Lo que hace es una prueba para ver que nuestro EJB, realmente este sumando los valores que le
proporcionemos.
o Con ejb.sumar(dato1,dato2) hace la llamada a nuestro ejb,
o Con esta referencia, ejb ya podemos empezar a ocupar los mtodos de nuestro ejb.
Agregamos el mtodo assertEquals() simplemente para comprobar que los datos que
estamos que estamos proporcionando deben de ser igual a los datos resultado, importamos.

Finalmente ejecutamos nuestro cdigo.

Notas Rpidas:
o En caso de que nos pida algunas importaciones ello introducimos Ctrl + Shift + O para importar la(s)
libreras necesarias.
o Para el caso de private static Context contexto; se importa el paquete de javax.naming.Context;
o Para colocar un System.out.println(); Se coloca sysout y enseguida se teclea Ctrl + Barra Espaciadora.









package mx.ids.test;

import static org.junit.Assert.*;
...
import org.junit.Test;

public class HolaMundoEJBTest {
private static EJBContainer contenedor;
private static Context contexto;
private static HolaMundoEJB ejb;
























Verificamos el resultado de HolaMundoEJBTest y verificamos que se ejecut sin ningn error.

Ejercicio 4. EJB Sesin
El objetivo del ejercicio es agregar un EJB de sesin a nuestro proyecto SGA (Sistema de Gestin de Alumnos),
el cual desarrollaremos a lo largo del curso
Al finalizar deberemos observar un listado de personas, el cual ser ejecutado, desde nuestro EJB,



Arquitectura Java EE
A lo largo del curso vamos a ir agregando componentes a nuestro Sistema SGA (Sistema de Gestin de
Alumnos), el cual se encargara de administrar un catlogo de personas. Esta aplicacin es una aplicacin Web,
pero puede tener clientes remotos y Web Services, la cual nos permitir administrar un catlogo de personas
desde diferentes clientes. Vamos a iniciar con la siguiente arquitectura.




En el caso anterior solo tenamos una implementacin de una PersonaServiceImpl en este caso tendremos
tambin una interface remota posteriormente el EJB, la clase de implementacin va a implementar esta clase
remota. Y esta clase a su vez va a utilizar un objeto de tipo persona con el cual vamos a recuperar un listado de
objetos de este tipo, una vez que ya hayamos definido los componentes del lado del servidor (derecha), lo que
vamos a hacer es definir una aplicacin cliente, esta aplicacin cliente puede estar en el mismo servidor o
tambin puede estar en una maquina distinta por lo tanto vamos a mandar a llamar nuestra interfaz remota
del servidor, esto est utilizando en automtico el RMI, es decir estamos haciendo llamadas remotas a nuestro
EJB adems vamos a utilizar el nombre JNDI para poder ubicar una instancia de esta interfaz o de este tipo
(PersonServiceRemote), al final de cuentas la clase que se va a utilizar es la implementacin
(PersonaServiceImpl) sin embargo siempre vamos a utilizar una referencia de nuestra interfaz para poder
obtener un bajo acoplamiento de nuestra configuracin de la arquitectura de nuestro sistema SGA.

Desarrollo
Paso 1. Creamos un nuevo proyecto
2. en el caso de usar glassfish y maven configurar el pomp.xml




Agregamos una nueva clase dentro de mx.ids.sga.domain debido a que esta clase de persona la considersamos
como una clase de dominio del problema de nuestro sistema.

Entonces la clase Persona la depositamos dentro del paquete, la cual es una clase pura de Java, la cual la
convertiremos en una clase de identidad, cuando veamos el tema de JPA por el momento vasta con agregar lo
siguiente.

Clase Persona
Esta clase debido a que se va a enviar por la red, debido a que estamos utilizando el protocolo RMI y
podramos recibir llamadas desde fuera de este servidor necesitamos que esta clase sea del tipo
Serializable simplemente implementando esta interfaz es posible enviar esta clase atreves de la red en
llamadas remotas



El cual agrega un atributo la Serializacin serialVersionUID con un valor por default, debido a que cuando
estamos enviando este objeto por la red podra tener diferentes versiones, en llamadas locales cuando
estamos dentro del mismo servidor esto no es necesario, sin embargo debido a que este tipo de objetos de
tipo sesin es recomendable que implementen esta clase por defecto.
El siguiente paso es agregar una interface de tipo persona service la cual ser una interface remota dentro del
paquete mx.ids.sga.servicio el cual se llamara PersonaServiceRemote


Para convertir esta interface en una interface remota basta con agregar la anotacin @Remote



Esta interface nos va a permitir llamar los mtodos de nuestro EJB como sabemos una interface no contiene
implementacin nicamente es un contrato que nos va a permitir tener un bajo acoplamiento al utilizar
nuestra interface y la llamada a nuestro EJB entonces bsicamente es nuestro intermediario con nuestro
cliente, vamos a agregar los mtodos para poder administrar nuestro catalogo de personas las cuales son muy
bsicos, pero nos van a permitir realizar las operaciones bsicas con nuestro catalogo de personas.


}
Con esto ya tenemos nuestra interface de tipo remoto.

Ahora vamos a agregar la implementacin de esta interface en el mismo paquete sga/servicio creando
una nueva clase PersonaServiceimpl y la clase que va a implementar es PersonaServiceRemote



Este al crearlo en automtico nos va a agregar una implementacin de todos los mtodos que
definimos en nuestra interface, asi que ya tenemos nuestro esqueleto de la interface PersonaServiceimplesin
embargo esta aun no es una clase de tipo EJB para convertirlo en un EJB basta con agregar la anotacin de
@Stateless

Ahora si ya tenemos un EJB llamado PersonaServiceImpl y lo vamos a acceder atreves de
PersonaServiceRemote que es nuestra interface de tipo remoto

La implementacin de estos mtodos por el momento va a quedar con los elementos por default




Comenzaremos por definir el mtodo listarPersonas ya que es el que queremos probar desde el cliente de
nuestro EJB, lo que vamos hacer en este momento es agregar un listado en cdigo duro de un listado de
personas simulando registros de nuestra base de datos.
Comenzamos agregando una coleccin de personas
Y agregamos un par de personas a esta coleccin
A continuacin vamos a agregar una persona por lo que creamos en cdigo duro un objeto de tipo
persona, podemos utilizar el constructor vaco, sin embargo queremos que muestre datos, por lo tanto
se le agregan los siguientes elementos, utilizando el constructor no vaco.


Y lo que vamos hacer posteriormente una vez que mandemos a llamar a este mtodo, es regresar el listado de
personas con el return en cdigo duro que hemos creado. Esto posteriormente vamos a utilizar el API de JPA
para poder recuperar el listado de personas desde nuestra base de datos, en este caso solo es una
implementacin directa y en cdigo duro.

Con esto ya tenemos configurado nuestro EJB segn mostramos en la figura inicial, tenemos nuestra interface
tipo remoto y tenemos la implementacin y esta implementacin ya tenemos un mtodo listar personas que
vamos a utilizar en nuestro cliente.

El siguiente paso es agregar la clase ClientePersonaService el cual va a ser el cliente de nuestro EJB y vamos a
realizar lo siguiente en nuestro paquete de src/main/java agregamos el paquete mx.ids.sga.cliente y
agregamos la clase cabe sealar que esta clase bien podra estar fuera del servidor que vamos a estar
trabajando. Debido a que vamos a utilizar la interface remota y estaramos haciendo llamadas remotas a
nuestro EJB va RMI y aunque esta prueba la vamos a realizar de manera local, realmente se est utilizando el
protocolo RMI y se est haciendo el mismo trabajo de llamada remota que si estuviramos fuera del servidor.

Agregamos el siguiente cdigo a nuestra clase, el cual se va a conectar via JNDI a nuestro servidor y va a
solicitar una instancia de nuestro EJB.
En este caso vamos a utilizar un APPI simplificado de glassfish y la clase initialContext, con esto bsicamente
nos estamos ahorrando varias de las configuraciones de propiedades que debemos especificar cuando
utilizamos JNDI, si estamos utilizando otros servidores de aplicaciones, debemos de revisar las
documentaciones del servidor, en este caso estamos utilizando la versin simplificada de glassfish para poder
conectarnos a nuestro servidor y poder solicitar una instancia de nuestro EJB, debido a que esta llamada podra
generar una excepcin por lo que se debe de englobar en un try/catch posteriormente agregamos la llamada
remota a nuestro EJB utilizamos nuestro jndi y el mtodo lookup, vamos a utilizar el nombre global de nuestro
ejb, en este caso estamos adelantndonos un poco al nombre sin embargo cuando hagamos el despliege de
este EJB, el cual ser necesario para poder ejecutar nuestro cliente vamos a especificar el nombre de nuestra
aplicacin llamada sga-jee, esto lo vamos a realizar posteriormente cuando hagamos el despliege de nuestro
ejb en nuestro servidor de glassfish, enseguida especificamos el nombre de nuestro EJB y posteriormente el
nombre de la interface que vamos a utilizar para recuperar la instancia de nuestro EJB, debemos especificar el
nombre completamente calificado de nuestra interface, sin embargo este cdigo necesitamos realizar un cast
debido a que regresa un object.

Con esto ya tenemos la llamada del JDNI utilizando el nombre global el cual es portable en cualquier servidor
JAVAEE y con eso estamos recuperando una referencia y utilizando la interface PersonaServiceRemote para
poder recuperar una referencia de nuestro EJB personaService una vez que ya tenemos nuestro objeto
personaService lo que vamos ha hacer es solicitar el mtodo listarPersonas podemos observar que tenemos el
listado de mtodos y mandamos a llamar listarPersonas(); debido a que este mtodo fue el que
implementamos en nuestro EJB, recordemos que este cdigo posiblemente este en otro servidor y debido a
que vamos a regresar objetos de tipo persona, esta clase Persona debe ser Serializable de lo contrario va a
marcar un error al querer enviar estos objetos atraves de la red, importamos la clase java.util y tambin
importamos la clase persona.

Con esto ya deberamos de tener nuestro listado de personas, ahora lo que vamos a hacer es un for para iterar
esta coleccin, simplemente para desplegar los valores que hayamos obtenido de nuestro servidor, recuerde
que al invocar persona que corresponde a la clase se invoca el mtodo toString().
Con esto ya tenemos a nuestro cliente del EJB, sin embargo debido a como hemos comentado que el EJB se
encuentra en el servidor de glassfish, lo que necesitamos es desplegar, primero nuestro EJB en el servidor y
posteriormente hacer la llamada desde nuestro cliente, si se trata de iniciar nuestra aplicacin en ete momento
nos marcara un error (error Corba debido a que se utiliza el protocolo RMI basado en este protocolo, por lo
tanto no exite la comunicacin y tampoco pudimos encontrar el componente EJB en nuestro servidor)
dicindonos que no hay comunicacin con el servidor, por lo cual para que exista tal comunicacin primero
debemos levantar nuestro servidor de glassfish y tambin debemos tener desplegado nuestro componente
EJB, esta llamada puede demorar debido a que es una llamada remota y se esta utilizando el protocolo RMI.

Por lo tanto el siguiente paso es desplegar nuestro componente EJB que creamos anteriormente en el servidor
y posteriormente ejecutar nuestro cliente



Vamos a utilizar maven para generar el JAR respectivo de este proyecto, para esta tarea debemos
primeramente detener nuestro servidor, para poder realizar nuestras pruebas unitarias de nuestro EJB.
Damos Click derecho sobre nuestro proyecto, Run As, Maven install



Esto creara nuestro Jar dentro de nuestro proyecto


Una vez con esta ruta, lo que vamos hacer, es inicializar nuestro servidor de glassfish y desplegar este
componente que hemos empaquetado, recientemente con maven y desplegarlo en nuestro servidor de
glassfish.
Para ello vamos a la consola de servers


Le damos clic derecho a nuestro servidor, glassfish, View Admin Console. O desde nuestro Explorador
introducimos http://localhost:4848/

Y con la ruta del archivo que ya tenemos previamente, lo que vamos a hacer es desplegar esta aplicacin desde
el servidor glassfish.

Nos vamos a Applications.


Damos en Deploy


Nos pedir la ruta del archivo que queremos desplegar, en este caso colocamos la ruta donde se genero
nuestro archivo sga.jee.jar

La introducimos se llenan los formatos por default y le damos aceptar.








































JavaBeans IDS



Estilos de Arquitectura
Multiniveles
Multicapas
SOA
Cliente-Servidor

Arquitectura Aplicativa Estandar


El problema del dominio
Seguridad
Transaccionalidad
Concurrencia
Escalabilidad
Interoperabilidad
Robustez
Mantenimiento

Soluciones Java
JDBC / Base de Datos
JavaServlets
Java Class (POJOS)
SpringFramework Beans
Context & Dependency Injection (CDI)

Enterprise JavaBeans
Framework para desarrollar y desplegar aplicaciones de negocio basadas en componentes
Modelo de componentes del lado del servidor para aplicaciones de negocio distribuidas

Arquitectura Java EE SOA

En una arquitectura Java EE SOA, Los End Points pueden ser implementados con EJB
Las interfaces soportadas son SOAPService o RESTService.

EJB con el patrn MVC
Modelo: @Stateless
cmp Arquitectura SOA
AS/JavaEE
Negoci o
Exposicin
Dominio/Servicios Persistencia
Infraestructura
JAX-WS/RS
JMS
EJB
CDI
JPA
JDBC
Dominio/Servicios
Persistencia
Exposicin
JAX-WS/RS
SCA
EJB
CDI
JPA
JDBC
Integracin
JAX-WS
JMS
SCA
EJB
Remote


EJB puede completar la implementacin del patrn MVC en el modelo.

Implementaciones
Las diferentes implementaciones de EJB estan asociadas a las implementaciones de Java EE 6.
A partir de la versin java EE 6 se agreg una versin ms ligera llamada Lite, donde solo soporta un
subconjunto de la especificacin.
La implementacin referencia de EJB es Glassfish

EJB 3.1 Lite
o Jboss AS 7
o Caucho Resin 4
o Apache TomEE 1
o Apache Geronimo 3
o Oracle Glassfish 3

EJB 3.1 Full Profile
o IBM WAS 8
o IBM CE 3
o Oracle Glassfish 3
o TMAX JEUS 7
o Fujitsu Interstarge AS
o Apache Geronimo 3
o Jboss AS 7

Ejemplo Bsico:

Requisitos:
El ambiente que necesitamos para comenzar con EJB es:
El entorno de desarrollo Oracle Enterprise Pack for Eclipse 4.2
cmp Components - EJB
Client
SecurityServiceEJB
UsuarioServiceEJB
EJB Contai ner
EJB Local
EJB Remote
JavaCLI
JAX-WS Cl i ent
JAX-RS Cl i ent
CDI Bean
JSF Bean
JSP/Servl et
EntityManager
Servidor de Aplicaciones Java EE 6
Configurado el Servidor dentro de Eclipse,
Archivos y Bibliotecas de la Capacitacin

Creacin de un nuevo proyecto:
Nombre: Training
Target: Glassfish 3.1.2
EAG Version: 6.0
Configuration: Default
Clic en el Boton Next

Creamos dos nuevos mdulos: EJB y WEB
New Module
o EJB Module
o WEB Module
Posteriormente los asociamos al proyecto empresarial.
Checamos por ultimo la generacin del archivo application.xml
Clic en el boton FInish

Mi primer EJB
Para crear nuestro primer EJB, inicialos el asistente de Eclipse
Creamos una clase basica en el proyecto EJB y agregamos el contenido que se muestra en la lamina.

New Java Class
TrainingEJB/mx.ids.service.HelloServiceEJB




Cliente de EJB
Los EJB no pueden ser invocados directamente por un navegador web solo proporcionan interfaces de
programacin aplicativa APIS.
Creamos un Servlet en el proyecto WEB y agregamos el contenido que se muestra para poder invocar el EJB
Ya en un navegador web escribimos la ruta del servlet.

JavaServlet


Tipos de EJB
La especificacin de EJB define 3 diferentes tipos:
Session Bean
o Intercambio de Informacin
Interactiva (dilogos)
Message-Driven Bean
o Procesamiento de mensajes
Entity Bean
o Representacin de objetos de negocio en un mecanismo de persistencia

Los subtipos de Session Bean son
Stateless (SLSBs). Los mas Utilizados para implementar operaciones de negocio
o Verbos de un Caso de Uso
o Operaciones de Negocio
o Compartidos entre peticiones
o Comunicacin En Lnea / Asncrona
Statefull (SFSBs). Pueden mantener informacin del cliente.
o Verbos de un Caso de Uso
o Operaciones de Negocio
o No Compartidos entre peticiones
o Comunicacin En Lnea
Singleton (SSBs). Soporte de concurrencia . Utilizados para implementar operaciones no funcionales
o Utileras de Negocio
o Operaciones de Infraestructura
o Uno por aplicacin
o Comunicacin En Lnea / Asncrona

Message-Driven Bean
Message-Driven Bean es un componente ms enfocado a la integracin y servicios de mensajera.
Integracin de Aplicaciones
Servicio de Mensajes (Bajo Acoplamiento)
Comunicacin asncrona
Compartidos entre peticiones
Java Message Service (JMS)

Existen dos subtipos Queue y Topic










Los elementos que integran un EJB :
- Una clase Java. La mayoria de las veces solo incluira mtodos, en algunos casos la implementacin de la
interface Serializable puede requerir.
- El registro via anotaciones o XML. Este registro le indica al EJB container en el despliegue que tipo de
EJB es, la transaccionalidad, y reglas de seguridad.


Clase Java
Constructor
Registro
Anotaciones
XML



EJB Container/Services

EJB Container
Proporciona un entorno de ejecucin para los EJB y otros componentes en el servidor de aplicaciones.
El contenedor maneja todos los aspectos para operacin del EJB y acta como intermediario entre la
lgica de empresa escrita por el usuario en el Bean y el resto del entorno del servidor de aplicaciones.

Los diferentes servicios que integra y soporta el EJB Container son:
Concurrency: de acuerdo al tipo de ejb
seguridad: JAAS
Instance pooling/caching: Pool por EJB
JNDI/Injection: CDI
Transactions: JTS
Interceptors (AOP) EJB Interceptor
Time Service: @CronService
LifeCycle: EJB Componente



JNDI
JNDI es un servicio de directorio de Java EE, permite a tener un nombre logico por cada componente
desplegado. Un cliente puede hacer referencia y uso con este nombre.
Java EE 6 estadarizo el nombrado lgico de componentes.


Java Naming and Directory Interface
java:global[/app-name]/module-name/bean-name [!FQN]

cmp EJB Container
JAX-WS
EJB Container
Bean Validator
JAX-RS
JMS
JPA
JTA
JavaMail
Appl i cati on Server
Stateless
Interceptors Stateful Singleton


JNDI & Interfaces
JNDI asigna un Nombre por cada interface que tenga un EJB. Si un EJB no cuenta con interface. Considera el
nombre de la clase como nombre lgico.

cmp JNDI
EJB Contai ner
PagosEJB
CalculadoraEJB
Servlet
Appl i cati on Server/ JavaEE
Web Contai ner
j dbc/oracle
mail/google
JMSQueue
EntityManager


Uso de JNDI
Los pasos para hacer uso de un EJB con JNDI es:
1.- Inicializacin del Contexto, por default es el mismo Application Server
2.- bsqueda del componente, se requiere saber cul es el nombre logico que asigno JNDI
3.- uso de capacidad, una vez obtenida una referencia del EJB se puede ya hacer uso de sus capacidades


cmp Interfaces
CalculadoraServiceEJB
Cal cul adoraServi ce
Cal cul adoraRemoteServi ce
Cal cul adoraWebServi ce
Cal cul adoraRestServi ce

Ejemplo de JNDI
En esta lamina se muestra un ejemplo del nombre que asigno JNDI para el EJB CalculadoraServiceEJB.
Este EJB no tiene implementada interface, JNDI utilizo el nombre de la clase para agregarlo a nombre logico.

CalculadoraServiceEJB
java:global/Curso/CursoEJB/CalculadoraServiceEJB
java:global/Curso/CursoEJB/CalculadoraServiceEJB!mx.ids.training.domain.api.services.CalculadoraServiceEJB]



El cliente JavaServlet inicializa el contexto y realizar la busqueda.

Dependency Injection
El Servicio de Dependency Injection nos permite eliminar las dependencias incrustadas en nuestro componente
y delegarlas al EJB Container. Solo tenemos que indeclar declarativamente que es lo que queremos utilizar y el
servicio nos injectara las depedencias.

Beneficios:
Bajo Acoplamiento
Eliminacin del Patrn Service Locator
Verificacin de tipos en tiempo de Compilacin




Diagrama Conceptual de DI
El uso de DI es realizado con anotaciones particulares de EJB o con anotaciones de CDI. La verificacin de tipos
es realizado en la fase compilacin.
Mientras que en ejecucin es la injeccin automatica.
Uso de Anotaciones
EJB & CDI



Ejemplo de DI
En esta lamina se muestra un ejemplo del uso de DI con un EJB como cliente.
El primer recurso configurado es EntityManger que utiliza la anotacion @PersistenceContext

Para declarar una dependecia de EJB se utiliza la anotacin @EJB

Cliente EJB

cmp Dependency Inj ection
EJB Contai ner
PagosEJB
CalculadoraEJB
Servlet
Appl i cati on Server/ JavaEE
Web Contai ner
j dbc/oracle
mail/google
JMSQueue
EntityManager
Cliente Servlet
Un cliente Servlet tambien puede hacer uso de la Injeccin de dependecias.



Application Server & DI
@Inject de CDI pertime integrar mas componentes que solo EJBs.
@PersistenceContext integra EntityMananer,
Para cualquier otro componente se utiliza @Resource

@javax.inject.Inject (CDI)
SessionBeans
POJOS/ CDI Beans
@javax.ejb.EJB
SessionBeans
@javax.persistence.PersistenceContext
javax.persistence.EntityManager
@javax.annotation.Resource
javax.transaction.UserTransaction
javax.sql.DataSource
javax.jms.Queue
javax.jms.Topic
javax.jms.QueueConnectionFactory
javax.jms.ConnectionFactory
javax.jms.TopicConnectionFactory
javax.mail.Session

Transaccin
Una transaccin: La ejecucin de un programa administrativo que desempea una funcin para acceder a una
recurso compartida.

Atmica
Todas o ninguna
Significa que se ejecutara completamente o nada
Consistente
Un programa de transaccin debe mantener la consistencia de la base de datos
Aislada
Un Conjunto de transacciones puede ejecutarse al mismo tiempo sin afectarse entre si
Durable
Al finalizar la transaccin todas las actualizaciones se almacenaran.

Java Transaction Service
JTS implementa el manjeo de transacciones.
JTS Sirve como un intermediario entre una aplicacin y mas de un recurso transaccional

Es una especificacin (Java EE) para implementar manejo de transacciones.
Recursos Transaccionales
Base de datos
Sistemas de Mensajera



Transaccin Programtica
Agregar soporte transaccional a EJBs se realiza hacer con el uso de JTA, que es una interface para manipular
programaticamente el inicio y finalizacin de transacciones.

Java Transaction API
javax.transaction.UserTransaction





Ejemplo de Transaccin Programtica
Adems de programar el inicio y fin de una transaccin en JTA, tambin se debe manipular cualquier tipo de
excepcin checada de la interface UserTransaction

@Resource
UserTransaction
Manejo de Excepciones



Transaccin Declarativa
Otra forma de integrar transaccionalidad en EJBs,
Es mediante un modelo Declarativo con anotaciones , donde solo se indica en que metodo se requiere
transaccin, y la propagacin de la misma

@TransactionAttribute
MANDATORY
Una transaccin es necesaria para llamar al mtodo.
Si ya hay una transaccin iniciada, el mtodo se unir a la transaccin.
Si no hay una transaccin iniciada, lanzara una TransactionRequiredException
Crear o actualizar JPA
NEVER
No puede ser invocado dentro de una transaccin.
Si ya hay una transaccin iniciada, lanzara una excepcin.
Si no hay una transaccin iniciada, llamara al mtodo.
NOT_SUPPORTED
No utilice una transaccin para llamar al mtodo.
Si ya hay una transaccin iniciada, se suspender hasta que el mtodo es completado.
Si no hay una transaccin iniciada, llamara al mtodo.

La propagacin que tiene por default cualquier mtodo de EJB es REQUIRED.
Una transaccionalidad declarativa permite excluir metodos de una transaccin.

@TransactionAttribute
REQUIRED
Una transaccin es necesaria para llamar al mtodo.
Si ya hay una transaccin iniciada, el mtodo se unir a la transaccin.
Si no hay una transaccin iniciada, comenzara una nueva transaccin.
Servicios de Dominio
REQUIRES_NEW
Una transaccin es necesaria para llamar al mtodo.
Si ya hay una transaccin iniciada, se suspender e iniciara una nueva transaccin.
Si no hay una transaccin iniciada, comenzara una nueva transaccin.
SUPPORTS
No se necesita una transaccin para llamar al mtodo.
Si ya hay una transaccin iniciada, el mtodo se unir a la transaccin.
Si no hay una transaccin iniciada, no comenzara una transaccin, NO.
Consultas Servicios Dominio, Repositorios

Ejemplo de Transaccin Declarativa
Stateless y statefull cuenta con soporte de transaccionalidad declarativa.
La demarcacin de una transaccin no afecta la logica programada dentro del cuerpo del metodo.


Excepciones en Transacciones
Cualquier Excepcin de sistema establece que la transaccin solo pueda finalizar como rollback.
Para configurar que una Excepcin aplicativa pueda establecer transacciones a solo a rollback, se agrega la
anotacin @ApplicationException y el atributo true en la definicin de la clase.

System Exception
java.lang.RuntimeException
java.rmi.RemoteException
Javax.ejb.EJBException
Application Exception
@javax.ejb.ApplicationException



Interceptor
Un Interceptor es un objeto administrado por el contedor que puede interponerse en la llamada de un metodo.
Muchas vences llamados aspectos o servicios transversales.
Utilizados para
Auditoria
Log Principal
Autorizacin
Autenticacin
Verificacin de Parmetros
Permite factorizar estas llamadas que son repeditas en los diferentes metodos i solo establecelas en un solo
objeto, el interceptor

Objetos administrados por el Contendor que pueden interponerse en la llamada de un mtodo, o
eventos del ciclo de vida.
Servicios Transversales


Ejemplo de Interceptor
Un Interceptor no requiere implementar una interface o extender de una clase especial.
Solo debe tener un metodo con el parametro InvocationContext y la anotacin @ArounInvoke









cmp Vista de Seguridad Servicio
Cliente
Intercetors
aspects::AutenticacionInterceptor
- sessi onServi ce :Sessi onServi ce
+ autenti caci on(Invocati onContext) :Obj ect
aspects::AutorizacionInterceptor
+ autori zaci on(Invocati onContext) :Obj ect
i nterface
services::UsuarioService
+ doCreate(ParamInputTO<Usuari o>) :ParamOutputTO<Usuari o>
+ doDel ete(ParamInputTO<Usuari o>) :ParamOutputTO<Usuari o>
+ doUpdate(ParamInputTO<Usuari o>) :ParamOutputTO<Usuari o>
+ doUpdatePassword(ParamInputTO<Usuari o>) :ParamOutputTO<Usuari o>
+ fi nd(ParamInputTO<Usuari o>) :ParamOutputTO<Usuari o>
+ getByID(ParamInputTO<Usuari o>) :ParamOutputTO<Usuari o>
Interceptor & EJB
El registro de un Interceptor en EJB es con la anotacin @Interceptors y la clase como atributo

EJB Stateless