Ir al contenido principal

DataNucleus Parte 5 - Persistence API FAQ

Como complemento a los factores antes mencionados para tener en cuenta a la hora de elegir su API de persistencia, se ha hablado mucho FUD en la web acerca de JDO y JPA, en gran parte perpetrados por los vendedores de RDBMS, y ofrecemos un FAQ que corrige muchos de estos puntos para que pueda basar su decisión sobre lo que es mejor para usted.

Q: ¿Cuál fue la especificación original?

JDO fue la primera especificación java de persistencia, empezando en 1999, y la especificación JDO 1.0  se publico en  Abril 2002. Este proveía la API de persistencia y fue estandarizada como JSR012. En mayo 2006 JDO2 fue liberada. Esta proveía una actualización de la API de persistencia así como una buena definicion de ORM, estandarizada como JSR243. Mas trde en Mayo 2006 JPA1 fue liberado. Este preveía una API de persistencia, y una lmitación de ORM, concetrada solamente en DBMS, y fue estandarizada como JSR220.  

 Q: ¿Por qué se crea JPA cuando ya teníamos JDO para persistencia en JAVA?

Política. Proveedores RDBMS al parecer no le gustaba la idea de tener una tecnología que permitía a los usuarios aprovechar una sola API, y cambiar fácilmente a otro tipo de almacén de datos. Mucha presión se aplicó sobre SUN para proporcionar una especificación diferente, e incluso para tratar de decir que la JPA sustituyera a JDO. 

Q: ¿Está JDO muerto?
No. SUN donó JDO a Apache para desarrollar más la tecnología. Ha habido las siguientes modificaciones a las especificaciones JDO2;

  •  JDO2.1 agregando soporte para annotations, enums, y algunos conceptos JPA.
  • JDO2.2 añadiendo soporte para buscar grupos dinámicos, de aislamiento de transacción y de control de caché.
  • JDO3.0 añadiendo MetaData / Enhancer APIs, así como tiempo de espera de consulta y cancelar consulta, etc.
Además, JDO3.1 está en marcha, añadiendo soporte para más métodos JDOQL, así como el control de posición de una columna, el tamaño de una secuencia, etc.
Q: JPA reemplazará ha JDO ? 
Es muy difícil que suceda ya que JPA no ofrece nada para hacer frente a la persistencia de objetos Java a almacenes de datos  que no sean RDBMS (LDAP, ODBMS, XML, ODF, Excel, etc). Ni siquiera dar una definición completa de ORM, por lo que todavía no puede competir con el manejo de ORM JDO. Incluso en JPA2 (final a finales de 2009) todavía hay conceptos básicos ORM que no son manejados por JPA, todavía JDO estandariza ellos. JDO aún está en desarrollo, y mientras los usuarios requieran esta tecnología va a seguir existiendo. DataNucleus seguirá apoyando a los APIs ya que existe una necesidad en las aplicaciones de las empresas modernas, a pesar de lo que Oracle, IBM, y otros tratan de imponer a usted. 
Q: ¿Qué diferencia hay entre como se desarrolla JDO y como se desarrolla JPA?
JPA se desarrolla en privado por un "grupo de expertos". JDO se desarrolla en público por cualquier persona interesada en la tecnología. Las pruebas para verificar el cumplimiento de JPA sólo están disponibles después de firmar acuerdos de confidencialidad con SUN y este proceso puede tardar hasta 3 meses para obtener la serie de pruebas. Las pruebas para verificar el cumplimiento de JDO son de descarga gratuita y se puede ejecutar por los usuarios o desarrolladores. Esto significa que cualquiera puede comprobar si una aplicación es compatible con JDO, mientras que no es lo mismo en el caso de JPA. DataNucleus ejecuta el JDO3 y JPA1 TCKs a intervalos frecuentes y publicar los resultados en nuestra página web.
 Q: ¿Por qué yo debería usar JDO, sí JPA esta soportada por grandes organizaciones?
Por "las grandes organizaciones" que supuestamente significa que las organizaciones comerciales como Oracle, IBM, RedHat. Y tienen sus propios intereses creados en las tecnologías de RDBMS, o en la venta de servidores de aplicaciones. Usted debe tomar sus propias decisiones. Su solicitud será apoyada por usted, no por ellos. La tecnología que se utiliza debe ser la mejor para el trabajo y con la que se siente más cómodo. Si usted se siente más cómodo con JPA y ofrece todo lo que su aplicación necesita y utiliza, uselo. Del mismo modo, si JDO ofrece lo que usted necesita, entonces usa JDO. Por esta razón DataNucleus ofrece soporte para las dos especificaciones. 
 

Comentarios

Entradas más populares de este blog

Emprendiendo en la Nube - Arquitectura y Patrón de Diseño

Arquitectura Java para Desarrollo con GAE y GWT Soñando con el trabajo ideal, el cual sería ganar dinero por investigar, pues es lo que me gusta y  divierte, decidí emprender con una startup Tecnológica que pretende hacer de los lugares desconocidos y preciosos en lugares conocidos y visitados. Para  desarrollar una startup que pretende tener repercusión mundial, se necesita ser ordenado desde un principio, la arquitectura de software y el marco de trabajo en el proyecto es tu primera valla a superar. No pretendo criticar el desarrollo ágil por la poca documentación que genera, pienso que deberíamos tomar sus técnicas enriquecedoras, por eso combino el desarrollo clásico con el desarrollo ágil. Ahora ustedes se preguntarán por qué hablo de desarrollo ágil y clásico, si el título dice “Arquitectura Java para Desarrollo con GAE y GWT”, pues tiene mucha relación, pues los desarrolladores estamos acostumbrados a tomar  frameworks y buenas prácticas de diseño y desarrollo para a

INSTALACION DE ORACLE 12C EN CENTOS 7 PARTE 2-3 ARRANQUE AUTOMATICO ...

Extendiendo espacio de la partición raíz en linux en particiones estándar KVM - Debian 10

Ojo pestaña y ceja: Cuando realizas particiones estandar en Linux, la última partición que debes agregar es la raíz y esta debe ocupar los últimos sectores del disco. Esto porque cuando quieras extender la raíz(/) no te dará dolores de cabeza. Aquí un ejemplo en KVM /dev/vda1 swap 8G /dev/vda2 /boot 1G /dev/vda3 / 11G Extendiendo un disco virtual en qemu para KVM * Clonar KVM virt-clone --original vm_debian10_t2micro_ps --name vm_debian10_t2micro_servercapedwarf_one --file /opt/images/debian10_capedwarf_one-vm.qcow2 * Información de ubicación de disco virtual del kvm virsh domblklist vm_debian10_t2micro_servercapedwarf_one * Información de disco virtual virt-filesystems --long -h --all -a /opt/images/debian10_capedwarf_one-vm.qcow2 qemu-img info /opt/images/debian10_capedwarf_one-vm.qcow2  * Incrementar tamaño de disco virtual de 20G a 30G qemu-img resize /opt/images/debian10_capedwarf_one-vm.qcow2 +10G virsh blockresize vm_debian10_t2micro_servercapedwarf_one /opt/images/debian10_cape