EJB 3.

0 - JPA
OBJETIVOS

Afortunadamente, la comunidad Java conoce ahora mucho más los

problemas relacionados a la construcción de aplicaciones web y
empresariales que hace cinco años.
Hemos "aprendiendo haciendo" y la experiencia nos ha ayudado a
implementar soluciones más fáciles de controlar, partiendo desde
estándares a construir objetos de negocio del lado del servidor y que
ahora esta más a nuestro alcance!

EJB 3.0 es un estándar evolucionado del antiguo EJB 2.0, y que

nace con la jdk 5, este nos permitirá crear aplicaciones sin tener que
reinventar servicios como las transacciones, seguridad, persistencia
automática, etc.

El objetivo principal del curso es la de familiarizar al alumno con

dicho estándar.
CONTENIDO

Principales Módulos

– J2EE Containers.
– EJB 3.0
– Interfaz Home y Remoto
– Tipos de EJB
– Transaccionalidad
– Timer Services
– Interceptores y Entity Listener
– Web Services
– JPA
– EntityManager
– Persistence Context
– EntityManager Factory
– ApplicationTransaction
– Entity Inheritance
– Multi-tables Mappings

Metodología
Durante el curso se irán mostrando las transparencias a la vez que se van comentando los aspectos teóricos con los ejemplos
desarrollados.
 J2EE Containers.

El concepto de servidor de aplicaciones está relacionado con el concepto de sistema distribuido. Un sistema distribuido, en
oposición a un sistema monolítico, permite mejorar tres aspectos fundamentales en una aplicación: la alta disponibilidad, la
escalabilidad y el mantenimiento.
Centralización de las aplicaciones.
Disminución de la complejidad en el desarrollo.
Alta Disponibilidad.
Técnicas de balanceo de carga.
Recuperación de fallos (failover) .
Escalabilidad.
Seguridad.
Performance.
La alta disponibilidad hace referencia a que un sistema debe estar funcionando las 24 horas del día los 365 días al año.
La escalabilidad es la capacidad de hacer crecer un sistema cuando se incrementa la carga de trabajo (el número de
peticiones).
El mantenimiento tiene que ver con la versatilidad a la hora de actualizar, depurar fallos y mantener un sistema.

Existen diversas implementaciones, cada una con sus propias características que la pueden hacer más atractiva en el
desarrollo de un determinado sistema.
BEA WebLogic, IBM WebSphere, Oracla IAS, Jboss, Glassfish...

Arquitecturas de servidores.
 EJB 3.0

Los Enterprise JavaBeans son una de las API que forman parte del estándar de construcción de aplicaciones empresariales
J2EE .

El modelo de programación propuesto por la versión 2.1 de EJB conllevaba una serie de inconvenientes que limitaron mucho
el uso de esta especificación y conllevó la aparición de soluciones open source que suplían las carencias que presentaba EJB 2.1.

El objetivo de Enterprise JavaBeans (EJB) 3.0 es simplificar el desarrollo de aplicaciones Java y estandarizar el API de
persistencia para la plataforma Java.

Elimina la necesidad de construir interfaces EJB y descriptores de despliegue

innecesarios, y en lugar de esto, permite que los desarrolladores los generen
especificando anotaciones (similar a XDoclet). Esta aproximación libera a los
desarrolladores de crear descriptores de despliegue y de crear interfaces para los
componentes
Simplifica los EJBs para asemejarse a los POJOs o Java Beans.
Elimina la necesidad de tener interfaces de componentes para los EJBs.
Los beans de entidad no requieren ninguna interfaz de componente.
Los beans de entidad utilizarán ahora una interfaz POJO.
Elimina la necesidad de implementar métodos callback de ciclo de vida
innecesarios.
 EJB 3.0
Interfaz Remote y Home

Interfaz Remote: Los Beans ofrecen métodos concretos que pueden ser llamados por un cliente, aunque pueden existir
métodos que no sean públicos. Para ello a cada Bean le corresponde una interfaz ya sea Remota o Local, como mínimo un Bean
debe implementar UNA de estas interfaces, la interfaz Remote son para aquellos Beans que puedan ser llamados desde una
máquina virtual java distinta a donde se encuentra el servidor de aplicaciones.

Interfaz Home: normalmete se usan para ofrecer servicios a otros Sessions Beans que se encuentran en el mismo servidor
de aplicaciones, es decir, en la misma máquina virtual, pueden tratarse de métodos que aparezcan en un Bean cuya interfaz es
remota. Si alguien llama a un método de una interfaz local se encuentra ejecutándose bajo la misma máquina virtual, esto sirve
para por ejemplo iniciar subtransacciones.

Ejemplo de interface local:

@Local
public interface CustomerServiceLocal {

public void saveCustomer( Customer customer );

public Customer getCustomer( Long id );
public Collection getAllCustomers();
public void deleteCustomer( Customer customer );

Ejemplo de interface remota :

@Remote
public interface CustomerServiceRemote{

public void saveCustomer( Customer customer );

public Customer getCustomer( Long id );
public Collection getAllCustomers();
public void deleteCustomer( Customer customer );

}
Tipos de EJB
Tipos de EJB

Stateless Session Beans

Son EJB sin estado, no contienen atributos, para utilizarlos en distintas llamadas de los métodos del EJB.
@Remote
public interface POJIHello {
public void dimeAlgo();
}

@Stateless
public class POJOHello implements POJIHello {
public void dimeAlgo() {
System.out.println("Algo");
}
}

Ciclo de vida de los Stateless Session Beans

 Tipos de EJB

Stateful Session Beans

La principal diferencia es que un Stateful Session Bean estará siempre firmemente vinculada a la ejecución del cliente, es
decir, este tipo de beans tiene atributos que pueden ser accedidos, modificados, etc en las distintas llamadas al bean.

@Stateful
public class CestaBean implements CestaRemote {
protected Vector<Producto> cesta= new Vector<Producto>();
public void insertarProducto(Producto producto) throws CestaException {
if (producto== null)
throw new CestaException("Cesta ist null");

producto setUnidadesPedidas(best.getUnidades());
cesta.add(producto);
}
public Vector<Producto> getProductos() {
return cesta;
}
}

Ciclo de vida de los Stateful Session Beans

Tipos de EJB

Message Driven Beans (MBD): unos beans con una estrecha relación con JMS (Java Messaging Service).
De hecho la mayoría de los MBD son consumidores de mensajes JMS.
Los Message Driven Beans carecen de estado.
La comunicaicón entre un cliente y un Message-driven Bean siempre se produce mediante JMS.

@MessageDriven(mappedName = "MDBAuditoria", activationConfig = {

@ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"),
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue")
})
@Interceptors(ej4.AuditoriaListener.class)
public class MDBAuditoriaBean implements MessageListener {
public MDBAuditoriaBean() {
}

public void onMessage(Message message) {

try {
TextMessage text = (TextMessage) message;
String msg = text.getText();
System.out.println("MENSAJE="+msg);

} catch (Exception ex) {

ex.printStackTrace();
}
}
}
Tipos de EJB

Ciclo de Vida de MDB

Tipos de EJB

Entity Beans

Los Entity Beans son el portal a la base de datos, el paso intermedio al nivel de persistencia, aunque no siempre debe tratarse
de una base de datos relacional. Un Entity Bean es una clase java normal que representa con sus atributos las columnas de una
tabla de una base de datos, si se necesita crear una nueva fila en base de datos, se crea una nueva instancia del entity bean si se
desea modificar alguna columna de bd, se setea el atributo.
Una instancia de un entity bean representa una fila de una tabla de bd.
Por lo que hemos visto, los Entity Beans forman parte del estandár EJB 3.0 para la persistencia de datos == JPA

@Entity
@Table(name="CABIN")
public class Cabin implements java.io.Serializable {
private int id;
private String name;
@Id
@Column(name="ID")
public int getId(){
return id;
}
---setId()
@Column(name="NAME")
public String getName(){
return name;
}
--setName
}
Transaccionabilidad

Con el uso de las transacciones se asegura que una función compleja se ejecuta o no. Esto por ejemplo significa que los datos
en la base de datos sólo se modificarán cuando se ejecute la transacción de forma completa. La protección en la transacción se
refiere siempre al estado de los datos en base de datos y no a los valores que pueda tener el bean.

Container Managed Transaction (CMT)

El servidor de aplicaciones se ocupa del control completo de la transacción según las prescripciones que le indiquemos.

@TransactionAttribute
Cada método público de un session bean o message-driven bean puede dotarse de dicha anotación, de este modo se controla
el comportamiento de las transacciones en dicho bean.
La anotación suele realizarse a nivel de clase o de método, normalmente se encuentra en estos últimos.

Tipos de Transacciones:

NOT_SUPPORTED
SUPPORT
REQUIRED
REQUIRES NEW
MANDATORY
NEVER
Transaccionabilidad

@Stateful
public class CounterTestBean implements counterTestRemote{
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public void primerMetodo(){
// Si un cliente llama este método se inicia una nueva transaccion
otroMetodo();
}

@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public void otroMetodo(){

// Si este metodo es llamado por primerMetodo()

// no se crea ninguna transaccion nueva. Se utilizara
// la transaccion del primer metodo
// Si es el cliente el que llama directamente a este metodo
// se iniciara una nueva transaccion
}
}
Timer Service

Se suele utilizar cuando deseamos realizar un proceso controlado temporalmente, ya sea en una fecha determinada o cada
cierto intervalo de tiempo.

Se suele utilizar un Stateless Session Bean o un Message-driven Bean.

Los EJB 3.0 Entities NO estan disponibles para Timer Service.

TimedObject
Para poder utilizar Timer Service, un Stateless Session Bean o un Message-Driven Bean deben implementar la la interfaz
TimedObject, que consta de un sólo método.

En el estandar EJB3.0 existe también la posibilidad de dotar a cualquier método con la anotación @javax.ejb.Timeout

La ventaja de utilizar como temporizador un stateless session bean reside en que se pueden ofrecer métodos al cliente a través
de la interfaz para iniciar y detener el temporizador.
Timer Service

public class AlarmSchedulerBean implements AlarmSchedulerRemote {

@Resource
TimerService timerService;

public static final String COMANDO = "HSP";

public void startMonitor() {

timerService.createTimer(1 * 1000, 1 * 1000, COMANDO);
}

public void stopMonitor() {

for (Object obj : timerService.getTimers()) {
Timer timer = (Timer) obj;
String info = (String)timer.getInfo();
if (info.equals(COMANDO)) {
timer.cancel();
}
}
}

@Timeout
public void timeout(Timer timer) {
String info = (String)timer.getInfo();
if (info.equals(COMANDO)) {
System.out.println("Liberando memoria: "+ Runtime.getRuntime().freeMemory());
}
}
}
Interceptors y Entity Listeners

Un interceptor es una simple clase java cuyos métodos siempre se ejecutan cuando se llama al método de otra clase
totalmente diferente.
Un interceptor se puede configurar para un session bean (stateless ó stateful), o para un message-driven bean,
NO para los entity-beans.

@Stateless(mappedName="AuditoriaBean")
@Interceptors(ej4.AuditoriaListener.class)
public class AuditoriaBean implements AuditoriaRemote {

public void setTimeTrace(boolean trace) {}

public boolean getTimeTrace() {

return false;
}
}

public class AuditoriaListener {

@AroundInvoke
public Object auditoria(InvocationContext invocation) throws Exception {
try {
return invocation.proceed();
} finally {
String classe = invocation.getClass().getName();
String metodo = invocation.getMethod().getName();
String resultado = classe + ":" + metodo + " --> +new java.util.Date();
System.out.println(resultado);
}
}
}
Web Services

Un Web Services es cualquier servicio que pueda llamarse mediante los protocolos utilizados en el World Wide Web p
or un cliente situado remotamente.

Toda la comunicación entre un web services y su cliente e basa en XML, y está por tanto estandarizado,
el cliente envia una petición en XML al web service y como respuesta también recibirá un XML, ambos XMLs se
han creado bajo el estándar SOAP (Simple Object Access Protocol). Mediante SOAP se define el estándar que regula las reglas
de serialización o empaquetado de datos y generación de los mensajes transmitidos durante una transacción en la que se incluye
un WebService.

Los métodos disponibles en el web service, los parametros que recibe así como el tipo del valor que devuelve también se
define en un XML estándar, el WSDL (Web Service Description Language). Un XML WSDL puede interpretarse por cualquier
programa realizado en cualquier lenguaje y así escribir el mensaje SOAP a elaborar, con el que trabajará el cliente y el servidor.

Anotaciones para Web Services

@WebService
@WebMethod
@SOAPBnding
@WebParam
JPA

Es el API de persistencia desarrollada para la plataforma Java EE e incluida en el estandar EJB 3 (Enterprise Java Beans) .

El objetivo que persigue el diseno de esta API es no perder las ventajas de la orientacion a objetos al interactuar con una base
de datos, y permitir usar objetos regulares conocidos como POJOS (Plain Old Java Object )

Consta de:
•Java Persistence API
•Query Language
•Object relational mapping metadata
JPA

Ciclo de vida Entity Beans

El control real de un Entity Bean reside en el EntityManager, cuando se produce un evento en un entity bean,
el EntityManager llama a los métodos lifecycle-callback si la clase los ha implementado.

Métodos LifeCycle-Callbacks

PrePersist

PostPersist

PreRemove

PostRemove

PreUpdate

PostUpdate

PostLoad
JPA
JPA
EntityManager

Actualmente como hemos visto los entity beans son clases java normales enriquecidos con metainformación para que el
EntityManager se encuentre en posición de mantener sus atributos sincronizados con la base de datos.

EntityManager supervisará cada modificación en los atributos y decidirá a lo largo de la transación lo que es necesario para
mantener la consistencia entre los datos en memoria de los entity beans con los datos en base de datos.

Persistence Unit

Son todos los entity beans que controla el EntityManager.

Persistence Context

Es la suma de todos los entity beans que controla el EntityManager y el estado en el que se encuentran, es decir, se encuentra
definido por la transacción en la que se encuentra en un momento determinado.

EntityManager Factory

Las aplicaciones crean instancias de EntityManager en esos casos mediante el método createEntityManager de
javax.persistence.EntityManagerFactory.
JPA

Entity Inheritance

Dentro de los entity beans es posible construir jerarquías de herencia con las que el EntityManager puede tratar, para ello se
programan dos o más clases derivadas las unas de las otras y describe sus relaciones además con la anotación @Inheritance.

TIPOS:

SINGLE_TABLE

TABLE_PER_CLASS

JOINED
JPA

Multi-tables Mappings

En una base de datos relacional surgen inevitablemente una gran variedad de relaciones entre tablas de la base de datos.
Por ejemplo en una tabla de pedidos, habrá una referencia al id del usuario que hace el pedido, y no puede existir ningún
pedido por un usuario que no exista.

@JoinColumn

@PrimaryKeyJoinColumn

@PrimaryKeyJoinColumns

@OneToOne

@OneToMany

@ManyToOne

@ManyToMany
JPA

Performance

Como hemos podido ver en los ejemplos, JPA se apolla en un ORM para generar las consultas, en los ejemplos el que
hemos visto ha sido TopLink, pero existen otros que pueden hacer que las transacciones, recuperación de datos, etc, por parte de
la api se ejecute más rápido, como podemos ver en la siguiente comparativa realizada por el componente ORM Cocobase con
otros componentes compatibles con JPA.
Gracias

GRACIAS
POR
SU
ATENCIÓN

www.hrcs.es
info@hrcs.es

Edificio HEVIMAR II
Graham Bell 6, 2ª Planta, 8
Parque Tecnológico de Andalucía
29590 Málaga
Tfno. 952020113