Download Sesión 5

Desarrollo de Componentes de
Negocio con Tecnología
Enterprise JavaBeans™ (EJB)
Contenidos
Introducción a Java Platform Enterprise Edition
Elementos de JEE
Un conjunto de especificaciones
Principales
Secundarias:
Java EE 5
JSR 220 (web services)
Tecnologías
Tecnologías
Tecnologías
Tecnologías
de
de
de
de
servicios web
aplicaciones web
aplicaciones de empresa
administración y seguridad
Kit de desarrollo de software Java EE 5 (Java EE 5
SDK)
Herramientas y servidores de aplicaciones Java EE
comerciales y de código abierto
Componentes y aplicaciones Java EE
Introducción a Java Platform Enterprise Edition
Especificaciones JEE
Introducción a Java Platform Enterprise Edition
Especificaciones JEE
Introducción a Java Platform Enterprise Edition
Arquitectura de contenedor de
componentes
Introducción a Java Platform Enterprise Edition
Implementación de la
arquitectura
Introducción a Java Platform Enterprise Edition
Contenedores JEE
Introducción a Java Platform Enterprise Edition
Tipos de componentes JEE
Introducción a Java Platform Enterprise Edition
Servicios Java EE: categorías
De implementación:
Persistencia
Transacciones
Seguridad
Inherentes:
API:
Asignación de nombres
Mensajería
Conectores
Del fabricante:
Configurados en XML
o con annotations
Usados desde código
Ciclo de vida
Subprocesos (threading)
Comunicación con
objetos remotos, como
RMI y CORBA
Capacidad de ampliación
Fail over
Balanceo de carga
Introducción a Java Platform Enterprise Edition
Servicios de contenedor
Introducción a Java Platform Enterprise Edition
Roles en JEE
Introducción a Java Platform Enterprise Edition
Proceso de creación de
aplicaciones EJB
Introducción a Java Platform Enterprise Edition
Comparación del desarrollo
con Java EE y tradicional
Contenidos
Introducción a la aplicación de subasta
Casos de uso
Introducción a la aplicación de subasta
Modelo del dominio
Introducción a la aplicación de subasta
Objetos del dominio (Auction)
Introducción a la aplicación de subasta
Objetos del dominio
(AuctionUser)
Introducción a la aplicación de subasta
Objetos del dominio (Bid)
Introducción a la aplicación de subasta
Objetos del dominio (Item)
Introducción a la aplicación de subasta
Objetos del dominio
(BookItem)
Introducción a la aplicación de subasta
Arquitectura de la
implementación
Ejecutar Auction v.1
Contenidos
Implementación de los beans de sesión EJB3.0
Comparación de beans de sesión
con y sin datos de estado
La mayoría de aplicaciones Java EE que
utilizan interfaces de usuario necesitan
que se mantengan los datos de estado
¿Dónde mantenerlo?
Capa de usuario
Capa Web HttpSession
Capa de base de datos
Capa de negocio beans de sesión con
estado
Implementación de los beans de sesión EJB3.0
Mantenimiento del estado
Capa de usuario (programa cliente)
Capa Web
En HttpSession
Capa de negocio (EJB)
Trasiego de datos
En EJBs con estado
Capa de base de datos
Carrito de la compra
Datos en varias páginas
Implementación de los beans de sesión EJB3.0
Beans sin estado
El bean no retiene información del cliente.
Entre invocaciones es posible que un cliente
no obtenga la misma instancia de bean de
sesión.
Una misma instancia de bean de sesión
puede manejar cualquier número de
solicitudes de cliente.
Mejora de rendimiento.
Implementación de los beans de sesión EJB3.0
Beans sin estado
Cuidado con los atributos de instancia
Características de los beans de
sesión con datos de estado
El bean pertenece a un cliente concreto
durante una conversación o sesión completa.
La conexión del cliente existe hasta que el
cliente elimina el bean o la sesión expira.
El tiempo de espera del bean de sesión suele
depender del intervalo de inactividad establecido
por el proveedor.
El contenedor mantiene una instancia EJB
separada para cada cliente.
Los beans de sesión con datos de estado
requieren más memoria por cliente que los beans
de sesión sin datos de estado.
Implementación de los beans de sesión EJB3.0
Beans con estado
Implementación de los beans de sesión EJB3.0
Declaración de interfaz de
negocio para bean de sesión
Declarar interfaz de negocio
Declarar las partes remotas y locales
Implementación de los beans de sesión EJB3.0
Interfaces locales y remotas
La implementación se puede
anotar con @Remote pero no
con @Local y @Remote a la vez
Un implementación puede ser
remota y local pero las anotaciones
van en cada interfaz
Implementación de los beans de sesión EJB3.0
Creación de bean de sesión que
implementa la interfaz de negocio
Implementación de los beans de sesión EJB3.0
Requisitos de la clase de
implementación
pública, no debe ser final ni abstracta
Constructor público que no acepte
parámetros.
El contenedor utiliza este constructor para
crear instancias de la clase de bean de
sesión.
No debe definir el método finalize.
Conexión local
Interfaz local
EJB Container
Vistas de cliente
locales y
distribuidas
mar-10
alb@uniovi.es
35
Conexión remota
Interfaz remota
EJB Container
Vistas de cliente
locales y
distribuidas
mar-10
alb@uniovi.es
36
Implementación de los beans de sesión EJB3.0
Interfaces locales y remotas
La implementación se puede anotar con @Remote
pero no con @Local y @Remote a la vez
Un implementación puede ser remota y local pero las
anotaciones van en cada interfaz
Ver en Auction v.1
Implementación de los beans de sesión EJB3.0
Todas las anotaciones
Tipo de bean
Tipo de acceso
@Remove
Acceso a recursos desde el EJB
@Remote, @Local
Cierre de sesión (en Statefull)
@Stateless, @Statefull
@EJB, @Resource
Ciclo de vida
@PostConstruct, @PreDestroy,
(Sólo statefull) @PostActivate, @PrePassivate
Implementación de los beans de sesión EJB3.0
Ciclo de vida de session beans
sin estado
Implementación de los beans de sesión EJB3.0
Ciclo de vida de session beans
con estado
Implementación de los beans de sesión EJB3.0
Definición de controladores de
eventos de ciclo de vida
Forma genérica
Implementación de los beans de sesión EJB3.0
Objeto SessionContext
Proporciona acceso al EJBObject (al
contenedor)
Entorno de seguridad
Información sobre el control de la transacción
Acceso a JNDI
Implementación de los beans de sesión EJB3.0
Metadatos de despliegue
En EJB 3.0: anotaciones y/o xml
Con anotaciones no es necesario el xml
Si están presentes los dos, el xml revoca
las configuraciones de anotaciones
Descriptores JEE:
Web: web.xml
EJB: ejb-jar.xml
Aplicaciones completas: application.xml
Implementación de los beans de sesión EJB3.0
Ejemplo de ejb-jar.xml
Implementación de los beans de sesión EJB3.0
Empaquetado
Web: <nombre>.war
EJB: <nombre>.jar
Aplicaciones:
<nombre>.ear
Ver en Auction v.1
Archivo JAR nomal
Descriptor ejb-jar.xml en
/META-INF
Contiene WAR + JAR
Descriptor application.xml
en /META-INF
Implementación de los beans de sesión EJB3.0
Posibles clientes
Otro EJB de sesion
Un servlet (o JSP compilado)
Clase Java normal
¿Cómo obtener una referencia al EJB?
Depende de si el cliente se ejecuta en un
contenedor o no (si es EJB/servlet o clase
normal)
Implementación de los beans de sesión EJB3.0
Con servicios de contenedor
Servlet o EJB local
El contenedor inyecta la referencia
Implementación de los beans de sesión EJB3.0
Con servicios de contenedor
Servlet o EJB remoto (en otro
contenedor)
Búsqueda JNDI
En ejb-jar.xml
o web.xml
Implementación de los beans de sesión EJB3.0
Sin servicios de contenedor
Clase Java (local o remota)
Se deben usar los servicios JNDI
Ver en Auction v.1
Contenidos
JPA: conceptos básicos
Persistencia
Necesidad de que los datos manejados
sobrevivan tras la ejecución del
programa
Muchas técnicas y tecnologías (ficheros,
serialización, bases de datos, etc)
JPA: especificación de un mapeador
objeto/relacional
JPA: conceptos básicos
Asignación estática: De clases
a tablas
JPA: conceptos básicos
Mapeador ORM
Diseño e implementación con OO pero
persistencia en BDD relacional
Diferentes paradigmas (diferencias
estructurales, dinámicas, etc.)
Se busca tener persistencia automática
y (casi) transparente
Los objetos son persistentes (en BDDR) sin
apenas programación (mucho ahorro de
código tedioso)
JPA: conceptos básicos
Conceptos básicos
Unidad de persistencia
Administrador de entidades
Controla el ciclo de vida de la entidades: salvar, borrar,
recuperar, buscar (CRUD)
Contexto de persistencia
Conjunto de clases de entidad administradas por el ORM
Descriptor persistence.xml
Estado de la entidad con respecto al administrador de
entidades
Identidad persistente
Vínculo del objeto java con el registro en la tabla
Dentro de un contexto de persistencia un objeto java es
único
No confundir con la identidad java
JPA: conceptos básicos
Clases Entidad
Representan conceptos del modelo de
dominio
Relacionadas con otros son el modelo del
dominio
Conjunto de clases que representan los conceptos
principales del problema (núcleo de la
funcionalidad del programa)
Otras clases de proceso (p.e: EJBs de sesión)
las manipulan
JPA: conceptos básicos
Clase Java como Entidad
Deben seguir convenio Java Beans:
Setters y getters
Constructor sin parámetros
Recomendable
Serializable
hashCode() y equals() redefinido
Campo Identificador (clave)
Colecciones para asociaciones many
Puede ser Set<T>, List<T>, Map<T> o
Collection<T> (interfaces)
JPA: conceptos básicos
Modelo de dominio en código
JPA: conceptos básicos
De clase a tabla
JPA: conceptos básicos
Metadatos con
@Anotaciones
Metadatos en XML
En fichero orm.xml
En persistence.xml
Fichero referenciados desde
persistence.xml
XML revoca las indicaciones de
@Annotations
mar-10
En deploy pueden se pueden ajustar
rendimientos sin tocar código fuente
alb@uniovi.es
61
Metadatos xml, ejemplo
mar-10
alb@uniovi.es
62
JPA: conceptos básicos
Campos persistentes o
propiedades
Acceso field:
se anotan los atributos
Acceso properties:
se anotan los
getters
JPA: conceptos básicos
Tipos Java persistentes
Tipos primitivos Java
Envoltorios Java, como java.lang.Integer
java.lang.String
byte[] y Byte[]
char[] y Character[]
Los tipos serializables, incluidos, entre otros:
java.util.Date, java.sql.TimeStamp
Cualquier otra clase del programa
JPA: conceptos básicos
Archivo persistence.xml
Define las clases que forman parte de la
persistence-unit (por su presencia)
Especifica el DataSource
JPA: conceptos básicos
Ejemplo de uso EntityManager
Ver en Auction v.1
JPA: conceptos básicos
Estados de un objeto
persistente
mar-10
alb@uniovi.es
JVM
67
JPA: conceptos básicos
APIs JPA
APIs JPA:
interfaces y métodos
alb@uniovi.es
69
JPA: conceptos básicos
Notificación de cambios de
estado
Especificación de métodos callback con
anotaciones
@PrePersist
@PostPersist
@PreRemove
@PostRemove
@PreUpdate
@PostUpdate
@PostLoad
JPA: conceptos básicos
Uso de Entity Manager
JPA: conceptos básicos
JPA: conceptos básicos
Uso de contexto extendido
JPA: conceptos básicos
Ver en Auction v.1
JPA: conceptos básicos
Estructura típica de archivo
ejb-jar
Ver en Auction v.1
Contenidos
JPA: modelado de asociaciones
Categorías de anotaciones
mar-10
alb@uniovi.es
77
JPA: modelado de asociaciones
Anotaciones por categoría
mar-10
alb@uniovi.es
78
JPA: modelado de asociaciones
Anotaciones por categoría
mar-10
alb@uniovi.es
79
JPA: modelado de asociaciones
Asociaciones en Java
Si la relación es bidireccional
siempre hay que establecer la
relación en las dos clases
Se podría añadir métodos para
gestionar de forma cómoda la
relación
mar-10
alb@uniovi.es
80
JPA: modelado de asociaciones
Multiplicidad en JPA
one-to-one
many-to-many
one-to-many
many-to-one
mar-10
son direccionales, esta es la inversa de una
one-to-many
alb@uniovi.es
81
JPA: modelado de asociaciones
Multiplicidad en JPA
one-to-one
many-to-many
one-to-many
many-to-one
mar-10
son direccionales, esta es la inversa de una
one-to-many
alb@uniovi.es
82
<
Unidireccional muchos a uno
Bid siempre debe
tener un Item
mar-10
alb@uniovi.es
83
JPA: modelado de asociaciones
Bidireccional uno a muchos
<
Doble actualización
mar-10
alb@uniovi.es
84
La doble actualización
En java es necesaria pero en SQL la asociación
es una foreign key.
Solo se actualiza el campo en una tabla.
JPA vigila ambos extremos y detecta las dos
modificaciones en Java
Se producirán dos INSERT o dos UPDATE
(según) cuando sólo una es necesaria
Para evitarlo se marca un extremo con
mappedBy=“campo_FK_del_otro_extremo”
mar-10
alb@uniovi.es
85
JPA: modelado de asociaciones
Uno o uno con foreign key
mappedBy en la
clase que no tiene
la FK
mar-10
alb@uniovi.es
86
JPA: modelado de asociaciones
… a Muchos @OrderBy
List mantiene en memoria el
orden traído de BDD
pero en BDD no se
mantiene el orden en el
que se insertaron en List
mar-10
alb@uniovi.es
87
JPA: modelado de asociaciones
Muchos a muchos
unidireccional
>
mar-10
alb@uniovi.es
88
JPA: modelado de asociaciones
Muchos a muchos
bidireccional
mar-10
alb@uniovi.es
89
JPA: modelado de asociaciones
Atributo del modo de
recuperación (fetch)
Forma de recuperar objetos de la BDD y
meterlos en contexto de persistencia
En memoria los objetos forman un grafo
por sus asociaciones
Recorrer el grafo (navegar las
asociaciones) es la forma natural de los
modelos Orientados a Objetos
Pero ¿cuándo y cómo se cargan en
memoria?
mar-10
Alberto M.F.A. alb@uniovi.es
90
JPA: modelado de asociaciones
Estrategia de fetch
¿Cuándo se suben de la BDD..
…los objetos asociados con un objeto
dado?
Dos momentos:
mar-10
LAZY: se cargan en el momento que se
necesiten
EAGER: se cargan al cargar el objeto que
las asocia
Alberto M.F.A. alb@uniovi.es
91
JPA: modelado de asociaciones
Fetch por defecto
Modificación del
comportamiento
por defecto
JPA: modelado de asociaciones
Atributo del modo de cascada
Ver en Auction v.1
Contenidos
Estrategias para mapear
herencia
JPA permite 3
Tabla por cada clase no abstracta
Tabla por cada clase
InheritanceType.TABLE_PER_CLASS
InheritanceType.JOINED
Tabla única para toda la jerarquía
mar-10
InheritanceType.SINGLE_TABLE
alb@uniovi.es
95
InheritanceType.TABLE_PER_CLASS
Table per concrete class
Una tabla por cada clase no abstracta
Las propiedades heredadas se repiten en cada tabla
Problemas
Ventajas
Asociaciones polimórficas (de la superclase) se hacen
poniendo la FK en cada tabla
Consultas polimórficas son menos eficientes, son varias
SELECT o una UNION
Cambios en la superclase se propagan por todas las tablas
Cuando sólo se necesitan consultas contra las clases hijas
Recomendable
mar-10
Cuando no sea necesario el polimorfismo
alb@uniovi.es
96
InheritanceType.TABLE_PER_CLASS
Table per concrete class
Se crea una tabla por cada
clase no abstracta
abstracta
mar-10
alb@uniovi.es
97
InheritanceType.TABLE_PER_CLASS
Table per concrete class
Atención: Opcional en JPA, puede
que no todos los proveedores JPA
la soporten
mar-10
alb@uniovi.es
98
InheritanceType.SINGLE_TABLE
Table per class hierarchy
Todas las clases persisten en una única tabla con la
unión de todas las columnas de todas las clases
Usa un discriminador en cada fila para distinguir el
tipo
Ventajas
Es simple y eficiente
Soporta el polimorfismo
Fácil de implementar
Fácil modificar cualquier clase
Desventaja
mar-10
Todas las columnas no comunes deben ser nullables
Pueden quedar columnas vacías
alb@uniovi.es
99
InheritanceType.SINGLE_TABLE
Table per class hierarchy (2)
Mapeo
En la clase raiz añadir @DiscriminatorColumn
En cada clase hija añadir @DiscriminatorValue
Recomendación
mar-10
Si las clases hijas tienen pocas propiedades (se
diferencian más en comportamiento) y se
necesitan asociaciones polimórficas
Debería ser tomada como estrategia por defecto
alb@uniovi.es
100
InheritanceType.SINGLE_TABLE
Table per class hierarchy (3)
mar-10
alb@uniovi.es
101
InheritanceType.SINGLE_TABLE
Table per class hierarchy (4)
@DiscriminatorColumn,
@DiscriminatorValue
no son necesarios, se toman valores por
defecto si no están presentes
mar-10
alb@uniovi.es
102
InheritanceType.JOINED
Table per subclass
Cada clase de la jerarquía tiene su propia tabla
Las relaciones de herencia se resuelven con FK
Cada tabla solo tiene columnas para las propiedades
no heredadas
Ventaja
Modelo relacional completamente normalizado
Integridad se mantiene
Soporta polimorfismo
Evoluciona bien
Desventaja
mar-10
Si hay que hacer cosas a mano las consultas son mas
complicadas
Para jerarquías muy complejas el rendimiento en consultas
puede ser pobre, muchas joins
alb@uniovi.es
103
InheritanceType.JOINED
Table per subclass (2)
Recomendación
mar-10
Si las clases hijas se diferencian mucho en
sus propiedades y tienen muchas
Si se necesita polimorfismo
Cuando los nullables den problemas
alb@uniovi.es
104
InheritanceType.JOINED
Table per subclass (3)
mar-10
alb@uniovi.es
105
InheritanceType.JOINED
Table per subclass (4)
mar-10
alb@uniovi.es
106
Entities vs Value types
(incorporable(?), embeddable)
Una de las riquezas de los modelos OO
más clases que tablas
Entidades son aquellas clases de las
cuales los objetos son relevantes para
el usuario
mar-10
En JPA siempre llevan identificador y deben
ajustarse a un convenio de nombres
(mínimo)
alb@uniovi.es
107
Entities vs Value types
Tipos valor son aquellas clases cuya identidad no es
conocida por el usuario, ni le importa
Tienen semántica de composición o directamente aparecen
como atributos en los diagramas UML
Las clases JDK (Integer, Long, etc.) son de este tipo
Su ciclo de vida depende totalmente de la entidad a la que
están asignados
En runtime los objetos Valor sólo tienen referencias
entrantes de los objetos que los poseen y no pueden ser
compartidos con otros objetos
La diferencia entre uno y otro es difícil de definir ya
que depende del contexto
mar-10
alb@uniovi.es
108
Referencias
A entidades
Se salvan como claves ajenas
A value types
mar-10
Se salvan en la misma tabla que la entidad
que los posee
Excepto si son colecciones (p.e. un usuario
tiene varias direcciones) otra tabla
Se usa la etiqueta @Embedded
alb@uniovi.es
109
Ejemplo
mar-10
alb@uniovi.es
110
Mapeos
Si hay más de un VT del mismo tipo en una
entidad hay que forzar los nombres de las
columnas ya que si no se repiten en el DDL
mar-10
alb@uniovi.es
111
@Embeddable
Marca una clase como sólo ValueType
Se pueden configurar las propiedades
(o atributos) con etiquetas:
mar-10
@Basic, @Column, @Lob, @Temporal,
@Enumerated
alb@uniovi.es
112
POJO Ejemplo (Value Object)
No lleva @Id
Tipo de acceso (field,
property) igual al de la
clase que lo incluye
mar-10
alb@uniovi.es
113
JPA: modelado de herencia y composición
Uso de claves compuestas
Ver en Auction v.1
Contenidos
JPA: lenguaje de consultas
Paginación
El primer resultado es el 0
Las Query permiten
encadenamiento de
métodos
mar-10
Número máximo de filas a
recuperar desde la fijada por
setFirstResult()
Ejecuta la consulta y
devuelve una List()
de objetos User
Alberto MFA alb@uniovi.es
116
JPA: lenguaje de consultas
Enlace de parámetros
Lo que no se debe hacer
¿Qué hay en este
string?
¿Qué pasa si
escriben esto en
un formulario?
Es el problema de la SQL injection
mar-10
Alberto MFA alb@uniovi.es
117
JPA: lenguaje de consultas
Enlace de parámetros
Enlace nominal (recomendado)
setParameter() sobrecargado para
java.util.Date, java.util.Calendar y
Object (ver documentación)
mar-10
Alberto MFA alb@uniovi.es
118
JPA: lenguaje de consultas
Enlace de parámetros
Enlace posicional
El orden de parámetros
no tiene por qué ser
secuencial
¡Ojo! Se empieza en 1
setters
sobrecargados
mar-10
Alberto MFA alb@uniovi.es
119
Ejecución
Se produce al invocar a:
getResultList()
getSingleResult()
Excepción si más
de uno o ninguno
Así ya no… pero puede
no haber ninguno
mar-10
Alberto MFA alb@uniovi.es
120
JPA: lenguaje de consultas
Consultas con nombre
Se carga el string de la consulta desde
mapeos
createNamedQuery(…)
Query con anotaciones o en orm.xml
mar-10
Alberto MFA alb@uniovi.es
121
Ver en Auction v.1
mar-10
Alberto MFA alb@uniovi.es
122
JPA: lenguaje de consultas
Partes de una consulta
Selección
Restricción
Fuente de datos FROM
Una sola o combinación de ellas
Filtrado de filas WHERE
Proyección
mar-10
Selección de partes de las filas que pasan
el filtro SELECT
Alberto MFA alb@uniovi.es
123
JPA: lenguaje de consultas
Partes de una consulta
FROM
WHERE
Resultados
Tabla
Criterios de
selección de filas
Curso 2005-2006
SELECT
SID2-GAP
Puede que haya
menos filas
(WHERE) y puede
que menos campos
(SELECT)
124
JPA: lenguaje de consultas
Selección (FROM)
SELECT en JPA QL, no necesario en HQL
Alias necesarios para condiciones sobre
miembros
select i from Item i
select i from Item as i
select i from Item i
Las consultas son polimórficas
mar-10
¡Sube toda la BDD!
select b from BillingDetail b
select o from java.lang.Object o
select s from java.io.Serializable s
Alberto MFA alb@uniovi.es
También
polimorfismo sobre
125
interfaces
JPA: lenguaje de consultas
Restricción (WHERE)
WHERE para filtrar filas
mar-10
Alberto MFA alb@uniovi.es
126
JPA: lenguaje de consultas
Restricción (WHERE)
mar-10
Alberto MFA alb@uniovi.es
127
JPA: lenguaje de consultas
Operadores de comparación y
precedencia
_
+
mar-10
Alberto MFA alb@uniovi.es
128
JPA: lenguaje de consultas
Restricciones sobre
colecciones (WHERE)
En el WHERE
Se pueden complementar con funciones
mar-10
Alberto MFA alb@uniovi.es
129
JPA
Funciones
Hibernate
mar-10
Alberto MFA alb@uniovi.es
130
JPA: lenguaje de consultas
Ordenación
De la forma usual
mar-10
Alberto MFA alb@uniovi.es
131
Proyección
(Esta consulta es inútil ya
que da un producto
cartesiano)
Cada fila es un vector de los
elementos proyectados (Item y Bid)
mar-10
Alberto MFA alb@uniovi.es
132
JPA: lenguaje de consultas
Proyección de escalares
En la select pueden ir
atributos de clases…
… y resultados de funciones
(las ya vistas)
mar-10
Alberto MFA alb@uniovi.es
133
JPA: lenguaje de consultas
Consulta sobre varias tablas
+
Tabla
Criterios de filtrado
de filas
Resultados
Combinación de registros de las
dos tablas
Tabla
Curso 2005-2006
SID2-GAP
134
Joins: inner, left y right outer
Todos los Items
con sus Bids
Los Items que
tienen mar-10
Bids
Alberto MFA alb@uniovi.es
135
Joins implícitos en
asociaciones
Cuando se accede a propiedades a lo
largo de un camino (path)
Bid join Item
Item join User
Acceso a propiedad
También se puede usar en select
mar-10
Alberto MFA alb@uniovi.es
136
JPA: lenguaje de consultas
Joins implícitos
Solo se permiten en caminos (path) que
pasen a través de asociaciones manyto-one o one-to-one
El final del camino NO puede ser
multivaluado
mar-10
P.e. item.bids.amount es ilegal
Alberto MFA alb@uniovi.es
137
JPA: lenguaje de consultas
Joins implícitos en SQL
mar-10
Alberto MFA alb@uniovi.es
138
Joins en FROM
Cuando el camino de asociaciones
resulta en un conjunto
many-to-many
one-to-many
mar-10
Alberto MFA alb@uniovi.es
139
JPA: lenguaje de consultas
Joins en FROM
También left y right join
Los Item %name% y sus
Bids aunque haya Item
que no tienen Bids
mar-10
Alberto MFA alb@uniovi.es
140
JPA: lenguaje de consultas
Join explícito en SQL
mar-10
Alberto MFA alb@uniovi.es
141
Theta-style en WHERE
El ajuste del join se hace en el WHERE
Es práctico para consultas sobre clases
no asociadas
Da pares
mar-10
Alberto MFA alb@uniovi.es
142
JPA: lenguaje de consultas
Consultas de agregados
mar-10
Alberto MFA alb@uniovi.es
143
JPA: lenguaje de consultas
Funciones en SELECT
count() min() max() sum() avg()
mar-10
Alberto MFA alb@uniovi.es
144
JPA: lenguaje de consultas
Consulta de totales
GROUP BY
Formación de
grupos
+
Tabla
Criterios de
selección de filas
Funciones de
agregados
Cálculos sobre
los grupos
Tabla
Selección de
grupos
Resultados
HAVING
Curso 2005-2006
SID2-GAP
145
JPA: lenguaje de consultas
Agrupamiento
Cláusula GROUP BY (como en SQL)
Como en SQL cualquier
propiedad o alias que
aparezca en SELECT
fuera de una función de
agregado debe aparecer
también en la cláusula
GROUP BY
mar-10
Alberto MFA alb@uniovi.es
146
JPA: lenguaje de consultas
Restricción de grupos con
HAVING
Mismas reglas que en SQL
Solo puede aparecer en
HAVING una función de
agregado o una propiedad (o
alias) usado en GROUP BY
mar-10
Alberto MFA alb@uniovi.es
147
JPA: lenguaje de consultas
Instanciación dinámica en
SELECT
Las consultas que no
devuelven entidades
pueden tener rendimiento
al no meter resultados en
contexto de persistencia
mar-10
Cada fila devuelve un
objeto de la clase que se
especifica
La clase debe existir y no
necesita estar mapeada
Alberto MFA alb@uniovi.es
148
JPA: lenguaje de consultas
Subselects
En SQL una subselect puede ir en
SELECT, FROM o WHERE
En JPA QL sólo puede ir en el WHERE
Las debe soportar la BDD
mar-10
MySQL en versiones anteriores a 4.?? no
tiene subselects
Alberto MFA alb@uniovi.es
149
JPA: lenguaje de consultas
Subselects
Correlada: puede tener peor
rendimiento
No correlada: no tiene
impacto de rendimiento
Siempre entre
paréntesis
mar-10
Alberto MFA alb@uniovi.es
150
Contenidos
Desarrollo de aplicaciones que usan mensajes
Middleware orientado a
mensajes (MOM)
Permite conexiones desacopladas entre
sistemas
Facilita la integración entre sistemas de
tecnologías dispares
Añaden una capa intermedia
La interacción entre sistemas se basa
en intercambio de mensajes (o eventos)
Desarrollo de aplicaciones que usan mensajes
MOM como integrador
Distribución
de mensajes
Clientes de
mensajería
Desarrollo de aplicaciones que usan mensajes
Tipos de clientes de
mensajería
Se bloquea esperando
la llegada de un mensaje
Desarrollo de aplicaciones que usan mensajes
Arquitectura de mensajería
punto a punto
Cuando el consumidor recoge el mensaje se
borra de la cola
Puede haber múltiples consumidores, pero “el
primero que llega se lo lleva”
También pude haber múltiples productores
enviando a la misma cola
Desarrollo de aplicaciones que usan mensajes
Arquitectura de mensajería de
publicación/suscripción
El tema es
como una lista
de distribución
El mensaje se
conserva hasta
que todos los
suscritos lo
consumen
Desarrollo de aplicaciones que usan mensajes
Elementos del API JMS
Desarrollo de aplicaciones que usan mensajes
Estructura de los mensajes
Desarrollo de aplicaciones que usan mensajes
Diagrama de colaboración
Ejemplo
Desarrollo de aplicaciones que usan mensajes
Desarrollo de aplicaciones que usan mensajes
Diagrama de colaboración
Ejemplo
Desarrollo de aplicaciones que usan mensajes
Desarrollo de aplicaciones que usan mensajes
Método gestor del evento
Desarrollo de aplicaciones que usan mensajes
Ver en MessageDrivenBean
EJB como clientes de
mensajería
Contenidos
Desarrollo de beans controlados por mensajes
MessageDriven Beans
Son clientes asíncronos de mensajes
Implementan el interfaz
MessageListener
Desconectados de cliente
Desarrollo de beans controlados por mensajes
Ciclo de vida
Posible interceptar
los cambios de estado
@PostConstruct
@PreDestroy
Desarrollo de beans controlados por mensajes
Código ejemplo
Desarrollo de beans controlados por mensajes
Filtra los mensajes
que llegan
Ver en MessageDrivenBean
Contenidos
Implementación de clases y métodos interceptor
Interceptores y clases
interceptor
Código que se añade para ejecutar
funcionalidad extra (transversal) a la
funcionalidad original de un bean o
entidad (callbacks)
Interceptores de métodos de negocio
De un bean de sesión o de mensajes
@AroundInvoke
Interceptores de ciclo de vida
Notificación del cambio de estado de un bean
de sesión o clase entidad persistente
Implementación de clases y métodos interceptor
Métodos interceptores para
beans (sesión y mensaje)
private
public
protected
Signatura para un interceptor de
método de negocio
Signatura para un interceptor de ciclo
@PostConstruct
de vida
@PreDestroy
@PostActivate
…
Implementación de clases y métodos interceptor
API de InvocationContext
Ver en Auction v.3
Implementación de clases y métodos interceptor
Conceptos
Los métodos interceptores pueden estar
en la misma clase a interceptar o en
otra aparte
Un interceptor se puede aplicar a un
sólo método o a todos los de una clase
Se pueden aplicar varios interceptores a
un mismo bean (o método), la llamada
pasa a través de todos ellos
Actúan como filtros
Implementación de clases y métodos interceptor
Ejemplo de método
interceptor (en misma clase)
Implementación de clases y métodos interceptor
Ejemplo de clase interceptora
Interceptada
Interceptora
Implementación de clases y métodos interceptor
Varios métodos interceptores
Clases interceptoras
Método interceptor en la misma clase
Implementación de clases y métodos interceptor
Interceptores de ciclo de vida
Un mismo método puede
atender varios eventos
Implementación de clases y métodos interceptor
Interceptores de ciclo de vida
para entidades
Los métodos interceptores pueden estar
en la misma clase entidad o en otras
clases
Eventos:
Ver en Auction v.2
@PrePersist
@PostPersist
@PreRemove
@PostRemove
@PreUpdate
@PostUpdate
@PostLoad
Implementación de clases y métodos interceptor
Ejemplo de métodos
interceptores
Implementación de clases y métodos interceptor
Ejemplo de clase interceptora
para entidades
Contenidos
Implementación de transacciones
Determinación del
comportamiento transaccional
Cada método de bean de sesion o
mensaje actúa (o puede actuar) bajo la
demarcación de una transacción
El contenedor gestiona y coordina todos
los recursos involucrados en la
transacción
Transacciones locales o distribuidas
Uno o varios recursos transaccionales
Implementación de transacciones
Escenarios de comportamiento
transaccional
Implementación de transacciones
Para cada método de bean…
Implementación de transacciones
Gestión de Trx por el
contenedor (CMT)
Por defecto las transacciones
las gestiona el contenedor
Para cada método se puede especificar
su papel frente a una transacción (atributo)
Requiered
por defecto
Implementación de transacciones
Compatibilidad de atributos de
Trx y tipos de bean
Implementación de transacciones
Ejemplo de control de trx CMT
Implementación de transacciones
Control del estado de rollback
de una trx CMT por el bean
Demarcación
de la trx
Implementación de transacciones
Beans de sesión con estado y
comportamiento transaccional
Hasta ahora…
Si el bean es con estado…
el bean maneja el estado de recursos
transaccionales, p.e. BDD; pero …
Él mismo puede ser transaccional
Los cambios en sus atributos de estado son
también transacionales
Debe implementar el interfaz
SessionSynchronization para ser coordinado
en la transacción
Implementación de transacciones
Implementación de transacciones
Gestión de transacción por el
bean (BMT)(por programa)
El bean gestiona por programa el
estado de la transacción
Se debe usar la interfaz
UserTransaction (API JTA)
Implementación de transacciones
Control de trx BMT
Implementación de transacciones
Ejemplo BMT
control de trx
Implementación de transacciones
Transacciones en beans de
mensajes
Entre el emisor y el receptor está el
sistema de gestión de mensajes
El MOM actúa de intermediario y rompe
la cadena emisión/recepción en dos
transacciones
1ª trx. El emisor envía a la cola.
Commit confirma la recepción del mensaje por
la cola
2ª trx. El receptor consume el mensaje
Commit elimina el mensaje de la cola
Implementación de transacciones
Opciones de control de trx en
beans de mensajes
Implementación de transacciones
Mensaje envenenado
Contenidos
Manejo de excepciones
Fuentes de excepciones
Manejo de excepciones
Tipos de excepciones Java
Chequeadas, heredan de Exception
NO chequeadas, heredan de
RuntimeException
Indican errores lógicos en la aplicación
Indican errores de programación o no
recuperables
En JEE de suele hablar de:
Excepciones de aplicación
Excepciones de sistema
Manejo de excepciones
Excepciones de aplicación y
sistema
Manejo de excepciones
Ruta de retorno de
excepciones
Manejo de excepciones
Análisis del manejo de
excepciones por el contenedor
Tipo de excepción
Contexto transacción
Iniciado por el emisor
Iniciado por el contenedor
Sin transacción
Administrado por el bean
Tipo de bean
Aplicación o sistema
Sesión o mensaje
Tipo de método
De negocio y métodos interceptores
De callback desde el contenedor
Manejo de excepciones
Excepciones de aplicación:
gestión por el contenedor
Generadas por un método de negocio
El contendor:
Pasa la excepción al cliente (local o
remoto)
NO ANULA la excepción automáticamente
Se puede anular con setRollbackOnly
Manejo de excepciones
Excepciones de sistema:
gestión por el contenedor
Manejo de excepciones
Manejo de
excepciones
en métodos
de
enterprise
bean
Manejo de excepciones
Manejo de excepciones de
aplicación en el cliente del bean
Manejo de excepciones
Manejo de excepciones del
sistema en el código del cliente
Manejo de excepciones
Manejo de excepciones del
sistema en el código del cliente
Manejo de excepciones
Manejo de excepciones del
sistema en el código del cliente
Manejo de excepciones
Excepciones de anulación de
transacción
Manejo de excepciones
Excepción de transacción
requerida
Contenidos
Uso de servicios de temporizador
Servicios de temporizador
Se crean objetos timer
Los timers, a la expiración, llaman a
métodos callback designados
Los métodos callback pueden ser de:
Beans de sesión sin estado
Beans de mensajes
Tipos de timer:
De único evento
De tiempo absoluto (fecha y hora)
De duración (lapso de tiempo)
Tipos de
temporizadores
Uso de servicios de temporizador
Creación de un objeto Timer
Uso de servicios de temporizador
Ejemplos de creación
Uso de servicios de temporizador
Método de procesamiento de
eventos de Timer
El timer llama al método indicado del
bean que lo creó
Dos formas de indicar a qué método se
debe invocar:
Usando la anotación @Timeout
Implementando la interfaz TimedObject
Ejemplo: implementando
TimedObject
Uso de servicios de temporizador
Ejemplo: @Timeout
Ver en Auction v.4
Uso de servicios de temporizador
Directrices para el uso de
temporizadores
Si un bean crea varios temporizadores debe
usar atributo info para distinguir quien llama
al método de timeout (todos llaman al
mismo)
Si se cae el servidor, los temporizadores
creados sobreviven a la caída
Los eventos perdidos se disparan todos al arrancar
de nuevo
El método Timeout puede ser transaccional
El contexto de seguridad en el que se ejecuta
el método Timeout debe ser especificado en
configuración
Uso de servicios de temporizador
Administración de objetos de
temporizador
cancel
Contenidos
Implementación de la seguridad
Arquitectura
de seguridad
Implementación de la seguridad
Autenticación y autorización
Autenticación: asegura que el usuario
es quien dice ser
La hace la infraestructura PKI de la
empresa
Autorización: verifica qué operaciones
puede realizar el usuario
La hace el contenedor JEE
Deber ser configurado adecuadamente
Implementación de la seguridad
Identidades de usuario en JEE
Principal
Usuario autenticado en el dominio de
seguridad JEE
Rol
Grupo de Principales que comparten un
conjunto común de permisos
Implementación de la seguridad
Asignación de identidades a
La asignación depende
principales JEE
del contenedor
concreto, se hace
en el momento de
la puesta en
marcha de la
aplicación
Implementación de la seguridad
Autenticación del emisor de la
llamada
Depende de la
infraestructura
Por el contenedor
Implementación de la seguridad
Estrategias de autorización
Implementación de la seguridad
Autorización declarativa
Por medio de:
anotaciones
descriptores de despliegue
Hay que especificar:
Declaración del rol de seguridad
Asignación de permisos de métodos
Asignación de identidades de seguridad
Implementación de la seguridad
Declaración de roles de
seguridad
Ver en Auction v.5
Implementación de la seguridad
Declaración de permisos de
métodos
Implementación de la seguridad
Ejemplo: Declaración de
permisos con descriptor
Implementación de la seguridad
Declaración de la identidad de
seguridad
La identidad con la que un bean llama a
otro bean es la identidad del que le
llama a él (por defecto)
use-caller-identity
Es posible cambiarla: que un bean
llame a otro con una identidad
configurada
Run-as
Implementación de la seguridad
Identidad run-as
Implementación de la seguridad
Autorización programática
Por programa se puede averiguar el
Principal del usuario y el rol con el que
actúa
isCallerInRole
getCallerPrincipal
Implementación de la seguridad
Método isCallerInRole
Implementación de la seguridad
Mapeao de roles de bean a
roles de aplicación
Implementación de la seguridad
Método getCallerPrincipal
Implementación de la seguridad
Ejemplo completo
Implementación de la seguridad
Responsabilidades del
implementador
Contenidos
Uso de las mejores prácticas de la tecnología EJB
Patrones para EJB
Uso de las mejores prácticas de la tecnología EJB
Elección de la tecnología EJB
Uso de las mejores prácticas de la tecnología EJB
Factores que indicarían que
EJB no es la tecnología
Ya hay muchas inversiones en otras
tecnologías
Las limitaciones de EJB son impeditivas:
Poca lógica de negocio, mucha
presentación y consultas
Theading, código nativo, variables estáticas
Servlets, JSP, Struts, es mejor
La aplicación es sencilla y no tiene
previsión de crecer
Uso de las mejores prácticas de la tecnología EJB
Algunos patrones conocidos
aplicados a EJB
Sesion bean Fachada
Secuenciador Generador de claves
Uso de las mejores prácticas de la tecnología EJB
Patrones conocidos en EJB
Data Transfer Object
Interfaz de mensajes
Uso de las mejores prácticas de la tecnología EJB
Minimización del uso de
llamadas a métodos remotos
Siempre que se pueda usar la interfaz local
Distribuir lo menos posible cuantos más
EJB en la misma JVM mejor
Métodos de sesión bean remotos de alto nivel
Solo los bean interactúan con Entidades
Beans remotos pueden usar beans locales
Usar DTO para transferencias remotas de
datos