Aspectos Avanzados de la Tecnología de Objetos 6. Objetos y componentes de software: Persistencia en el modelo de objetos. (1ra parte) Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy Contenidos Bases de datos orientadas a objetos. Motores de persistencia. Opciones. Estándares de objetos de datos: Patrones utilizados para resolver el Modelo de Negocio y su Acceso Patrones utilizados para resolver el Mapeo de la Persistencia Patrones utilizados para resolver la Arquitectura de la Persistencia Patrones utilizados para resolver el Comportamiento de la Persistencia Dr. Juan José Aranda Aboy

Objetivos específicos Describir la correspondencia (mapping) objeto – relacional. Conocer y aplicar apropiadamente los patrones utilizados. Emplear apropiadamente los motores de persistencia. Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy 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. Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy 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. Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy 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. Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy 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. Dr. Juan José Aranda Aboy

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 Dr. Juan José Aranda Aboy

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. Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy 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. Dr. Juan José Aranda Aboy

Diseño relacional del modelo conceptual de la base de datos books Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy Diseño orientado a objetos del modelo conceptual de la base de datos books Dr. Juan José Aranda Aboy

Diagrama de clases generado por NetBeans 5.5 Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy Diagrama de clases … (2) Dr. Juan José Aranda Aboy

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í. Dr. Juan José Aranda Aboy

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. Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy 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. Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy 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. Dr. Juan José Aranda Aboy

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. Dr. Juan José Aranda Aboy

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. Dr. Juan José Aranda Aboy

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. Dr. Juan José Aranda Aboy

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? Dr. Juan José Aranda Aboy

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”. Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy 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. Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy 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. Dr. Juan José Aranda Aboy

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. Dr. Juan José Aranda Aboy

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). Dr. Juan José Aranda Aboy

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. Dr. Juan José Aranda Aboy

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). Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy 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. Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy 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. Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy 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. Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy 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. Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy Tipos de 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. Dr. Juan José Aranda Aboy

Tipos de Entity Beans (2) 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. Dr. Juan José Aranda Aboy

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. Dr. Juan José Aranda Aboy

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. Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy 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. Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy 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). Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy EJB-QL 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 Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy Evolución de EJB EJB 1.* BMP: CMP: EJB 2.0 BMP: CMP: Dr. Juan José Aranda Aboy

EJB – CMP 1.0 para la tabla Autores de la base de datos books Dr. Juan José Aranda Aboy

EJB – CMP 1.0 para la tabla Autores de la base de datos books (2) Diagrama de Componente Dr. Juan José Aranda Aboy

EJB generados por NetBeans 5.5 para la base de datos books Dr. Juan José Aranda Aboy

Diagrama de clases obtenido por ingeniería inversa Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy Fragmento del EJB generado por NetBeans 5.5 para la tabla Autores de books Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy 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. Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy 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. Dr. Juan José Aranda Aboy

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. Dr. Juan José Aranda Aboy

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). Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy 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"). Dr. Juan José Aranda Aboy

Java Persistence API - JPA FAQs Wikipedia – Java Persistence API Introduction to Java Persistence API (JPA) (OJO:-) JavaBeat: http://www.javabeat.net/ 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 Dr. Juan José Aranda Aboy

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, Cocobase y GENOME O/R mapper for .NET Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy 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. Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy 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. Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy 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 729-1034 Larman, C. “UML y Patrones” 2da ed. Pearson Prentice Hall, 2004, Cap. 34 pp 501-527 Deitel, H.M. & Deitel, P.J. “Java: Cómo Programar” 5ta ed. Pearson Educación, 2004, Caps. 23 al 25 pp 1073-1189 Persistence Options for Object-Oriented Programs Object/Relational Access Layer Patterns Java Persistence API Java Transaction API (JTA) Java Transaction Service (JTS) Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy Persistence Concept: The ability of the programmer to have her/his data survive the execution of a process, in order to eventually reuse it in another process. Persistence should be orthogonal, i.e., each object, independent of its type, is allowed to become persistent as such (i.e., without explicit translation). It should also be implicit: the user should not have to explicitly move or copy data to make it persistent. Dr. Juan José Aranda Aboy

Object-relational impedance mismatch http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch Examples of mismatch problems http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx Microsoft's recent announcement regarding "entity support" in ADO.NET 3.0 and the acceptance of the Java Persistence API as a replacement for both EJB Entity Beans and JDO: The ADO.NET Entity Framework Overview ADO.NET team blog Dr. Juan José Aranda Aboy

Persistence Framework What is Persistence Framework? A persistence framework moves the program data in its most natural form (in memory objects) to and from a permanent data store the database. The persistence framework manages the database and the mapping between the database and the objects. There are many persistence framework (both Open Source and Commercial) in the market. Persistence framework simplifies the development process. Dr. Juan José Aranda Aboy

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 Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy Tools 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 Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy Tools (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 Dr. Juan José Aranda Aboy

Dr. Juan José Aranda Aboy NetBeans 55 examples Using Hibernate With the NetBeans Visual Web Pack http://www.netbeans.org/kb/55/vwp-hibernate.html Creating a Simple Web Application in NetBeans IDE Using MySQL http://www.netbeans.org/kb/55/mysql-webapp.html Connecting to a MySQL Database in NetBeans IDE http://www.netbeans.org/kb/55/mysql.html EJB Technology and Java Persistence: Java Persistence 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 Dr. Juan José Aranda Aboy