Sesion 3. desarrollo de aplicaciones jee

ene-09 [email protected] 1

Desarrollo de aplicaciones JEE


Contenidos


Plataformas de la tecnología Java y Java EE

Requisitos de las aplicaciones de empresa


Tecnologías de infraestructura en aplicaciones de empresa



Elementos de la tecnología Java EE



Función de las API de Java EE



Contenedores Java EE



Separación de lógica de negocio y servicios



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 carga

API y servicios de la plataforma Java EE

Configurados en XML o con annotations Usados desde código


Servicios Java EE

API y servicios de la plataforma Java EE


Arquitectura de N capas

Capas y arquitecturas de la plataforma Java EE


JEE y las N capasCapas y arquitecturas de la plataforma Java EE


Arquitectura de N capas



Variantes en la arquitectura de N capas en JEE

� Centrada en la web� Combinada basada en la web y en componentes EJB� arquitectura centrada en componentes EJB

� Aplicaciones interempresariales (B2B)� Aplicaciones de servicios web



Arq. centrada en la web



Arq. centrada en EJB



Arquitectura B2B



Arq. de servicios Web



Catálogo de patrones Java EE

Patrones Java EE


Algunos patrones en Java EEPatrones Java EE


Contenidos


Componentes Java EE

� Componente: A menudo una agrupación de clases e interfaces que implementan una unidad autónoma de funciones.

� Tipos de componentes JEE:� Servlets� JSP (java servlet pages)� Beans de sesion� Clases entidad� Beans de mensajes

Principios de desarrollo basado en componentes


Características de los componentes Java EE

� Estado y propiedades� Encapsulación en un contenedor� Capacidad para interacciones de componentes locales y distribuibles

� Transparencia de ubicación� Obtención de referencias a componentes a través de un sistema de nombres



Estado y propiedades de componentes

� Estado: Capacidad del componente para almacenar información entre invocaciones del mismo cliente:� Con estado� Sin estado

� Ventaja técnica para mayor clusterización

� Propiedades:� Característica visible de un componente:

� En Java pares getters y setters



Interfaces como contratos

� Encapsulación: ejecución dentro de un contenedor. � Independencia del entorno

� Interfaces como contratos: Los componentes interactúan solo través de sus interfaces� Interface java



Interfaces como contratos



Conexiones remotas y locales


Conexiones remotas(diversas tecnologías)

Conexiones locales


RMI, remote methodinvocation

� Marshalling y unmarshalling� Transmisión de excepciones� Transmisión del contexto de seguridad� Transmisión del contexto de transacción



Implicaciones de invocación remota

� Cambio de semántica:� Paso por valor (remotas)� Paso por referencia (locales)

� Marshalling y unmarshalling� Sobrecarga grande (10/1)

� Acceso remoto proporciona transparencia de ubicación



Servicios de nombres en el modelo de componentes



Uso del API JNDI en JEE


Código a ejecutar en la parte cliente

Configuración en cliente externo para localizar el servidor JNDI


Uso del API JNDI en JEE

El registro JNDI mantiene referencias a los beans que sirve el contenedor



Tipos de objetos retornados por JNDI

� Conexiones a bases de datos relacionales� Conexiones a servicios de mensajería� Destinos de mensajes� Variables de entorno de componentes� Conexiones a sistemas heredados compatibles con adaptadores de recursos

Necesario hacer un cast


EJBContext para localizar componentes


EJBContext: contexto JNDI especializado para localizar ejb en java:comp/env


Inyección de dependencias en vez de JNDI

� El contenedor por medio de reflectividad interviene el código en el arranque del contenedor



Comparación entre comunicación síncrona y asíncrona

� Síncrona:� Semántica petición-respuesta� El llamador bloquea en espera mientras el llamado resuelve

� Asíncrona:� Semántica petición-notificación� El llamador no bloquea en espera� Reduce el acoplamiento

Modelo de comunicación asíncrona


Interacción asíncrona de componentes



Ventajas e inconvenientes de las interacciones asíncronas

� Ventajas:� Reducen acoplamiento entre componentes� Mejor rendimiento de máquinas en operaciones largas

� Inconvenientes:� Infraestructura más compleja

� Servidores, buffers, notificaciones

� Generan más tráfico de red ¿?



Roles en JEE

Desarrollo de aplicaciones Java EE


Fases de desarrollo

� Diseño� Codificación� Creación de descriptores de implementación

� Empaquetado� Ensamblaje� Despliegue



Ensamblado de EAR



Opciones para automatizar el empaquetado y el despliege

� Herramientas específicas� Makefile� Apache ANT � muy usada en Java

� Fichero build.xml con instrucciones� Solución universal� Ver ejemplo

� IDE: � Eclipse, Netbeans

Comparación entre opciones de desarrollo


Sistemas de control de código fuente

Comparación entre opciones de desarrollo


Configuración y empaquetado

� Archivos de almacenamiento web(WAR)

� Archivos de almacenamiento Java (JAR)� Archivos de almacenamiento de recursos (RAR)

� Archivos de almacenamiento empresariales (EAR)

Configuración y empaquetado de aplicaciones JEE


Archivos WEB



Creación manual de .WAR

2008-2009 46DASDI



Archivos JAR

� Contienen módulos EJB� Clases� Interfaces� Descriptores de despliege

� Otros recursos



Ejemplo estructura EJB-JAR

2008-2009 48DASDI



Archivos de recursos (RAR)

� Componente de más bajo nivel integrado en el framework JEE� Manipulación de Transacciones, Seguridad� Llamadas nativas, manipulación de hilos, etc

� Adaptadores a otros sistemas, etc



Archivos EAR

� Archivo que contiene todas las capas de la aplicación y todos los subcomponentes



Descriptores de despliege

� Modo declarativo de describir las interacciones entre componentes y entre componentes y sus contenedores mediante el uso de archivos XML

� En Java EE 5, los descriptores de implementación son optativos. Se pueden utilizar anotaciones en el código.

� Los descriptores de implementación, de haberlos, anulan las anotaciones en el código.



Ejemplo ejb-jar.xml



Estructura application.xml



Descriptores específicos

� Para cada contenedor concreto� Se especifican las características propias de ese contendor

� Cada contendor es distinto� En un empaquetado se pueden añadir muchos descriptores distintos



Ejemplo servidor Sun Java System



Contenidos


Arquitectura de aplicaciones Java EE centrada en la web

Función de los componentes web en una aplicación Java EE


Arquitectura de aplicaciones Java EE centrada en EJB

Función de los componentes web en una aplicación Java EE


Protocolo HTTP

Modelo de petición-respuesta de HTTP


Tipos de peticiones HTTP

Un navegador puede enviar la información al servidor de varias formas:

� GET: Paso de parámetros en la propia URL de acceso al servicio o recurso del servidor. Método “doGet” del servlet

� POST: Lo mismo que GET pero los parámetros no van en la línea de URL sino en otra línea a parte. El manejo es idéntico. Método “doPost” del servlet.

� PUT, …



Peticiones GET y POST

� Get: datos en query string

� Post: datos en cuerpo de la petición


Contenido del paquete HTTP


Respuesta devuelta por el servidor

� Entre las cabeceras de respuesta:� Resultado de la petición (status-code)

� MIME type de los datos� Codificación estándar de los tipos de datos� Página HTML: text/html� Documento XML: text/xml� Imagen en formato JPEG: image/jpeg


200 – OK400 – Bad Request401 – Unauthorized403 – Forbidden404 – Not Found. . .


HolaMundo Servlet

Comparación entre servlets y componentes JSP


Ejemplo de página JSP



JSP: Proceso de compilación



Ejemplo: de JSP a Servlet(Tomcat)



JSP a

Servlet.service()



Servlet API


Servlets: Jerarquía

� No es habitual implementar Servletdirectamente

� Heredamos de HttpServlet


Administración y ciclo de vida



Método service()

� Validar los datos de formulario.� Actualizar el modelo de datos de la aplicación.

� Reunir datos del modelo que va a representarse.

� Representar los datos en HTML o pasar la petición y los datos a otro componente para que los represente.



Combinación de servlets y componentes JSP

� Lo más habitual es usar combinaciones de servlets y JSP� JSP para generar la vista� Servlets para ejecutar la lógica del negocio



Concurrencia basada en hilos

Control de la concurrencia en componentes Web


Consecuencias para el desarrollador

� Un único Servlet puede estar atendiendo múltiples peticiones simultáneas� Varios hilos ejecutándo service() � posibles problemas de concurrencia

� Precauciones al:� Usar variables de instancia� Usar variables de clase (static)� Acceder a recursos externos si ellos no soportan concurrencia

� Posible recurso:



Asignación de alias y raíz de contexto web

� Formato general de URI


Nombre de la aplicación (el del paquete WAR o EAR)

Nombre del ficheroo alias de servlet que forma parte de la aplicación

bank.war


Control de sesión de usuario� HTTP no tiene sesión, la aplicación web debe hacerse cargo de ella� Varias posibilidades tecnológicas

� Enviar datos de sesión al navegador� Cookies, URL rewriting, etc� Útil si hay pocos datos

� Mantener datos en el servidor� El servidor necesitará más memoria� Al navagador solo se envia token de sesión

� En JEE el contenedor se hace cargo de la gestión de la sesión y ofrece un API de gestión

Administración de sesiones


Problemas de desarrollo de capas web

� HTTP es petición-respuesta� El servidor no se puede comunicar con el cliente� La respuesta debe incluir una actualización de la vista

� Aplicaciones con muchas “pantallas” tendrán muchos servlets y muchas URLs � difícil de gestionar

� JSP útil para presentar pero incómodo para lógica, servlets lo contrario

Complejidad de la capa Web


Arquitectura Model 1

Secundino González Pérez



Arquitectura Model 2

Secundino González Pérez



Paradigma modelo-vista-controlador

Patrones de diseño en la capa Web


Arquitectura 2 y MVC



Patrón Business-Delegate



Frameworks disponibles

� Generalizaciones del patrón MVC� Configuración XML del mapa de pantallas� Acciones, Vistas, etc

� Struts (1 y 2)� Tapestry� Spring MVC� WebWork� Java Server faces



Contenidos


API genéricas y específicas de los protocolos

Conceptos básicos sobre el API de los servlets


Método service()



Método service() en HTTPServlet

Separa la petición en función del método HTTP



Métodos de manejo de peticiones



Métodos de manejo de peticiones, código



HolaMundo Servlet



Configuración de servlets

� En fichero web.xml� Suministra información acerca del despliege de componentes en el contenedor� Página de inicio, mapes de Servlets y URLs, parámetros de configuración para servlets, recursos referenciados, etc



Ejemplo fichero web.xml



Utilización de las API de petición y respuesta


protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException {

. . .}

protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, java.io.IOException {

. . .}

� Service (doGet y doPost) reciben interfaces instanciadas:� “HttpServletRequest” canal de entrada con información enviada por el usuario

� “HttpServletResponse” canal de salida (página web)


HttpServeltRequest HttpServletResponse

serviceservice()()

Attributes[R/W/D]

Parameters[R]

Session[R/W/D]

Cookies [R]

ContentType[W]

Writer[W]

OutputStream[W]

Cookies[W]

Redirect[W]

WebContainer




<form> y request.getParameter()



Interfaz RequestDispatcher

� Deriva la petición a otro servlet o JSP para que complete el procesamiento� Es lo que permite que el JSP genera la vista y el servlet procese la lógica

Reenvío de control y transferencia de datos


Métodos forward e include� forward():

� La salida del componente al que se transfiere el control se convierte en la salida del componente que lo ha llamado.

� El componente llamante no puede generar ninguna salida por sí solo.

� Suelen utilizarlo los controladores (servlets)� include():

� La salida del componente al que se transfiere el control se inserta en la salida que genere el componente llamante.

� Suelen utilizarlo las vistas (JSP)



Transferencia de datos en la request

� Permite pasar datos desde un componente a otro de la cadena de procesamiento usando la request como almacén


En el JSP


Gestión de la sesión por el contenedor



Interfaz HttpSession

Deprecated methods



Enlace de sesion y navegador

� Cookies� En servidor las inserta en cada respuesta al navegador

� Reescribiendo todas las URL generadas por el contenedor


Rewrited as


Cierre de sesión, timeout, nueva



Contenidos


Presentación con JSP

� Ventajas:� Páginas hechas por diseñadores� Mejor interacción con herramientas de diseño

� Herramientas sencillas, editor de texto� Funcionan como servlets una vez compilados

� Posibilidad de ejecutar lógica (aunque es mejor que solo se dediquen a presentación)

Tecnología JSP como mecanismo de presentación


Proceso de compilación



Elementos en las páginas JSP� Directivas

� Permiten condicionar la generación del código del servletgenerado

� Requisitos de buffering� Página de error para redirección, etc.

� Acciones� Etiquetas XML que invocan a clases que generan código de

salida para la petición� Acciones estándar� Acciones propietarias (Tag libs)

� Scriptlets� Permite insertar código java que será ejecutado en el

momento de la petición



Elementos en las páginas JSP

Creación de páginas JSP


Formas sintácticas de las etiquetas JSP



Directivas JSP� Las directivas son mensajes al contenedor de JSP

� Ejemplos:ElementoElemento DescripciDescripcióónn

<%@ <%@ pagepage ... %>... %>

Permite importar clases Java, especificar el Permite importar clases Java, especificar el

tipo de la respuesta (tipo de la respuesta (““texttext//htmlhtml”” por omisipor omisióón), n),

etcetcééteratera<%@ <%@ includeinclude ... ...

%>%>Permite incluir otros ficheros antes de que la Permite incluir otros ficheros antes de que la

ppáágina sea traducida a un gina sea traducida a un servletservlet

<%@ <%@ taglibtaglib ... %>... %>

Declara una biblioteca de etiquetas con Declara una biblioteca de etiquetas con

accionesacciones personalizadas para ser utilizadas personalizadas para ser utilizadas

en la pen la pááginagina

Forma general: <%@ directive { attr=”value” }* %>



Directiva page



Directiva import

� Inserta el texto de otro recurso en tiempo de compilación



Ejemplo: directiva include


Elementos de “scripting”

ElementoElemento DescripciDescripcióónn

<% ... %><% ... %> ScriptletScriptlet. se usa para meter c. se usa para meter cóódigo Java dentrodigo Java dentro

<%= ... %><%= ... %>ExpresiExpresióónn. Permite acceder al valor devuelto por . Permite acceder al valor devuelto por

una expresiuna expresióón en Java e imprimirlo en OUTn en Java e imprimirlo en OUT

<%! ... %><%! ... %>DeclaraciDeclaracióónn. Usada para declarar variables y . Usada para declarar variables y

mméétodos en la clase correspondiente a la ptodos en la clase correspondiente a la pááginagina

<%<%---- …… ----%>%>

ComentarioComentario. Comentario ignorado cuando se . Comentario ignorado cuando se

traduce la ptraduce la páágina JSP en un gina JSP en un servletservlet..

(comentario en el HTML <!(comentario en el HTML <!---- commentcomment ��))


Ejemplo: expresión, saludo.jsp

expresión

Nota: Si se necesita usar los caracteres "%>" dentro de un scriptlet, hay que usar "%\>" y “<\%”

<%=



Ejemplo: scriptlet, saludo.jsp

<%



Ejemplo: declaración, saludo.jsp

<%!



JSP: Objetos predefinidos

� El código java incrustado en JSP tiene acceso a los mismos objetos predefinidos que tenían los servlets

� Aquí se llaman como sigue:�� requestrequest

�� responseresponse

�� pageContextpageContext

�� sessionsession

�� applicationapplication

�� outout

�� configconfig

Se puede acceder a

ellos directamente

desde los “scriptlets”



Acciones JSP

� Etiquetas XML que tienen procesamiento asociado

Procesamiento de datos de servlets


<jsp:useBean



<jsp:useBean id=“”



Ambitos JSP



Recuperando beans de la request



Syntax

<%@ taglib ( uri=”tagLibraryURI” | tagdir=”tagDir” ) prefix=”tagPrefix” %>

Directiva taglib

Bibliotecas de etiquetas personalizadas

� Declara que la página usa una librería de tags (acciones)

� Identifica la librería por su URI� Le asocia un prefijo para usar en el código de la JSP

<%@ taglib uri=”http://www.mycorp/supertags” prefix=”super” %>...<super:doMagic>...</super:doMagic>

Alias definido en web.xml


Ejemplo de uso de JSTL y EL

Bibliotecas de etiquetas personalizadas


Contenidos


Tipos de EJB� Además de los componentes EJB, el contenedor EJB

también pueden contener clases entidad JPA y otras clases auxiliares y de utilidad general.

Función de los componentes EJB


Solución en capas

ene-09 127

DAO Factory

ProcsFacade

Service Interface

Action

Action

Action

Action

Facade

Lógica PersistenciaPresentac.

Control

Persistence Interface

JDBC

Procs

Hibernate DAO

JDBC DAO

JPA DAO

Spring DAO

ModelModelModelProcs

Procs

Función de los componentes EJBSession Beans

implementan el patrón Fachada

Clases Java implementan el modelo del dominio


Capas de EJBs



Interfaces Context

� EJBContext� SessionContext� MessageContext

� Permiten al componente EJB interaccionar con el contenedor� Seguridad� Transacciones� Búsquedas JNDI



Función del contenedor EJB

Análisis del modelo de componentes EJB


Objetos EJB y proxies

� Intercepta las llamadas y toma el control

Clase que se programa

ene-09 131

EJBObject


Vistas de cliente locales y distribuidas


Conexión local

Interfaz local

EJB Container


Vistas de cliente locales y distribuidasene-09 [email protected] 133

Conexión remotaInterfaz remota

EJB Container


Invocación de stateless: cliente

� Este código se ejecuta en otra máquina (JVM)

� El cliente necesita acceso a la implementación del stub

� El stub se obtiene de un registro JNDI

ene-09 134


Servlet con referencia un beande sesión remoto sin estado� La referencia se guarda en atributo de

instancia� El bean staless es concurrente (thread safe)

� Se inicializa en el init()

Llamada a EJB desde servlets


Servlet con referencia a través de anotaciones� Inyección de referencias

� Solo es posible en componentes gestionados por el contenedor

� No hace falta contexto ni búsqueda JNDI.� El contenedor asigna un valor a la variable de la referencia bankMgr cuando se instancia el servlet.

� La inicialización no genera excepciones.

Llamada a EJB desde servlets


Contenidos


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

Comparación de comportamientos con y sin estado

� Carrito de la compra� Datos en varias páginas


Beans sin estado

� El bean no retiene información del cliente.� Entre invocaciones es posible que un cliente no obtenga la misma instancia de bean de sesión.

� Una misma instancia de bean de sesión puede manejar cualquier número de solicitudes de cliente. � Mejora de rendimiento.

Características de los beans sin estado


Beans sin estado

� Cuidado con los atributos de instancia

Características de los beans sin estado


Beans con estado

Características de los beans con estado


Adaptación de una clase Java a EJB sin sesión

� Declarar interfaz de negocio

� Definir clase de implementación

Creación de beans de sesión

anotaciones


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


Interfaces locales y remotas


� La implementación se puede anotar con @Remotepero no con @Local y @Remote a la vez

� Un implementación puede ser remota y local pero las anotaciones van en cada interfaz


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.



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



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

Empaquetado y despliegue de beans de sesión


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



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)

Creación de un cliente bean de sesión


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 JNDI


En ejb-jar.xmlo web.xml


Sin servicios de contenedor

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



Contenidos


Persistencia

� Necesidad de que los datos manejados sobrevivan tras la ejecución a del programa� Muchas técnicas y tecnologías (ficheros, serialización, bases de datos, etc)

� JPA: especificación de un mapeadorobjeto/relacional

API de persistencia de Java


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)

Mapeadores objeto/relacional


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

Requisitos de una clase Entidad


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



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



Conceptos básicos� Unidad de persistencia

� Conjunto de clases 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 persistence� 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

Ciclo de vida de las entidades


Archivo persistence.xml

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

� Especifica el DataSource



Ejemplo de uso de EntityManager


ene-09 [email protected] 170ene-09 [email protected] 170

Estados de un objeto persistente JVM



Notificación de cambios de estado

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



Estructura típica de archivo ejb-jar



API JPA



Consultas, lenguaje de consulta

� El EntityManager permite la creación de objetos Query� NativeQuery

� SQL nativo de la BDD

� NamedQuery� Consulta externalizada a fichero xml (orm.xml)

� Query� Expresadas en JPA-QL� Lenguaje de consultas OO independiente de la BDD



Ejemplo de Queries



Contenidos


Transacciones ACID

� Es la demarcación de una unidad de trabajo

� JPA permite trabajar con varios API de transacciones� JSE JDBC� JTA� Declarativas (EJB)

Semántica transaccional


Control de concurrencia

� Las trx ACID crean la ilusión de que cada usuario es único en la base de datos � aíslan a unos de otros

� El aislamiento tradicionalmente se consigue con bloqueos a nivel de fila, de rangos o de tabla:� De lectura (compartido)

� todos podemos leer pero nadie escribir� De escritura (exclusivo)

� nadie puede leer porque voy a escribir y nadie más puede escribir

� Las transacciones JEE en contendor pueden ser distribuidas

Semántica transaccional


Control de la trx

� Programáticas: el programador se hace cargo de la gestión usando el JTA� Acceso a la trx en curso por JNDI

� Declarativas: se especifica para cada operación su comportamiento transaccional� El contendor se encarga de la gestión� Anotaciones o xml

Transacciones programáticas y declarativas


Control usando JTA

� Acceso JNDI o anotacion

Controlar transacciones programáticas JTA


Ejemplo de control de transacción

Controlar transacciones programáticas JTA


Control por el contenedor

� El atributo de la trx controla el ciclo de vida de la transacción en curso� Required� RequiresNew� NotSupported� Supports� Mandatory� Never

Transacciones administradas por el contenedor


Coordinador de transacciones

Transacciones administradas por el contenedor


Control pesimista y optimista

ene-09 Alberto M.F.A. [email protected] 184

Lock Lock

ROLLBACK

Lock v1.0 v2.0 v1.0

ROLLBACK

En BDD ya no es v1.0

PESIMISTA OPTIMISTA

Bloqueo optimista y control de versiones

ene-09 [email protected] 185ene-09 Alberto M.F.A. [email protected] 185

Control optimista

� Diferencia entre trx de sistema y trx de aplicación

� El control optimista además permite detectar cambios en actualizaciones entre trx de sistema

La solución optimista es añadir versiersióónn a los objetos



Versionado de objetos con campo versión

� Añadir información al objeto para poder detectar cambios entre el estado detached y persistent� Campo versión (un entero)� Timestamp (de la última modificación)



Mapeado de campos

Sin get/set

JPA gestiona los campos versión de forma automática

Tipos válidos para versionado

!



Excepciones JPA

ene-09 Alberto M.F.A. [email protected] 188

�Todas las excepciones JPA son fatales y dejan el contexto de persistencia inutilizado

�Todas las excepciones lanzadas por EntityManager provocan rollback()

�Todas las de Query tb, excepto NoResultException yNonUniqueResultException.

Todas NO chequeadas

Excepciones durante una transacción


Chequeadas y no chequeadas

� No chequeadas provocan rollback� Las chequedas por sí solas no� Trx distribuidas:

� Otro agente puede provocar rollback y ya lo notificó � comprobar si la trx estámarcada para rollback

� Uso de EJBContext� getRollbackOnly� setRollbackOnly

Excepciones durante una transacción


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)

Tecnología del API JMS


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

Creación de un productor de mensajes de cola


Ejem

plo

Creación de un productor de mensajes de cola


Diagrama de colaboración

Creación de un consumidor de mensajes síncrono


Ejem

plo

Creación de un consumidor de mensajes síncrono


Método gestor del evento

Creación de un consumidor de mensajes asíncrono


Creación de un consumidor de mensajes asíncrono


EJB como clientes de mensajería

EJB como clientes de mensajería


Contenidos


MessageDriven Beans

� Son clientes asíncronos de mensajes� Implementan el interfaz MessageListener

� Desconectados de cliente

Introducción a los beans controlados por mensajes


Ciclo de vida

Introducción a los beans controlados por mensajes

Posible interceptar los cambios de estado

@PostConstruct@PreDestroy


Código ejemplo

Creación de un bean controlado por mensajes


Creación de un bean controlado por mensajes

Filtra los mensajes que llegan


Contenidos


Servicios Web

� W3C: “sistema de software diseñado para permitir la interacción interoperable entre máquinas en una red”

� Características:� Independencia de plataforma (Hw + SO)� Uso de tecnologías Internet: XML, HTTP, etc� Interoperabilidad de programas: clientes y servidores escritos en cualquier lenguaje

� Invocación a servicios ofrecidos como procedimientos

Finalidad de los servicios web


Servicios web como componentes remotos� Mismo paradigma que otras soluciones anteriores:� CORBA� RMI� RPC� DCOM

� Diferencia técnica: Se emplean tecnologías estándares abiertas Internet� XML, SOAP� HTTP, SMTP



Comparación entre servicios web y EJB remotos

� La implementación del servicio websimilar a un EJB de sesión

� El registro JNDI podría ser el registro UDDI de los WS

� El protocolo de transporte HTTP en vez de RMI-IIOP

� Los datos se transfieren en XML (SOAP) en ves de serializados



Requisitos de interoperabilidad

� Intercambio de mensajes HTTP y XML� Se necesita cerrar más las posibilidades

� SOAP � especificación XML para intercambio de invocaciones y respuestas

� WSDL � descripción “semántica” de los servicios ofrecidos (el interfaz)

� HTTP � métodos y cabeceras estandarizados

� UDDI � norma de publicación y búsqueda de servicios ofrecidos

Especificaciones de los servicios web


Arquitectura de WS



Ejemplo mensajes SOAP


Petición

Respuesta


Ejemplo WSDL “hola mundo”


Estructura general de documento WSDL


APIs java para WS� JDOM� JAXP � Java API for XML procesing� JAXB � Java API for XML binding� JAX-RPC � Java API for RPC� JAXR � Java API for UDDI registry� SAAJ � SOAP API with Attachements� JAX-WS � Java API for WebServices

� API de más alto nivel � Usa todas las demás por debajo� Permite manejo de WS sin conocimientos de XML, SOAP, etc

APIs de Java relacionados con servicios web

-

+

Complejidad


Contenidos


Punto final un Servlet

Puntos finales servlet JAX-WS

web.xml


Punto final un EJB

Puntos finales EJB JAX-WS


Tipos de datos admitidos en JAX-WS

� Se pueden transferir tipos básicos a WS

� Tipos complejos deben marcados

Puntos finales EJB JAX-WS


Desarrollo de clientes

� Es necesario disponer del WSDL

� A partir del archivo de especificación se pueden generar clases proxy� Las usa el cliente � Se encargan de localizar el servicio y realizar las conversiones Java�� SOAP

� También es posible generar el proxydinámicamente

Clientes de servicios Web


Ejem

plo

Clientes de servicios Web

Cliente con proxy dinámico

Cliente con proxy estático


Contenidos


Conceptos de seguridad

� Autenticación� Asegurar la identidad del usuario

� Autorización� Verificar que tiene permiso para la operación que solicita

� Confidencialidad� Impedir el espionaje de datos en transporte

� Integridad� Detectar la corrupción de los mensajes en el transporte

Seguridad administrada por el contenedor


Conceptos

� Autenticación y autorización pueden ser gestionados por JEE� No es aconsejable usar estrategias de seguridad programáticas � poco portables, poco maduras

� Confidencialidad e integridad conseguidas con un protocolo de transporte seguro� SSL (TLS)



Propagación del contexto de seguridad


ene-09 [email protected] 229ene-09 Alberto M.F.A. 229

Seguridad para WEB (HTTPS)

� HTTPS = HTTP Secure� HTTP sobre un protocolo de transporte seguro� HTTP � SSL � TCP

� SSL también es conocido como TLS según IETF



SSL (o TLS)� El servidor tiene un certificado

� opcionalmente el cliente tiene el suyo� Permite intercambio seguro de datos (p.e. claves de sesión)

� Usa algoritmos de clave simétrica y asimétrica

� Ofrece:� Autentificación � Confidencialidad� Integridad

Del servidor siempre, del cliente si tiene certificado



Autenticación administrada por contenedor web



Especificación� En web.xmlweb.xml� Una colección de recursos (URLs) solo podrán ser accedidos por usuarios que actúen bajo determinado rol usando determinados métodos HTTP

� La autenticación para cada ámbito de seguridad (realm) se hará usando alguna de las técnicas establecidas por la especificación de servlets



web.xml

� Colección de recursos, roles y métodos

Si no hay método todos están protegidos



web.xml

� Roles

� Técnicas



Tipos de autenticación soportados

� BASIC� DIGEST� FORM� CLIENT-CERT



Autentificación por Formulario

� No es segura por sí sola, es necesario combinarla con HTTPs (SSL – Secure SocketLayer)

� Permite controlar la apariencia de la pantalla de login

� La pantalla de login es HTML estándar, sigue un convenio de nombres� Action: j_security_check� Login: j_username� Pass: j_password



Interacción con la infraestructura de seguridad� BDD de usuarios y roles

� El contenedor consulta los datos de una fuente directamente

� Tipos de fuentes y configuración dependen de la implementación del contenedor

� Base de datos (tablas: usuarios, roles)� Ficheros XML� Ficheros de propiedades� . . .

� Consultar documentación del contenedor



Usuarios y roles

Roles y responsabilidades del usuario


Autorización basada en funciones en la capa EJB

Roles y responsabilidades del usuario


Métodos de API

� Métodos en web:� getUserPrincipal y isUserInRole

� Métodos en EJB:� getCallerPrincipal y isCallerInRole

Utilización del API de seguridad


API de seguridad de la capa web



API de seguridad de la capa EJB



Autenticar clientes de WS

� Mismo caso que el del navegador web� En el paquete HTTP debe ir la autenticación de usuario (sobre SSL)

� Si el WSDL está protegido el cliente debe tener una copia local

Seguridad HTTP y clientes JAX-WS

Sesion 3. desarrollo de aplicaciones jee

Technology

Transcript of Sesion 3. desarrollo de aplicaciones jee