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.