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 alb@uniovi.es 35

Conexión local

Interfaz local

EJB Container

Vistas de cliente locales y distribuidasmar-10 alb@uniovi.es 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

alb@uniovi.es 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

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. alb@uniovi.es 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. alb@uniovi.es 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 alb@uniovi.es 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

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

Resultados

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

Resultados

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

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...

Sesion Reciclaje

MENÚ - Jaliscoseplan.app.jalisco.gob.mx/files2/material_consulta/4_Planeacion_municipal/4_5... · C.M. 1 SESION 2 SESION 3 SESION 4 SESION 5 SESION 6 SESION 7 SESION 8 SESION 9 SESION

Quinta Sesion

SESION "A" SINTESIS y SESION "B" Practica 1

Interacción Hombre-Máquina - Departamento de ...di002.edv.uniovi.es/~cueva/asignaturas/doctorado/2004/1Fundamentos... · Incorporación de ayuda en línea ... considerada individualmente

Primera Sesion

SESION II_SIMBOLOGIA.pdf

Sistemas de informacin geográfica - di002.edv.uniovi.esdi002.edv.uniovi.es/~juanrp/docencia/gis/trabajos0708/Sistemas%20... · Sistemas de Información Geográfica. En principio

de Informática Panorámica - di002.edv.uniovi.esdi002.edv.uniovi.es/.../2004/01-Panorama/PanoramicaDotNet.pdf · Nueva herramienta: Visual Studio.NET ... seguridad, transacciones,

Gestión de Bases de Datos con Access.ppt)di002.edv.uniovi.es/~alberto_mfa/sid2/apuntes... · (Microsoft PowerPoint - Gestión de Bases de Datos con Access.ppt) Author: alb Created

1. Arquitectura Webdi002.edv.uniovi.es/~alberto_mfa/?download=1... · Concepto de Arquitectura en Desarrollo Software Concepción desde RUP Arquitectura física Distribución de nodos

Sesion Cuatro Investigacion de Mercado. Proposito de la Sesion Sesion : El proposito de esta sesion es facilitar que el estudiante comprenda y aplique.

Sesion HTML

Sesion 1 Gestion Del Talento Humano Sesion a 2016

Sesion 4. Desarrollo de Componentes Web con Servlets y JSPdi002.edv.uniovi.es/~alberto_mfa/?download=Sesion 4. Desarrollo de... · Sitios web y aplicaciones web Un sitio web es una

Sesion Stroke

Segunda sesion

Sesion tres

SESION ELÉCTRICAS

Lectores de libros electrónicos, dispositivos ...di002.edv.uniovi.es › ~luciano › ICE › I.pdf · Lectores de libros electrónicos, dispositivos, prestaciones y formatos. 1