Sesion 5. Desarrollo de Componentes de Negocio...

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


Arquitectura de contenedor de componentes


Implementación de la arquitectura


Contenedores JEE


Tipos de componentes JEE


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


Servicios de contenedor


Roles en JEE


Proceso de creación de aplicaciones EJB


Comparación del desarrollo con Java EE y tradicional


Contenidos

Casos de uso

Introducción a la aplicación de subasta

Modelo del dominio


Objetos del dominio (Auction)


Objetos del dominio (AuctionUser)


Objetos del dominio (Bid)


Objetos del dominio (Item)


Objetos del dominio (BookItem)


Arquitectura de la implementación


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


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.


Beans sin estado

� Cuidado con los atributos de instancia


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


Declaración de interfaz de negocio para bean de sesión

� Declarar interfaz de negocio

� Declarar las partes remotas y locales


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


Creación de bean de sesión que implementa la interfaz de negocio


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.


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


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


Ciclo de vida de session beanssin estado


Ciclo de vida de session beanscon estado


Definición de controladores de eventos de ciclo de vida

� Forma genérica


Objeto SessionContext� Proporciona acceso al EJBObject (al contenedor)� Entorno de seguridad� Información sobre el control de la transacción� Acceso a JNDI


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


Ejemplo de ejb-jar.xml


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


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)


Con servicios de contenedor

� Servlet o EJB local� El contenedor inyecta la referencia


Con servicios de contenedor

� Servlet o EJB remoto (en otro contenedor)

� Búsqueda JNDIEn ejb-jar.xmlo web.xml


Sin servicios de contenedor

� Clase Java (local o remota)� Se deben usar los servicios JNDI


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


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)


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


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


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)


Modelo de dominio en código


De clase a tabla


Metadatos con @Anotaciones


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



Metadatos xml, ejemplo

Campos persistentes o propiedades

Acceso properties:se anotan los getters

Acceso field:se anotan los atributos


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


Archivo persistence.xml

� Define las clases que forman parte de la persistence-unit (por su presencia)

� Especifica el DataSource


Ejemplo de uso EntityManagerJPA: conceptos básicos

Ver en Auction v.1


Estados de un objeto persistente JVM


APIs JPA


APIs JPA: interfaces y métodos

[email protected] 69

Notificación de cambios de estado

� Especificación de métodos callback con anotaciones� @PrePersist� @PostPersist� @PreRemove� @PostRemove� @PreUpdate� @PostUpdate� @PostLoad


Uso de Entity ManagerJPA: conceptos básicos

Uso de contexto extendidoJPA: conceptos básicos


Ver en Auction v.1

Estructura típica de archivo ejb-jar


Ver en Auction v.1

Contenidos

Categorías de anotaciones


JPA: modelado de asociaciones

Anotaciones por categoría




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



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



Unidireccional muchos a uno

Bid siempre debe tener un Item

<


Bidireccional uno a muchos

Doble actualización


<


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”


Uno o uno con foreign key

mappedBy en la clase que no tiene la FK


… 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



Muchos a muchos unidireccional

>



Muchos a muchos bidireccional


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?


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


Fetch por defecto


Modificación del comportamiento por defecto

Atributo del modo de cascadaJPA: modelado de asociaciones

Ver en Auction v.1

Contenidos


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


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


Table per concrete classSe crea una tabla por cada clase no abstracta

abstracta


Table per concrete class


Atención: Opcional en JPA, puede que no todos los proveedores JPA la soporten



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


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



Table per class hierarchy (3)



Table per class hierarchy (4)

@DiscriminatorColumn, @DiscriminatorValueno son necesarios, se toman valores por defecto si no están presentes



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


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



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)


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


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


Ejemplo

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

� Marca una clase como sólo ValueType� Se pueden configurar las propiedades (o atributos) con etiquetas:� @Basic, @Column, @Lob, @Temporal, @Enumerated


@Embeddable

POJO Ejemplo (Value Object)


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


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




� Enlace nominal (recomendado)

setParameter() sobrecargado para java.util.Date, java.util.Calendar y Object (ver documentación)




� Enlace posicional

setters sobrecargados

¡Ojo! Se empieza en 1

El orden de parámetros no tiene por qué ser secuencial



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


Consultas con nombre

� Se carga el string de la consulta desde mapeos

� createNamedQuery(…)

� Query con anotaciones o en orm.xml



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



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



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



Restricción (WHERE)

� WHERE para filtrar filas



Restricción (WHERE)



Operadores de comparación y precedencia

+

_



Restricciones sobre colecciones (WHERE)

� En el WHERE� Se pueden complementar con funciones



Funciones

JPA

Hibernate


Ordenación

� De la forma usual



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)


Proyección de escalares

En la select pueden ir atributos de clases…

… y resultados de funciones (las ya vistas)


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



Joins: inner, left y right outer

Todos los Itemscon sus Bids

Los Items que tienen Bids


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


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


Joins implícitos en SQL




Joins en FROM

� Cuando el camino de asociaciones resulta en un conjunto

one-to-many

many-to-many


Joins en FROM

� También left y right join

Los Item %name% y sus Bids aunque haya Itemque no tienen Bids


Join explícito en SQL



� El ajuste del join se hace en el WHERE� Es práctico para consultas sobre clases no asociadas


Theta-style en WHERE

Da pares


Consultas de agregados



Funciones en SELECT

count() min() max() sum() avg()


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



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)



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



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



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



Subselects

Correlada: puede tener peor rendimiento

Siempre entre paréntesis

No correlada: no tiene impacto de rendimiento


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


Tipos de clientes de mensajería

Se bloquea esperando la llegada de un mensaje


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


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


Elementos del API JMS


Estructura de los mensajes


Diagrama de colaboración


Ejem

plo


Diagrama de colaboración


Ejem

plo


Método gestor del evento



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


Código ejemplo


Filtra los mensajes que llegan


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


privatepublicprotected

@PostConstruct@PreDestroy@PostActivate…

API de InvocationContext


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


Ejemplo de método interceptor (en misma clase)


Ejemplo de clase interceptoraImplementación de clases y métodos interceptor

Interceptada

Interceptora

Varios métodos interceptores


Método interceptor en la misma clase

Clases interceptoras

Interceptores de ciclo de vida


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:


@PrePersist@PostPersist@PreRemove@PostRemove@PreUpdate@PostUpdate@PostLoad

Ver en Auction v.2

Ejemplo de métodos interceptores


Ejemplo de clase interceptora para entidades


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


Para cada método de bean…


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)

Requieredpor defecto

Compatibilidad de atributos de Trx y tipos de bean


Ejemplo de control de trx CMT


Control del estado de rollbackde una trx CMT por el bean


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


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)


Control de trx BMT



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


Opciones de control de trx en beans de mensajes


Mensaje envenenado


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


Excepciones de aplicación y sistema


Ruta de retorno 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


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


Excepciones de sistema:gestión por el contenedor


Manejo de excepciones en métodos de enterprisebean


Manejo de excepciones de aplicación en el cliente del bean


Manejo de excepciones del sistema en el código del cliente


Excepciones de anulación de transacción


Excepción de transacción requerida


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


Ejemplos de creación


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

Ejemplo: @Timeout


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


Administración de objetos 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


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


Asignación de identidades a principales JEE


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


Depende de la infraestructura

Por el contenedor

Estrategias de autorización


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


Declaración de roles de seguridad


Ver en Auction v.5

Declaración de permisos de métodos


Ejemplo: Declaración de permisos con descriptor


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


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


Método isCallerInRole


Mapeao de roles de bean a roles de aplicación


Método getCallerPrincipalImplementación de la seguridad

Ejemplo completoImplementación de la seguridad

Responsabilidades del implementador


Contenidos

Patrones para EJB

Uso de las mejores prácticas de la tecnología EJB

Elección 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


Algunos patrones conocidos aplicados a EJB

� Sesion bean �Fachada

� Secuenciador � Generador de claves


Patrones conocidos en EJB

� Data Transfer Object

� Interfaz de mensajes


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


Sesion 5. Desarrollo de Componentes de Negocio...

Documents

Transcript of Sesion 5. Desarrollo de Componentes de Negocio...