Transcript Persistencia

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
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
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:
1. 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.
2. 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
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
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
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:
1. Autores
2. Editoriales
3. Títulos
4. ISBNAutor
Autores
1
idAutor
nombrepila
apellidopaterno
Títulos
ISBNAutor
8
idAutor
Editoriales
Relación entre ellas:
idEditorial
idEditorial
1
8
nombreEditorial
titulo
numeroedicion
ion
copyright
8
isbn
•
isbn
1
ArchivoImagen
precio
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
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
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
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
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
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
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
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
Dr. Juan José Aranda Aboy
aplicación.
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:
1. Programarlo dentro de la empresa. No es lo más recomendable,
por la complejidad y costo que introduce.
2. 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
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
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
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
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
Tipos de Entity Beans
•
•
•
Existen dos tipos de Entity EJBs denominados
1. Bean Managed Persistence - BMP y
2. 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
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
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
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
Evolución de EJB
EJB 1.*
EJB 2.0
BMP:
BMP:
CMP:
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
Fragmento del EJB generado por NetBeans
5.5 para la tabla Autores de books
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
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-IsolationDurability).
• 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
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
• Java Persistence API
– 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
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
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
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
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/ObjectRelational_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
• 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
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
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
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