IMPLEMENTACION DE APLICACIONES INTERNET II

Presentación del tema: "IMPLEMENTACION DE APLICACIONES INTERNET II"— Transcripción de la presentación:

1 IMPLEMENTACION DE APLICACIONES INTERNET II
Persistencia de Datos

2 Objetivos Describir la correspondencia (mapping) objeto – relacional y el concepto de persistencia de datos. Conocer y aplicar apropiadamente los patrones y frameworks utilizados para brindar persistencia. Emplear apropiadamente los motores de persistencia.

3 Contenidos Bases de datos orientadas a objetos.
Motores de persistencia. Opciones.

4 Introducción En general, una aplicación informática consta de dos componentes principales que colaboran para llevar a cabo la funcionalidad que el usuario desea: El programa que implementa la aplicación, el cuál recupera datos de una base de datos, realiza los cálculos necesarios y presenta los resultados deseados al usuario. La base de datos como tal, que guarda la información necesaria para operar la aplicación, en forma de datos estructurados en los discos.

5 Introducción (2) Para que estos dos componentes puedan funcionar juntos deben poder comunicarse intercambiando datos: En otras palabras, deben ser compatibles. Sin embargo, durante los últimos treinta años, la evolución de estos dos componentes ha sido divergente, de forma que cada vez se ha hecho más difícil que colaboren en una misma aplicación. Así, desde los años 70s hasta la actualidad, las bases de datos utilizan un modelo teórico llamado “relacional”, que se ha convertido en un estándar y que es utilizado en la práctica por la totalidad de las aplicaciones de software.

6 Introducción (3) En cambio, los programas han usado, desde los años 80s, el modelo “orientado a objetos”, que difiere en mucho del modelo relacional y que se ha extendido cada vez más. Es por ello que aparece un conflicto a la hora de reunir estos dos componentes en una aplicación, ya que cada uno responde a diferente modelo y forma de operar. Cada componente maneja los datos con un formato diferente. Metafóricamente, podría afirmarse que el programa y la base de datos hablan idiomas diferentes y, por lo tanto, la comunicación entre ellos resulta difícil.

7 Persistencia Concepto:
Habilidad del programador para lograr que sus datos sobrevivan a la ejecución de un proceso, para eventualmente reutilizarles en otros procesos. La Persistencia debe Ser ortogonal: a cada objeto, independientemente de su tipo, de permitírsele convertirse en persistente como tal, sin una traducción explícita. Además, debe estar implícita: el usuario no debe tener que explícitamente mover o copiar datos para convertirlos en persistentes.

8 Modelo Relacional Basado en un artículo publicado por E. F. Codd en 1970. Las primeras bases de datos relacionales comerciales aparecen en la segunda mitad de los años setenta. Se ha convertido en un estándar prácticamente universal para el acceso a datos, dominando totalmente el área de las bases de datos hasta la actualidad. Este modelo se ocupa sólo de la parte estática de la aplicación (de los “datos”) y no de la parte dinámica (“los procesos”). Este énfasis en los datos es lógico en un modelo cuyo objetivo es modelar la parte estática de la aplicación, es decir, la base de datos. En el mundo de Bases de Datos (Relacionales) empleadas desde hace décadas en distintas industrias para guardar información, los datos no residen en objetos, sino en Tablas conformadas por Columnas y Renglones.

9 Ejemplo: Base de datos books
Integrada por las tablas: Autores Editoriales Títulos ISBNAutor Relación entre ellas: ISBNAutor idAutor isbn Autores nombrepila apellidopaterno Títulos titulo numeroedicionion copyright idEditorial ArchivoImagen precio 8 1 Editoriales idEditorial nombreEditorial

10 Diferencias entre los dos modelos
La forma en la que el modelo relacional trata los datos es muy diferente a cómo lo hace el modelo orientado a objetos: Mientras en este último, los datos son modelados en forma de objetos, en el modelo relacional son modelados como registros, los cuales son una serie de datos pertenecientes a una misma entidad de la vida real. Un registro difiere de un objeto en que sólo modela datos y que éstos no tienen estructura. En el modelo orientado a objetos, la información es manipulada a través de Objetos: entidades que describen las características y el comportamiento de determinada fuente, sean: personas, productos, cuentas bancarias u otro ente.

11 Diferencias … (2) El modelo relacional no refleja la estructura de la realidad: los registros están por separado y se relacionan por un mecanismo implícito llamado “clave foránea”. El programador debe saber que hay una relación entre los elementos ubicados en diferentes tablas, y debe programar de acuerdo a ello. Sin embargo, el modelo no refleja explícitamente esta relación y, en general, la estructura de la realidad, al contrario del modelo orientado a objetos.

12 Diseño relacional del modelo conceptual de la base de datos books

13 Diseño orientado a objetos del modelo conceptual de la base de datos books

14 Diagrama de clases generado por NetBeans 5.5

15 Diagrama de clases … (2)

16 Aplicaciones tradicionales
El programa suele estar diseñado según el modelo orientado a objetos y, por lo tanto, trabaja con datos en formato de objetos. Por el contrario, la base de datos está diseñada según el modelo relacional y, por lo tanto, trabaja con datos en formato de registros. Esto introduce una dificultad importante, porque los dos formatos de datos, objetos y registros, son incompatibles entre sí.

17 Aplicaciones tradicionales (2)
Así, cuando el programa quiere guardar o recuperar datos de disco para que no se pierdan entre ejecuciones, lo hace en forma de objetos, pues es el formato de datos que conoce. Sin embargo, la base de datos no puede guardar o recuperar objetos, pues está diseñada para guardar o recuperar registros, que es el formato de datos que reconoce. Por tanto, debe encontrarse una solución para que se comuniquen.

18 Solución obvia La solución más obvia a este problema es hacer que uno de los componentes hable el idioma del otro, es decir, que un componente use el formato de datos del otro. Así, la primera opción es que el programa esté diseñado para tratar con datos relacionales. En esta opción, tanto el programa como la base de datos hablan un mismo idioma: el relacional y utilizan como formato de datos el de registro. Por lo tanto, la comunicación es posible.

19 Comentarios Ésta era la manera de programar universalmente adoptada antes de la aparición de la orientación a objetos, y sigue siendo la arquitectura dominante aún en muchas aplicaciones. Incluso entre las empresas que utilizan lenguajes orientados a objetos, la mayoría programa sin tener en cuenta la orientación a objetos a la hora de usar los datos, los cuales se gestionan de forma relacional. El problema de esta arquitectura es que se desaprovechan las grandes ventajas de flexibilidad, facilidad de mantenimiento y facilidad de gestión de sistemas complejos que brinda la programación orientada a objetos. Asimismo, el código que opera con datos relacionales suele ser complejo, difícil de mantener y de ampliar y muy dependiente de la estructura de los datos.

20 Bases de datos orientadas a objetos
La opción de que toda la aplicación use un mismo modelo teórico relacional no es la más adecuada. Examinemos ahora la opción en que toda la aplicación tenga un único modelo teórico, pero que éste sea el de orientación a objetos. Esta opción implica que el formato de datos que usa toda la aplicación es el formato de objetos.

21 Bases de datos orientadas a objetos (2)
Para un programa resulta natural trabajar con objetos. Sin embargo, esto es imposible para las bases de datos tradicionales, basadas en el modelo relacional. Para resolver este problema han aparecido las bases de datos orientadas a objetos. Al contrario de sus homólogas relacionales, que trabajan con registros, las bases de datos orientadas a objetos guardan y recuperan objetos.

22 Bases de datos orientadas a objetos (3)
Por lo tanto, la comunicación de este tipo de base de datos con un programa orientado a objetos es posible. Aunque, sobre el papel, ésta es la mejor opción para implementar una aplicación de base de datos, en la práctica presenta una serie de problemas importantes, debido a las características actuales de las bases de datos orientadas a objetos. Éstas no están aún tan maduras como sus homólogas relacionales y, por tanto, no gozan de la abundancia de herramientas, la confiabilidad, facilidad de administración y el rendimiento de éstas.

23 Factores que conducen el diseño de capas de acceso objeto / relacionales
Funcionalidad versus costo. Separación de problemas respecto a costos. Rendimiento Flexibilidad versus confiabilidad. Sistemas del legado histórico. Estilo de la aplicación. Aplicaciones de diseño asistido por computador (CAD). Herramientas CASE.

24 Motores de persistencia
Las opciones basadas en imponer un único modelo teórico a toda la aplicación padecen de graves inconvenientes: En el caso de que toda la aplicación siga el modelo relacional, se pierden las ventajas de la orientación a objetos. En el caso de que toda la aplicación siga el modelo orientado a objetos, se tiene que las bases de datos que deben usarse están inmaduras y tienen un bajo nivel de estandarización. Otra opción es que el programa sea orientado a objetos y la base de datos sea relacional, lo que, en principio, constituye la opción más natural. Esta opción plantea el problema: ¿Cómo se logra que dos componentes con formatos de datos muy diferentes puedan comunicarse y trabajar conjuntamente?

25 Motores de persistencia (2)
La solución es encontrar un traductor que sepa traducir de cada modelo al otro. De esta forma, las dos componentes se entenderán sin necesidad de que uno hable el idioma del otro. Este traductor es un componente de software, una capa de programación, al que se le dan los nombres de “capa de persistencia”, “capa de datos”, “correspondencia O/R” (“OR mapping”) o “Motor de persistencia”.

26 Comentarios El programa sólo ve que puede guardar objetos y recuperar objetos, como si estuviera programado para una base de datos orientada a objetos. La base de datos sólo ve que guarda registros y recupera registros, como si el programa estuviera dirigiéndose a ella de forma relacional. Es decir, cada uno de los dos componentes trabaja con el formato de datos (el “idioma”) que le resulta más natural y es el motor de persistencia el que actúa de traductor entre los dos modelos, permitiendo que los dos componentes se comuniquen y trabajen conjuntamente.

27 Ventajas Esta solución goza de las mejores ventajas de los dos modelos: De una parte, puede programarse con orientación a objetos, aprovechando las ventajas de flexibilidad, mantenimiento y reusabilidad. Por otra parte, puede usarse una base de datos relacional, aprovechándose su grado de madurez y nivel de estandarización, así como las herramientas relacionales creadas. Se calcula que un motor de persistencia puede reducir el código de una aplicación en un 40%, haciéndola menos costosa de desarrollar. Además, el código que se obtiene programando de esta manera es más limpio y sencillo y, por lo tanto, más fácil de mantener y más robusto. Por añadidura, el motor de persistencia no sólo simplifica la programación, sino que permite hacer ciertas optimizaciones de rendimiento que serían difíciles de programar por nosotros mismos. En la actualidad, ésta es la mejor opción para implementar una aplicación.

28 Funcionamiento de la persistencia

29 Opciones para motores de persistencia
Una ventaja del motor de persistencia es que es el mismo para todas las aplicaciones. De esta forma sólo debe programarse una vez y puede utilizarse para todas las aplicaciones que se desarrollen en la empresa. Sin embargo, un motor de persistencia es difícil de programar y de mantener, por lo que necesita un gran esfuerzo en costo y tiempo de desarrollo. Es por ello que hay dos opciones a la hora de emplear un motor de persistencia: Programarlo dentro de la empresa. No es lo más recomendable, por la complejidad y costo que introduce. Utilizar un motor que ya esté programado, comprándolo a un vendedor o bien utilizando un motor gratuito de código abierto. Se recomienda la segunda opción, que es menos costosa y la menos propensa a fallos.

30 Motores de persistencia importantes
A continuación se explican algunos motores de persistencia importantes para la plataforma Java y para la plataforma .NET, con el fin de que pueda investigarse cuál es el que mejor se ajusta a las necesidades específicas. En la plataforma Java, los servidores de aplicaciones basados en la especificación “Enterprise JavaBeans” - EJB, incorporan un motor de persistencia a través del mecanismo conocido como “entity beans”. Sin embargo, los “entity beans” no son un mecanismo de persistencia totalmente recomendable, pues no permiten implementar algunas características de la programación orientada a objetos (por ejemplo, la herencia) y además, obligan a una forma de programar diferente a los objetos normales de Java ( “Plain Old Java Objects” - POJOs).

31 POJO's (Plain Old Java Objects)
Un POJO (acrónimo de Plain Old Java Object) es una clase del lenguaje de programación Java. Este nombre se les da a las clases que no son de algún tipo especial: EJBs, Java Beans, etc; y no cumplen ningún otro rol ni implementan alguna interfaz especial. El término "POJO" es usado principalmente para hablar de un objeto Java que no sigue ninguno de los modelos de objetos, convenciones o frameworks como lo hace EJB. Sin embargo, esta definición es ambigua, considerando los posibles cambios en los modelos y frameworks, y el hecho que esa categorización depende del contexto. En esencia, todos los objetos Java pueden referirse como POJOs. Bajo esta interpretación, las declaraciones que implican POJO deben aplicar a todos los objetos Java sin excepción. Sin embargo, muchos están en desacuerdo con este punto de vista.

32 Framework para Persistencia
¿Qué es un Framework para Persistencia? Un framework para persistencia mueve los datos del programa en su forma mas natural (objetos en memoria) hacia y desde un almacenamiento permanente de datos: la base de datos. El framework para persistencia gestiona la base de datos y el mapeo entre dicha base de datos y los objetos, por lo que debe proporcionar funciones para: Almacenar y recuperar los objetos en un mecanismo de almacenamiento persistente. Confirmar (commit) y deshacer (rollback) las transacciones. Su diseño debe ser extensible, para dar soporte a diferentes mecanismos de almacenamiento: bases de datos relacioneales, registros en archivos simples ó XML.

33 Jerarquía de clases del mecanismo de persistencia

34 Jerarquía de clases de las sentencias SQL

35 Boceto del diseño de una capa de persistencia

36 EJB http://www.javabeat.net/javabeat/ejb3/index.php
Los Enterprise JavaBeans (EJB) fueron introducidos debido a la existencia de componentes construídos distribuidos. Su promesa fue solucionar todas las ediciones y complejidades de CORBA. EJB era el corazón de J2EE y pasó con varias revisiones importantes y consiguió integrarse con muchas características. Cuando llegó, A principios de, la mayor parte de los programadores gustaron de EJB.

37 Enterprise Java Beans (EJBs)
Componente principal del grupo de especificaciones J2EE definidas por Sun. Un Enterprise Java Bean es una componente escrita en el lenguaje de programación Java y ubicada en un servidor donde se encapsula la lógica de negocios de una aplicación. La lógica de negocios es el código que cumple el propósito de la aplicación. Invocando esos métodos, los clientes remotos pueden acceder al inventario de servicios suministrado por la aplicación. A través de ellos se define una estructura ("Framework") en la cual es posible manipular e interactuar con procesos e información que residen en diversos ambientes computacionales, desde "MainFrames" hasta Bases de Datos. Estos componentes (EJB's) contemplan diversas características esperadas de una aplicación empresarial como: Control de Transacciones, Seguridad, Threading, Propagación de Transacciones, y otras funcionalidades. Dichos componentes son ejecutados dentro de un Application Server.

38 Beneficios del uso de EJBs
Simplifican el desarrollo de aplicaciones distribuidas grandes: Dado que el contenedor EJB suministra servicios a nivel de sistema a los enterprise java beans, el desarrollador puede concentrarse en resolver sólo sus problemas de negocios. El contenedor EJB – y no el programador del bean- es responsable por los servicios a nivel del sistema tales como manejo de transacciones y autorizaciones de seguridad. Dado que los beans, no los clientes, contienen la lógica de negocios de la aplicación, el desarrollador del cliente puede enfocarse en el aspeco de la presentación al cliente. No tiene que programar las rutinas que implementan las reglas del negocio ó los accesos a bases de datos. Como resultado, los clientes son livianos, lo que es un beneficio particularmente importante para aplicaciones cliente que se ejecutan en dispositivos pequeños. Dado que los enterprise beans son componentes portables, el armador de aplicaciones puede desarrollar nuevas aplicaciones empleando beans existentes. Esas aplicaciones pueden ejecutarse sobre cualquier servidor que cumpla las especificaciones J2EE, debido a que se emplean las APIs estandarizadas.

39 Cuando es apropiado usar EJBs
Debe considerarse su empleo si la aplicación tiene alguno de los requerimientos siguientes: Escalabilidad. Para acomodar a un número creciente de usuarios puede ser necesario distribuir los componentes de la aplicación entre varias computadoras. Los EJBs pueden ejecutarse en diferentes equipos de manera que resultará transparente a los clientes. Las Transacciones deben garantizar integridad de los datos. Los EJBs soportan transacciones: mecanismos que manejan el acceso concurrente a objetos compartidos. La aplicación tendrá variedad de clientes. Los clientes remotos pueden localizar fácilmente EJBs con pocas líneas de código. Dichos clientes pueden ser livianos, variados y numerosos.

40 Tipos de EJB's. Session EJB's: Permite realizar cierta lógica solicitada por un cliente, ya sea un JSP/Servlet, Applet ó inclusive otro EJB. Existen dos tipos: Stateless (Session) EJB's Statefull (Session) EJB's Entity EJB's: Trabaja conjuntamente con un depósito de información (Base de Datos). Manipula información residente en sistemas ajenos. También existen dos tipos: (Entity) Bean Managed Persistence (Entity) Container Managed Persistence Messaging EJB's: Ofrece las funcionalidades de sistemas "Messaging“: intermediario para recibir y publicar mensajes; que opera en forma asincrónica.

41 Estructura de un EJB Un EJB, con la excepción de los Messaging EJB's, está compuesto por cuatro partes: "Enterprise Bean Class“: Clase donde se encuentran definidas toda las funciones utilizadas por el EJB, sean procedimientos rutinarios o con lógica hacia bases de datos. Aquí reside todo el código funcional que realiza operaciones en Java, desde la activación del EJB hasta su destrucción incluyendo las funciones de negocios para las que fue diseñado. "Home Interface“: Define un esqueleto para funciones utilizadas en la "Enterprise Bean Class“. Sólo contiene las declaraciones para funciones necesarias en la creación-activación del EJB's. "Remote Interface": Contiene las declaraciones para las funciones de negocios definidas en la "Enterprise Bean Class“. Sólo el "esqueleto" de las funciones. El número de declaraciones dependerá de las funciones declaradas en la "Enterprise Bean Class". "Deployment Descriptor“: Archivo en XML que cumple varias funciones: Parametrizar el código Java del "Enterprise Bean Class“: definir parámetros que varían dependiendo del ambiente. Indica al "EJB Container": el tipo de EJB - Session, Entity, Messaging - ; el esquema de seguridad que posee; y en caso de ser un "Container Managed Entity EJB“: las funciones para las que se generará lógica; así como otras funcionalidades.

42 Manejo de excepciones Las excepciones lanzadas por los EJBs pueden ser: System exception: indica un problema con los servicios que sustentan la aplicación. Application exception: Señala un error en la lógica de negocio del bean.

43 Excepciones del paquete javax.ejb
Method Name Exception It Throws Reason for Throwing ejbCreate CreateException Parámetro de entrada no válido. ejbFindByPrimaryKey (y cualquier otro método buscador find* que devuelva un objeto simple.) ObjectNotFoundException (subclase de FinderException) The database row for the requested entity bean cannot be found. ejbRemove RemoveException The entity bean's row cannot be deleted from the database. ejbLoad NoSuchEntityException The database row to be loaded into the entity bean cannot be found. ejbStore The database row to be updated cannot be found. (todos los métodos) EJBException Se encontró un problema en el sistema.

44 Session EJB's (Stateful y Stateless)
Ciclo de Ejecución Estructura y Componentes Adicionales. Codificación del EJB. Codificación del Cliente para EJB. Ejemplos: TimerSessionBean: Stateless session bean que establece un ”timer”. HelloServiceBean: Stateless session bean que implementa un servicio Web. CartBean: Stateful session bean que es accedido por un cliente remoto.

45 Ciclo de Ejecución

46 Estructura y Componentes Adicionales
La estructura básica de EJB's es sólo una parte necesaria para la ejecución exitosa de un EJB. otros componentes necesarios: Stubs y Skeletons Librerías (JAR's) Propietarias Codificación de un Session (Stateless) EJB.

47 Stubs La comunicación entre el cliente y el "EJB Container" se lleva a cabo mediante procedimientos remotos (vía RMI/IIOP), lo que implica que tanto el cliente como el "EJB Container" pueden residir en distintos "Hosts“. De aquí surge una pregunta clásica en ambientes distribuidos: ¿Cómo sabe el cliente la definición del EJB? ¿Cómo sabe que métodos llamar? La manera en que el cliente se entera de esto es a través de un Stub. Un Stub proporciona una estructura al cliente que describe los elementos definidos en Servidor, en este caso el EJB. Este Stub es generado por una herramienta proporcionada por el Application Server quien debe estar accesible al Cliente que intenta comunicarse con el "EJB"/Application Server.

48 Skeletons El Skeleton es la contra parte del Stub que reside en el Servidor. Para efectos de EJB's, este componente es llevado a cabo a través del "Home Interface" y "Remote Interface". Aunque es importante conocer el uso de Stubs y Skeletons en EJB's, generalmente la comunicación entre el Cliente y EJB es llevada automáticamente y sin mayor preocupación debido a que tanto el "EJB Container" y "Servlet Container" se encuentran en la misma estructura del Application Server y por ende en el mismo "Host". Uno de los casos donde resulta crítico tomar en consideración el uso de Stubs y Skeletons es cuando se posee un ambiente de Cluster, lo cual implica que existe comunicación entre diversos Application Servers en diversos "Hosts".

49 Librerías (JAR's) Propietarias
Además de estos Stubs y Skeletons, también existen diversas librerías que son proporcionadas en los diferentes Application Servers. Estas librerías (Archivos JAR) deben estar accesibles al Cliente o Servidor según lo requiera el servidor.

50 Entity Beans Existen dos tipos de Entity EJBs denominados
Bean Managed Persistence - BMP y Container Managed Persistence - CMP La diferencia entre ambos estriba en la manera en que se accede a la información residente en la Base de Datos. En Bean Managed Persistence - BMP es necesario escribir toda la lógica de acceso para la Base de Datos. Esta lógica escrita a través del API JDBC implica contemplar diversos aspectos de codificación como parámetros, variables, algoritmos, y otros detalles. Si el EJB realiza interacciones complejas con la Base de Datos, este código no sólo puede ser complejo de escribir, sino difícil de mantener actualizado.

51 Mapeo Objeto Relacional
Para proyectos pequeños de EJB's, el mapeo Objeto Relacional puede ser realizado directamente por un programador. Para proyectos de gran tamaño, esto puede resultar incosteable e ineficiente. Hoy día existen varios productos que realizan este mapeo rápida y eficientemente, además de ofrecer otras funcionalidades como "Cache's", "Pooling" hacia la Base de Datos y otros mecanismos más. Actúan como una capa adicional entre el Application Server/"EJB Container" y la Base de Datos.

52 Ciclo de ejecución de un “entity bean”
El ciclo de ejecución para un Entity EJB debe interactuar con un depósito de Información ajeno al Application Server, típicamente una Base de Datos.

53 Entity EJBs: BMP En Bean Managed Persistence - BMP es necesario escribir toda la lógica de acceso para la Base de Datos. Esta lógica escrita a través del API JDBC implica contemplar diversos aspectos de codificación como parámetros, variables, algoritmos, y otros detalles. Si el EJB realiza interacciones complejas con la Base de Datos, este código no sólo puede ser complejo de escribir, sino difícil de mantener actualizado.

54 BMP "Bean Managed Persistence"
Definiciones en Bases de Datos. Creación de Interfases ("Home Interface" y "Remote Interface"). Creación del EJB. Deployment Descriptor del EJB. Creación del Cliente (JSP/Servlet).

55 Entity EJBs: CMP En Container Managed Persistence – CMP, la lógica de acceso hacia la Base de Datos es generada por el EJB Container del Application Server. Este mecanismo tiene sus desventajas comparado con un BMP: El primer aspecto, que es la ventaja de generar código automático, es balanceado por la necesidad de contemplar y conocer a detalle configuraciones del Application Server requeridas para emplear al CMP. La otra desventaja es que como el código es generado automáticamente, no existe la posibilidad de afinarlo. El que sea generado código JDBC no implica que ha sido utilizado el mejor algoritmo para el trabajo.

56 CMP "Container Managed Persistence"
SuperClase/SubClase, "Abstract Schema" y EJB-QL. Creación de Interfases ("Home Interface" y "Remote Interface"). Creación del EJB. Deployment Descriptor del EJB. Creación del Cliente (JSP/Servlet).

57 Comparación de tipos de Entity Beans
En Container Managed Persistence – CMP, la lógica de acceso hacia la Base de Datos es generada por el EJB Container del Application Server. Este mecanismo tiene sus desventajas comparado con un BMP: El primer aspecto, que es la ventaja de generar código automático, es balanceado por la necesidad de contemplar y conocer a detalle configuraciones del Application Server requeridas para emplear al CMP. La otra desventaja es que como el código es generado automáticamente, no existe la posibilidad de afinarlo. El que sea generado código JDBC no implica que ha sido utilizado el mejor algoritmo para el trabajo.

58 Capa de Persistencia EJB
Esta capa implementa el modelo de datos de la aplicación Las componentes introducidas en la sección de Modelo de Datos son implementados con “entity beans” usando tecnología Enterprise JavaBeans (EJB) 3.0. EJB version 3.0 presenta una nueva API de Persistencia Java. Simplifica y estandariza el mapeo objeto-relacional.

59 Capa de Persistencia (2)
EJB3.0 hace que las aplicaciones sean independientes de las especificaciones de requerimiento de mapeo. El desarrollador puede ó usar anotaciones o descriptores XML para especificar la información de mapeo objeto-relacional. La especificación EJB 3 proclama un modelo programación POJO y describe los beans de sesión EJB 3 como POJOs, aunque usualmente requieren anotaciones. Los entity beans son POJOs (Plain Old Java Objects) anotados con metadata. Estos pueden ser serializados y distribuidos siempre a través de la red en un ambiente que no toma conciencia de la persistencia (persistence-unaware). Como consecuencia de este cambio se hacen obsoletos los objetos para transferencia de datos (Data Transfer Objects - DTOs).

60 Desacople de impedancia
Una consideración muy importante y en ocasiones no contemplada lo suficiente en desarrollos de "Entity EJB's", es la discrepancia que existe del mundo Java (Objetos) al mundo de Base de Datos (Relacional). Sabemos que el problema que surge al interactuar Objetos (Java) con Bases de Datos (Relacionales) es que no existe un mapeo directo entre ambos: es posible que un Objeto compuesto por diversos valores requiera interactuar con dos o tres tablas relacionales para lograr el comportamiento deseado. Esta discrepancia entre el mundo de Objetos (Java) y el relacional (SQL) también es conocida como Desacople de Impedancia (Impedance Mismatch).

61 Localización Cuando se interactúa con depósitos de información mediante EJBs , debe considerarse: Al crearse un EJB para manipular información residente en Bases de Datos, se trae una copia de ésta al EJB. Dicha información puede variar desde datos personales, cuentas bancarias o cualquier otro tipo que sea conveniente persistir a través del tiempo. Es aquí donde se hace más clara la necesidad de localización. Cuando el cliente (JSP/Servlet) genera un “entity EJB”, éste seguramente volverá hacer uso del EJB. Tomando el caso de una cuenta bancaria, el cliente puede invocar una operación sobre la información de "x" cuenta. Si posteriormente se deseara invocar otra operación sobre estos datos, no sólo sería excesivo volver a extraer la información de la Base de Datos, sino ilógico, puesto que ya están en el "EJB Container“ del Application Server.

62 Localización (2) La manera en que son re-localizados EJBs ya creados es a través de métodos de búsqueda, denominados finder methods. Estos finder methods pueden ser de cualquier tipo imaginable ya que son diseñados por el creador del EJB, dependiendo de la información estos pueden ser: findEnRango, findByPrimaryKey, findPorApellido, etc. El vocablo find es utilizado como una convención para distinguir su uso. Estos métodos son declarados en el Home Interface del EJB.

63 Sincronización La sincronización de información entre el EJB y el depósito de información es otra propiedad de un Entity EJB. Su importancia se debe a las características de los datos residentes en Bases de Datos. Regresando al caso de una cuenta bancaria: si esta información es manipulada a través de un EJB, es de suma importancia que sea sincronizada con aquella de la Base de Datos. Suponga que el EJB deduce "x" cantidad de dinero a una cuenta, debido a que es posible que la información residente en una Base de Datos sea manipulada por otro sistema (Sucursal o Cajero automático), es conveniente sincronizar de inmediato este tipo de operaciones para asegurarse que el juego de datos en el EJB no ha cambiado respecto al depósito central. Este mismo caso se puede suscitar si después de un lapso extenso de tiempo se desea manipular un Entity EJB. En este caso, siempre es conveniente re-cargar (sincronizar) la información del EJB con aquella de la Base de Datos para asegurarse que no ha cambiado desde la creación inicial del EJB.

64 ¿Cuando y quién invoca ejbStore y ejbLoad?
Sincronización (2) La sincronización de información se lleva acabo a través de dos métodos que deben ser implementados en todo Entity EJB: ejbLoad y ejbStore. ejbLoad es utilizado para traer información del depósito hacia el EJB y ejbStore es para llevar los datos del EJB hacia la Base de Datos. ¿Cuando y quién invoca ejbStore y ejbLoad? Las dos situaciones obvias son al crear y al destruir el “Entity EJB”. Sin embargo, ambos también pueden ser invocados al realizarse una manipulación crítica como las mencionadas anteriormente. En este caso, el llamar estos métodos es un tema fuertemente relacionado con Transacciones en EJB's. Finalmente cabe mencionar que un cliente (JSP/Servlet) jamás invoca estos métodos directamente, sino que la tarea es delegada al Application Server para ser invocados según se hayan definido las transacciones correspondientes.

65 Consideraciones sobre los CMP
El surgimiento de CMP Entity Beans, además de la generación del código automático de acceso (JDBC), tiene sus raíces en las diversas empresas que apoyan EJBs, específicamente aquellas que desarrollan EJBs para terceros: Independent Software Vendors – ISV: Una empresa que ha desarrollado un "proceso lógico" en Entity EJBs lo suficientemente productivo que decide comercializarlo a otras empresas en el ramo. En este caso, la portabilidad de Java hacia diversos Application Servers no es suficiente, por la simple razón de que Usted no sabe como está definido el modelo de datos en otras empresas.

66 Consideraciones sobre los CMP (2)
Una solución a este problema sería distribuir el código fuente de cada Entity EJB para ser modificado. Sin embargo, esto no sólo daría acceso total a un proceso que pudo costar miles de dólares en refinar, sino que también haría difícil el actualizar dichos Entity EJBs en versiones futuras debido a la falta de control sobre el código fuente. A través de los CMP Entity Beans es posible dividir efectivamente la lógica de negocios del EJB del acceso al depósito de información, ofreciendo la posibilidad de distribuir binarios de EJBs con la facilidad de definir acceso a Bases de Datos transparentemente. Sin embargo, esta transparencia no es del todo gratis.

67 SuperClase / SubClase La primera distinción entre un BMP y un CMP Entity Bean es que la clase principal del EJB en sí (aquella que contiene la implementación) está subdividida en dos: una SuperClase definida por el programador del EJB y una SubClase que es generada por el EJB Container del Application Container.

68 Esquema abstracto La generación de código automático para acceder al deposito de información debe surgir de ciertas definiciones forzosamente, puesto que: ¿Cómo sabrá el Application Server / EJB Container que la función insertarSaldo es distinta de insertarNombre o que la función cuentaBancaria se refiere a la tabla llamada tarjetahabientes? Esta tarea recae sobre lo que es conocido como Esquema Abstracto (Abstract Schema).

69 EJB-QL Ejemplo de "Abstract Schema" visto desde un alto nivel
La última diferencia entre CMP y BMP se debe a una cualidad especifica de un Entity EJB: los métodos de búsqueda. Al implementarse estos métodos de búsqueda en BMP se define la lógica directamente. Sin embargo, surge la misma incógnita mencionada anteriormente: ¿Cómo sabe el Application Server / EJB Container que significa findPorApellido o findByPrimaryKey ? Para esto se utiliza el "Enterprise Java Bean-Query Language“(EJB-QL). Ejemplo de "Abstract Schema" visto desde un alto nivel

70 Evolución de EJB EJB 1.* BMP: CMP: EJB 2.0 BMP: CMP:

71 EJB – CMP 1.0 para la tabla Autores de la base de datos books

72 EJB – CMP 1.0 para la tabla Autores de la base de datos books (2)
Diagrama de Componente

73 EJB generados por NetBeans 5.5 para la base de datos books

74 Diagrama de clases obtenido por ingeniería inversa

75 Fragmento del EJB generado por NetBeans 5
Fragmento del EJB generado por NetBeans 5.5 para la tabla Autores de books

76 Otros Motores de Persistencia
Oracle TopLink BEA Kodo Hibernate

77 Oracle Toplink Oracle TopLink es una arquitectura de persistencia que permite manejar el mapeo. Utilizándola, pueden construirse rápidamente aplicaciones que combinan el mejor aspecto de tecnología de objetos y las bases de datos relacionales. Motor de persistencia asumido en NetBeans 5.5

78 BEA Kodo Mapping Object-Relational provee persistencia para aplicaciones Java empresariales y servicios.

79 Hibernate Es una herramienta “open source” que provee Persistencia objeto/relacional y servicios de consulta. Hibernate se sitúa entre la aplicación y la base de datos, y objetos cargados y almacenados, asistiéndolo con la persistencia y administración de contenidos.

80 Transacciones Omitiendo detalles, una Transacción es la acción que permite que: No sea enviado un producto hasta que haya sido actualizado el Inventario del mismo. Al intentarse abonar "x" cantidad de dinero, ésta no sea realizada hasta que se haya realizado la respectiva deducción de otra cuenta. Actualizar diversos depósitos de información al mismo tiempo. Etc.

81 Transacciones (2) En términos más triviales: una transacción representa un todo o nada, es decir, o se realizan todos los pasos definidos en ella o no se realiza ninguno. En un EJB, las transacciones son definidas en el Descriptor de despliegue (Deployment Descriptor) para cada método a ser ejecutado. Esto permite que si ocurre algún error ("Exception") dentro del método, todas sus acciones sean invalidadas. Esto es conocido como "Rollback". Por lo general todas las transacciones en un EJB son definidas a través del parámetro REQUIRED. Esto implica que al invocarse el método, se inicie una transacción exclusiva para éste. Definir una transacción como REQUIRED es una manera muy segura de mantener la integridad de información.

82 Otros parámetros para transacciones
Una transacción puede recibir otros parámetros: REQUIRESNEW: Este tipo de parámetro permite al método en cuestión crear una transacción exclusiva. Al utilizarse REQUIRED, si ya existe una transacción de por medio y ocurre un error ("Exception") todas las operaciones tanto del método en cuestión así como las del que inicio la transacción serán retractadas ("Rolledbacked"). Al utilizarse REQUIRESNEW se evita este comportamiento "anidado" de transacciones. SUPPORTS: Esta transacción permite al método del EJB participar en una transacción siempre y cuando el cliente ( JSP/Servlet/Applet ) la haya iniciado, de otra manera no participa en ninguna transacción. MANDATORY: A través de MANDATORY se le indica al método que debe existir transacción en progreso. Si no existe, el "Application Server/EJB Container" genera un error (javax.ejb.TransactionRequiredException) NOTSUPPORTED: Indica que el método no participará en ninguna transacción. Dado el caso de encontrarse una transacción en progreso, será suspendida y reanudada una vez que el método sea invocado. NEVER: Permite que un método jamás participe en una transacción. Inclusive, si el cliente (JSP/Servlet) llama este tipo de métodos cuando esta en proceso una transacción, se genera un error. El uso de cualquiera de los parámetros anteriores para Transacciones en EJBs no se recomienda al menos que haya sido realizado un análisis exhausto acerca de sus consecuencias en el EJB.

83 Operaciones de transacción
Una transacción es una unidad de trabajo - conjunto de tareas- que deben completarse con éxito ó no se debe realizar ninguna, por tanto, una transacción es atómica: indivisible. Comúnmente termina mediante las operaciones confirmar (commit) ó deshacer (rollback) Las tareas de una transacción pueden incluir inserción, actualización, eliminación de objetos y combinaciones de estas operaciones, que pueden ser solicitadas en cualquier orden. Esto conduce al patrón GoF Command: Defina una clase por cada tarea que implementa una interfaz común.

84 Transacciones y JTS/JTA
Las transacciones juegan un papel muy importante en cualquier sistema de cómputo y en EJBs no son la excepción. A través de transacciones es posible garantizar la integridad de ciertas operaciones llevadas acabo en un sistema. Esta integridad es la parte fundamental ofrecida por una base de datos también denominada prueba del "ACIDo" (Atomicity-Consistency-Isolation-Durability). Sun define las especificaciones para el servicio de transacciones (Java Transaction Service - JTS) y para la interfaz del programador de aplicación (Java Transaction API - JTA).

85 JTS/JTA Java Transaction Service - JTS y Java Transaction API - JTA son un juego de librerías ("packages") utilizadas en el lenguaje Java para definir manualmente el uso de transacciones en los programas. JTS es el API utilizado por los diversos vendedores. Éste es rara vez utilizado por un programador al diseñar aplicaciones. JTA puede ser empleado para definir transacciones en cualquier programa Java. Sin embargo, su uso para aplicaciones de EJBs y sus clientes (JSP/Servlets) es fuertemente desanimado. Lo anterior se debe que al ser definida una transacción manualmente se pueden generar resultados inesperados, que varían desde operaciones congeladas ("deadlocks") hasta los efectos de propagación que pueda tener la transacción en todo el sistema. Además: ¡Se estaría dando un paso atrás en el mundo de EJBs!, puesto que la intención de los EJBs es precisamente el ahorro de escribir este tipo de código complejo ("Middleware").

86 Java Persistence API - JPA
FAQs Wikipedia – Java Persistence API Introduction to Java Persistence API (JPA) (OJO:-) JavaBeat: Cuando se afirma que JPA sigue el estándar POJO, se afirma que las entidades (entity classes) son clases Java regulares y normales, en el sentido de que no necesitan extender o implementar ninguna clase especializada. Plain Old Java Object (POJO) es un término utilizado para referirse a objetos Java que ni extienden ni implementan a alguna clase especializada. POJO+Persistence

87 Motores de persistencia más completos
Hay motores de persistencia más completos que no tienen este tipo de inconvenientes. Entre los de código abierto destacan: Hibernate, Relational Persistence for Java and .NET OpenEJB Castor, Apache Mapeador objeto-relacional para Java Torque, Apache ObJectRelationalBridge OJB y Apache Object Relational Mapping, Persistence and Caching for Java, Cayenne. Entre los comerciales destacan: TopLink de Oracle (asumido en NetBeans 5.5), Cocobase y GENOME O/R mapper for .NET

88 Especificación JDO En los últimos años se ha creado una especificación llamada Objetos de Datos Java (“Java Data Objects” – JDO), para estandarizar la forma de programar en Java y también en C# con los motores de persistencia. Ejemplos de motores de persistencia que cumplen el estándar JDO son: Comerciales: BEA Kodo, Versant FastObjects .NET y Versant Object Database (incluye JDO Genie), LiDo (Xcalia Dyamic Data Integration Software), Exadel JDO, y Signsoft GmbH IntelliBO. Código abierto: Tri Active JDO (TJDO) y XORM.

89 Plataforma .NET Debido a su relativa novedad, el desarrollo de motores de persistencia está menos maduro con respecto a los desarrollos existentes para la plataforma Java. Además, al ser una plataforma propietaria, es difícil encontrar proyectos de código abierto para ella. Por tanto, no hay tanta variedad de motores de persistencia en esta plataforma. Microsoft posee un motor de persistencia para .NET llamado ObjectSpaces embebido dentro de Visual Studio 2005. También puede usarse ORM.NET, un motor de persistencia no comercial para .NET. Profundizaremos el acceso a objetos de datos de .NET posteriormente en este curso.

90 Ejercicios Aplicación clásica, maneja conexión a BD mediante JDBC: BooksClasic Aplicación utilizando persistencia manejada mediante Entity Classes: BooksApp Manejo de persistencia empleando Hibernate. Ejemplo de uso de BEA KODO para resolver la persistencia.

91 Referencias Motores de Persistencia
Persistencia de Objetos Java Utilizando JDO PRB: Modelo de persistencia de objetos COM de SQL Server Connolly, T.M. & Begg, C.E. “Sistemas de Bases de Datos” 4ta ed. Pearson Addison Weasley, 2005, Caps. 25 al 30 pp Larman, C. “UML y Patrones” 2da ed. Pearson Prentice Hall, 2004, Cap. 34 pp Deitel, H.M. & Deitel, P.J. “Java: Cómo Programar” 5ta ed. Pearson Educación, 2004, Caps. 23 al 25 pp Persistence Options for Object-Oriented Programs Object/Relational Access Layer Patterns Java Persistence API Java Transaction API (JTA) Java Transaction Service (JTS)

92 Mapeo Objeto-Relacional
Object-relational mapping Object Relational Mapping Techniques for Successful Evolutionary/Agile Database Development: Mapping Objects to Relational Databases: O/R Mapping In Detail The Object-Relational Impedance Mismatch Object Relational Tool Comparison Object Relational Tool Comparison in .NET Core J2EE Design Pattern: Data Access Objects Patterns for Object / Relational Mapping and Access Layers (:-) Choosing an Object-Relational mapping tool JDBCPersistence Fast ORM for Java O/R Mapping Products

93 Herramientas Java Data Objects (JDO)
Introduction to Java Data Objects (JDO) Enterprise Java Bean (EJB) JavaEE5 Tutorial - Part 3 Oracle TopLink BEA Kodo™ 4.1 SAP NetWeaver Application Server, Java EE 5 Edition Apache OpenJPA GlassFish Java Persistence API Reference Implementation, TopLink Essentials Hibernate: Relational Persistence for Java and .NET (JBoss) Descarga

94 Herramientas (2) Foundations of Object-Relational Mapping - ChiMu Corporation Mapping tools for .NET: SharpToolbox' Object-Relational Mapping category Mapping tools for Java: JavaToolbox' Object-Relational Mapping category Tools to handle persistence and data access layers for .NET: SharpToolbox' Persistence - Data-tier category General code generation tools for .NET SharpToolbox' Code Generation category Ways to see data from an application developer's perspective - Frans Bouma A First Look at ObjectSpaces in Visual Studio 2005 Introduction to ObjectSpaces

95 Ejemplos en NetBeans 5.5 Using Hibernate With the NetBeans Visual Web Pack Creating a Simple Web Application in NetBeans IDE Using MySQL Connecting to a MySQL Database in NetBeans IDE EJB Technology and Java Persistence: Java Persistence Using Java Persistence in a J2EE 1.4 Web Application Using Hibernate as the Persistence Manager for an Application EJB 3.0 Enterprise Beans CMP Mapping in J2EE 1.4 Applications Testing EJB 2.0 Enterprise Beans in NetBeans IDE