sesion 5. desarrollo de componentes de negocio...
TRANSCRIPT
Desarrollo de Componentes deNegocio con TecnologíaEnterprise JavaBeans™ (EJB)
Contenidos
Elementos de JEE� Un conjunto de especificaciones
� Principales � Java EE 5 � JSR 220 (web services)
� Secundarias:� Tecnologías de servicios web� Tecnologías de aplicaciones web� Tecnologías de aplicaciones de empresa� Tecnologías de 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
� API:� Asignación de nombres� Mensajería� Conectores
� Inherentes:� Ciclo de vida� Subprocesos (threading)� Comunicación con
objetos remotos, como RMI y CORBA
� Del fabricante:� Capacidad de ampliación� Fail over� Balanceo de cargaConfigurados en XML
o con annotations Usados desde código
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
Introducción a Java Platform Enterprise Edition
Contenidos
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
Introducción a la aplicación de subasta
Ejecutar Auction v.1
Contenidos
Comparación de beans de sesióncon 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)� Trasiego de datos
� Capa Web� En HttpSession
� Capa de negocio (EJB)� 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 sinsin 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
Implementación de los beans de sesión EJB3.0
Características de los beans de sesión concon 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 beansde sesión sin datos de estado.
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 serremota 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.
Implementación de los beans de sesión EJB3.0
Vistas de cliente locales y distribuidas
mar-10 [email protected] 35
Conexión local
Interfaz local
EJB Container
Vistas de cliente locales y distribuidasmar-10 [email protected] 36
Conexión remotaInterfaz remota
EJB Container
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
Ver en Auction v.1
Todas las anotaciones
� Tipo de bean� @Stateless, @Statefull
� Tipo de acceso� @Remote, @Local
� Cierre de sesión (en Statefull)� @Remove
� Acceso a recursos desde el EJB� @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 beanssin estado
Implementación de los beans de sesión EJB3.0
Ciclo de vida de session beanscon 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
� Archivo JAR nomal� Descriptor ejb-jar.xml en /META-INF
� Aplicaciones: <nombre>.ear� Contiene WAR + JAR� Descriptor application.xmlen /META-INF
Implementación de los beans de sesión EJB3.0
Ver en Auction v.1
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 JNDIEn ejb-jar.xmlo 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
Implementación de los beans de sesión EJB3.0
Ver en Auction v.1
Contenidos
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 mapeadorobjeto/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
� Conjunto de clases de entidad administradas por el ORM� Descriptor persistence.xml
� Administrador de entidades� Controla el ciclo de vida de la entidades: salvar, borrar,
recuperar, buscar (CRUD)� Contexto de persistencia
� 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
JPA: conceptos básicos
Metadatos en XML
� En fichero orm.xml� En persistence.xml
� Fichero referenciados desde persistence.xml
� XML revoca las indicaciones de @Annotations� En deploy pueden se pueden ajustar rendimientos sin tocar código fuente
mar-10 [email protected] 61
mar-10 [email protected] 62
Metadatos xml, ejemplo
Campos persistentes o propiedades
Acceso properties:se anotan los getters
Acceso field:se anotan los atributos
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 EntityManagerJPA: conceptos básicos
Ver en Auction v.1
APIs JPA
JPA: conceptos básicos
APIs JPA: interfaces y métodos
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 ManagerJPA: conceptos básicos
JPA: conceptos básicos
Uso de contexto extendidoJPA: conceptos básicos
JPA: conceptos básicos
Ver en Auction v.1
Estructura típica de archivo ejb-jar
JPA: conceptos básicos
Ver en Auction v.1
Contenidos
mar-10 [email protected] 80
Asociaciones en Java
Se podría añadir métodos para gestionar de forma cómoda la relación
Si la relación es bidireccional siempresiempre hay que establecer la relación en las dos clases
JPA: modelado de asociaciones
mar-10 [email protected] 81
Multiplicidad en JPA
� one-to-one� many-to-many� one-to-many� many-to-one
� son direccionales, esta es la inversa de una one-to-many
JPA: modelado de asociaciones
mar-10 [email protected] 82
Multiplicidad en JPA
� one-to-one� many-to-many� one-to-many� many-to-one
� son direccionales, esta es la inversa de una one-to-many
JPA: modelado de asociaciones
mar-10 [email protected] 84
Bidireccional uno a muchos
Doble actualización
JPA: modelado de asociaciones
<
mar-10 [email protected] 85
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 conmappedBy=“campo_FK_del_otro_extremo”
mar-10 [email protected] 86
Uno o uno con foreign key
mappedBy en la clase que no tiene la FK
JPA: modelado de asociaciones
… a Muchos @OrderBy
mar-10 [email protected] 87
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
JPA: modelado de asociaciones
mar-10 Alberto M.F.A. [email protected] 90
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?
JPA: modelado de asociaciones
Estrategia de fetch
� ¿Cuándo se suben de la BDD..� …los objetos asociados con un objeto dado?
� Dos momentos:� LAZY: se cargan en el momento que se necesiten
� EAGER: se cargan al cargar el objeto que las asocia
mar-10 Alberto M.F.A. [email protected] 91
JPA: modelado de asociaciones
Fetch por defecto
JPA: modelado de asociaciones
Modificación del comportamiento por defecto
Atributo del modo de cascadaJPA: modelado de asociaciones
Ver en Auction v.1
Contenidos
mar-10 [email protected] 95
Estrategias para mapear herencia
� JPA permite 3 � Tabla por cada clase no abstracta
� InheritanceType.TABLE_PER_CLASS
� Tabla por cada clase� InheritanceType.JOINED
� Tabla única para toda la jerarquía� InheritanceType.SINGLE_TABLE
mar-10 [email protected] 96
Table per concrete class� Una tabla por cada clase no abstracta� Las propiedades heredadas se repiten en cada tabla� Problemas
� 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� Ventajas
� Cuando sólo se necesitan consultas contra las clases hijas� Recomendable
� Cuando no sea necesario el polimorfismo
InheritanceType.TABLE_PER_CLASS
mar-10 [email protected] 97
Table per concrete classSe crea una tabla por cada clase no abstracta
abstracta
InheritanceType.TABLE_PER_CLASS
Table per concrete class
mar-10 [email protected] 98
Atención: Opcional en JPA, puede que no todos los proveedores JPA la soporten
InheritanceType.TABLE_PER_CLASS
mar-10 [email protected] 99
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� Todas las columnas no comunes deben ser nullables� Pueden quedar columnas vacías
InheritanceType.SINGLE_TABLE
mar-10 [email protected] 100
Table per class hierarchy (2)� Mapeo
� En la clase raiz añadir @DiscriminatorColumn� En cada clase hija añadir @DiscriminatorValue
� Recomendación� 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
InheritanceType.SINGLE_TABLE
mar-10 [email protected] 102
Table per class hierarchy (4)
@DiscriminatorColumn, @DiscriminatorValueno son necesarios, se toman valores por defecto si no están presentes
InheritanceType.SINGLE_TABLE
mar-10 [email protected] 103
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� 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
InheritanceType.JOINED
mar-10 [email protected] 104
Table per subclass (2)
� Recomendación� Si las clases hijas se diferencian mucho en sus propiedades y tienen muchas
� Si se necesita polimorfismo� Cuando los nullables den problemas
InheritanceType.JOINED
mar-10 [email protected] 107
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� En JPA siempre llevan identificador y deben ajustarse a un convenio de nombres (mínimo)
mar-10 [email protected] 108
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 [email protected] 109
Referencias
� A entidades� Se salvan como claves ajenas
� A value types� 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
mar-10 [email protected] 110
Ejemplo
Mapeos
mar-10 [email protected] 111
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
� Marca una clase como sólo ValueType� Se pueden configurar las propiedades (o atributos) con etiquetas:� @Basic, @Column, @Lob, @Temporal, @Enumerated
mar-10 [email protected] 112
@Embeddable
POJO Ejemplo (Value Object)
mar-10 [email protected] 113
Tipo de acceso (field, property) igual al de la clase que lo incluye
No lleva No lleva @Id@Id
Uso de claves compuestas
JPA: modelado de herencia y composición
Ver en Auction v.1
Contenidos
mar-10 Alberto MFA [email protected] 116
Paginación
El primer resultado es el 0Número máximo de filas a recuperar desde la fijada por setFirstResult()
Ejecuta la consulta y devuelve una List()de objetos User
Las Query permiten encadenamiento de métodos
JPA: lenguaje de consultas
mar-10 Alberto MFA [email protected] 117
Enlace de parámetros
¿Qué pasa si escriben esto en un formulario?
Es el problema de la SQL injection
¿Qué hay en este string?
� Lo que no se debe hacer
JPA: lenguaje de consultas
mar-10 Alberto MFA [email protected] 118
Enlace de parámetros
� Enlace nominal (recomendado)
setParameter() sobrecargado para java.util.Date, java.util.Calendar y Object (ver documentación)
JPA: lenguaje de consultas
mar-10 Alberto MFA [email protected] 119
Enlace de parámetros
� Enlace posicional
setters sobrecargados
¡Ojo! Se empieza en 1
El orden de parámetros no tiene por qué ser secuencial
JPA: lenguaje de consultas
mar-10 Alberto MFA [email protected] 120
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 [email protected] 121
Consultas con nombre
� Se carga el string de la consulta desde mapeos
� createNamedQuery(…)
� Query con anotaciones o en orm.xml
JPA: lenguaje de consultas
mar-10 Alberto MFA [email protected] 122
Ver en Auction v.1
Partes de una consulta
� Selección� Fuente de datos � FROM� Una sola o combinación de ellas
� Restricción� Filtrado de filas � WHERE
� Proyección� Selección de partes de las filas que pasan el filtro � SELECT
mar-10 Alberto MFA [email protected] 123
JPA: lenguaje de consultas
Curso 2005-2006 SID2-GAP 124
Partes de una consulta
Criterios de selección de filas
TablaResultados
Puede que haya menos filas (WHERE) y puede que menos campos (SELECT)
FROM WHERE SELECT
JPA: lenguaje de consultas
mar-10 Alberto MFA [email protected] 125
Selección (FROM)� SELECT en JPA QL, no necesario en HQL
� select i from Item i
� Alias necesarios para condiciones sobre miembros� select i from Item as i� select i from Item i
� Las consultas son polimórficas� select b from BillingDetail b� select o from java.lang.Object o� select s from java.io.Serializable s
¡Sube toda la BDD!
También polimorfismo sobre interfaces
JPA: lenguaje de consultas
mar-10 Alberto MFA [email protected] 126
Restricción (WHERE)
� WHERE para filtrar filas
JPA: lenguaje de consultas
mar-10 Alberto MFA [email protected] 128
Operadores de comparación y precedencia
+
_
JPA: lenguaje de consultas
mar-10 Alberto MFA [email protected] 129
Restricciones sobre colecciones (WHERE)
� En el WHERE� Se pueden complementar con funciones
JPA: lenguaje de consultas
mar-10 Alberto MFA [email protected] 132
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 [email protected] 133
Proyección de escalares
En la select pueden ir atributos de clases…
… y resultados de funciones (las ya vistas)
JPA: lenguaje de consultas
Curso 2005-2006 SID2-GAP 134
Consulta sobre varias tablas
Tabla
Resultados
Tabla
+
Combinación de registros de las dos tablas
Criterios de filtrado de filas
JPA: lenguaje de consultas
mar-10 Alberto MFA [email protected] 135
Joins: inner, left y right outer
Todos los Itemscon sus Bids
Los Items que tienen Bids
mar-10 Alberto MFA [email protected] 136
Joins implícitos en asociaciones
� Cuando se accede a propiedades a lo largo de un camino (path)
Bid join ItemItem join User Acceso a propiedad
También se puede usar en select
mar-10 Alberto MFA [email protected] 137
Joins implícitos
� Solo se permiten en caminos (path) que pasen a través de asociaciones many-to-one o one-to-one
� El final del camino NO puede ser multivaluado� P.e. item.bids.amount es ilegal
JPA: lenguaje de consultas
mar-10 Alberto MFA [email protected] 139
Joins en FROM
� Cuando el camino de asociaciones resulta en un conjunto
one-to-many
many-to-many
mar-10 Alberto MFA [email protected] 140
Joins en FROM
� También left y right join
Los Item %name% y sus Bids aunque haya Itemque no tienen Bids
JPA: lenguaje de consultas
� El ajuste del join se hace en el WHERE� Es práctico para consultas sobre clases no asociadas
mar-10 Alberto MFA [email protected] 142
Theta-style en WHERE
Da pares
mar-10 Alberto MFA [email protected] 144
Funciones en SELECT
count() min() max() sum() avg()
JPA: lenguaje de consultas
Curso 2005-2006 SID2-GAP 145
Consulta de totales
Formación de grupos
Tabla
Resultados
+
Tabla
Cálculos sobre los grupos
Selección de grupos
Criterios de selección de filas
GROUP BY
HAVING
Funciones de agregados
JPA: lenguaje de consultas
mar-10 Alberto MFA [email protected] 146
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
Agrupamiento
� Cláusula GROUP BY (como en SQL)
JPA: lenguaje de consultas
mar-10 Alberto MFA [email protected] 147
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
JPA: lenguaje de consultas
mar-10 Alberto MFA [email protected] 148
Instanciación dinámica en SELECT
� Cada fila devuelve un objeto de la clase que se especifica
� La clase debe existir y no necesita estar mapeada
Las consultas que no devuelven entidades pueden tener rendimiento al no meter resultados en contexto de persistencia
JPA: lenguaje de consultas
mar-10 Alberto MFA [email protected] 149
Subselects
� En SQL una subselect puede ir en SELECT, FROM o WHERE
�� En JPA QL En JPA QL ssóólolo puede ir en el WHEREpuede ir en el WHERE� Las debe soportar la BDD
� MySQL en versiones anteriores a 4.?? no tiene subselects
JPA: lenguaje de consultas
mar-10 Alberto MFA [email protected] 150
Subselects
Correlada: puede tener peor rendimiento
Siempre entre paréntesis
No correlada: no tiene impacto de rendimiento
JPA: lenguaje de consultas
Contenidos
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
Clientes de mensajería
Distribución de mensajes
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
Desarrollo de aplicaciones que usan mensajes
Ejem
plo
Desarrollo de aplicaciones que usan mensajes
Diagrama de colaboración
Desarrollo de aplicaciones que usan mensajes
Ejem
plo
Desarrollo de aplicaciones que usan mensajes
Método gestor del evento
Desarrollo de aplicaciones que usan mensajes
Desarrollo de aplicaciones que usan mensajes
Ver en MessageDrivenBean
EJB como clientes de mensajería
Contenidos
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
Desarrollo de beans controlados por mensajes
Ver en MessageDrivenBean
Contenidos
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 beande sesión o clase entidad persistente
Implementación de clases y métodos interceptor
Métodos interceptores para beans (sesión y mensaje)
� Signatura para un interceptor de método de negocio
� Signatura para un interceptor de ciclo de vida
Implementación de clases y métodos interceptor
privatepublicprotected
@PostConstruct@PreDestroy@PostActivate…
API de InvocationContext
Implementación de clases y métodos interceptor
Ver en Auction v.3
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 interceptoraImplementación de clases y métodos interceptor
Interceptada
Interceptora
Varios métodos interceptores
Implementación de clases y métodos interceptor
Método interceptor en la misma clase
Clases interceptoras
Interceptores de ciclo de vida
Implementación de clases y métodos interceptor
Un mismo método puede atender varios eventos
Interceptores de ciclo de vida para entidades
� Los métodos interceptores pueden estar en la misma clase entidad o en otras clases
� Eventos:
Implementación de clases y métodos interceptor
@PrePersist@PostPersist@PreRemove@PostRemove@PreUpdate@PostUpdate@PostLoad
Ver en Auction v.2
Ejemplo de métodos interceptores
Implementación de clases y métodos interceptor
Ejemplo de clase interceptora para entidades
Implementación de clases y métodos interceptor
Contenidos
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)
Implementación de transacciones
Por defecto las transacciones las gestiona el contenedor
Para cada método se puede especificar su papel frente a una transacción (atributo)
Requieredpor defecto
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 rollbackde una trx CMT por el bean
Implementación de transacciones
Demarcación de la trx
Beans de sesión con estado y comportamiento transaccional
� Hasta ahora…� el bean maneja el estado de recursos transaccionales, p.e. BDD; pero …
� Si el bean es con estado…� É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
Implementación de transacciones
Ejemplo BMT control de trx
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
Implementación de transacciones
Contenidos
Fuentes de excepciones
Manejo de excepciones
Tipos de excepciones Java
� Chequeadas, heredan de Exception� Indican errores lógicos en la aplicación
� NO chequeadas, heredan de RuntimeException� 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
� Aplicación o sistema
� Contexto transacción� Iniciado por el emisor� Iniciado por el contenedor� Sin transacción� Administrado por el bean
� Tipo de bean� 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 enterprisebean
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
Manejo de excepciones
Contenidos
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)
Uso de servicios de temporizador
Tipos de temporizadores
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
Uso de servicios de temporizador
Ejemplo: implementando TimedObject
Ejemplo: @Timeout
Uso de servicios de temporizador
Ver en Auction v.4
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
Uso de servicios de temporizador
cancel
Contenidos
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 principales JEE
Implementación de la seguridad
La asignación depende del contenedor concreto, se hace en el momento de la puesta en marcha de la aplicación
Autenticación del emisor de la llamada
Implementación de la seguridad
Depende de la infraestructura
Por el contenedor
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
Implementación de la seguridad
Ver en Auction v.5
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 beanllame a otro con una identidad configurada� Run-as
Implementación de la seguridad
Identidad run-asImplementació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 getCallerPrincipalImplementación de la seguridad
Ejemplo completoImplementación de la seguridad
Responsabilidades del implementador
Implementación de la seguridad
Contenidos
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:� Theading, código nativo, variables estáticas
� Poca lógica de negocio, mucha presentación y consultas� 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
Uso de las mejores prácticas de la tecnología EJB