Skip to content

1. Introducción

El PDF de este documento está disponible |AQUÍ|.

Los ejemplos de este documento están disponibles |AQUÍ|.

1.1. Contenu

En este documento nos proponemos estudiar diferentes configuraciones de operación de una base de datos. Consideremos la siguiente arquitectura en capas:

El flujo de ejecución va de izquierda a derecha:

  • es una de las clases de la capa [ui] (Use Interface) la que se ejecuta primero. Esta instanciará las capas [metier] y [dao]. Si la capa [ui] es una interfaz gráfica, a continuación espera las acciones del usuario. Una acción del usuario puede provocar la ejecución de métodos en todas las capas de la arquitectura hasta llegar a la base de datos. El resultado de estas ejecuciones se presenta al usuario de una forma u otra;

La función de las diferentes capas podría ser la siguiente:

  • la capa [JDBC] (Java DataBase Connectivity) es una interfaz de acceso universal a las bases de datos. Siempre presenta la misma interfaz a la capa [DAO]. Si se cambia de SGBD, basta con cambiar el controlador JDBC. La capa [DAO] no cambia si se han respetado ciertas reglas. Sin embargo, es difícil garantizar una portabilidad del 100 % entre SGBD, ya que estos suelen contener una parte importante de SQL propietario que es difícil de ignorar, pues a menudo aporta mejoras de rendimiento. En cuanto se utiliza el código propietario de SQL, la portabilidad con SGBD ya no es posible. Además, los SGBD suelen tener políticas diferentes para la generación automática de claves primarias, así como palabras reservadas que no son las mismas en todos los casos. En este documento, sin embargo, se logró portar la arquitectura JDBC estudiada a seis SGBD diferentes, aceptando que existiera un proyecto de configuración para cada uno de ellos;
  • la capa [DAO] expone una interfaz de acceso a los datos de la base de datos específica utilizada (que debe diferenciarse de la interfaz JDBC, la cual expone métodos válidos para cualquier SGBD);
  • la capa [métier] implementa las reglas de gestión o reglas de negocio de la aplicación.
    • tiene como datos de entrada aquellos que provienen de la base de datos a través de la capa [dao] y/o los del usuario que le transmite la capa [ui];
    • genera datos que puede guardar en la base de datos a través de la capa [dao] y/o devolver a la capa [ui] que le ha solicitado información, para que se muestren al usuario;
  • la capa [ui] es la que ejecuta las acciones del usuario y le devuelve los resultados de las mismas;

En el ejemplo anterior, la capa [DAO] envía solicitudes SQL a la capa [JDBC] para su ejecución en la capa SGBD. Desde hace algunos años (2006), esta arquitectura puede evolucionar de la siguiente manera:

Ahora es la capa JPA (Java Persistence API) la que envía solicitudes SQL a la capa JDBC y recibe los resultados de esta. La capa [JPA] presenta a la capa [DAO] operaciones para persistir, modificar, eliminar u obtener objetos. La capa [DAO] ya no envía órdenes SQL. Este enfoque es más portátil, ya que las implementaciones de JPA manejan las diferencias con respecto a SGBD, pero es más lento que la tecnología JDBC. Realizaremos pruebas de rendimiento para demostrarlo. La tecnología JPA formaliza el trabajo realizado por el marco Hibernate [http://hibernate.org/] hace años.

Estudiaremos dos capas [DAO] con una de las dos arquitecturas siguientes:

Se exigirá que las capas [DAO1] y [DAO2] implementen la misma interfaz [IDAO]. Además, la prueba [JUnitTestsDao] será la misma para ambas configuraciones y nos permitirá comparar el rendimiento. La capa [DAO1] se implementará con Spring JDBC y la capa [DAO2] con Spring JPA;

Una vez hecho esto, expondremos la interfaz [IDAO] en la web de la siguiente manera:

  • en [1], la capa [IDAO] se expone en la web a través de una capa web [2] implementada por Spring MVC. Es precisamente la interfaz [IDAO] la que se expone, y construiremos dos versiones del servicio web dependiendo de si esta interfaz se implementa con una arquitectura [DAO-JDBC] o [DAO-JPA-JDBC];
  • En [B], un cliente remoto utiliza los URL expuestos por el servicio web, los cuales brindan acceso a los métodos de la capa [IDAO-serveur]. Nos aseguraremos de que la capa [DAO-Client] [3] implemente la interfaz [IDAO-serveur] [1]. Esto nos permitirá utilizar la misma prueba [JUnitTestsDao] que ya se ha utilizado dos veces ([4]);
  • en [3], la capa [DAO-client] se implementará con Spring RestTemplate;

Una vez hecho esto, protegeremos el acceso al servicio web:

  • en [5], la solicitud HTTP del cliente pasa por una capa de autenticación implementada con Spring Security;

Una vez hecho esto, actualizaremos la arquitectura anterior a la siguiente:

  • En [3], la aplicación del cliente es en sí misma una aplicación web. Esta presentará un formulario [5] que permitirá consultar los URL del servicio web seguro. Los accesos HTTP al servicio web seguro se realizarán mediante una capa [DAO-client-js] implementada en JavaScript. Esta arquitectura utiliza lo que se conoce como solicitudes entre dominios:
    • el servicio web [2] presenta URL con el formato [http://machine1:port1/];
    • la aplicación web cliente [3] se descarga desde una URL [http://machine2:port2/]. Si [http://machine2:port2/] no es idéntico a [http://machine1:port1/] (misma máquina, mismo puerto), entonces el navegador del cliente bloqueará las llamadas HTTP de la capa [DAO-client-js]. Para solucionar este problema, el servicio web debe permitir las solicitudes entre dominios. Veremos cómo;

Los proyectos presentados se han probado con los siguientes seis SGBD:

  • MySQL 5 Community Edition;
  • SQL Server 2014 Express;
  • PostgreSQL 9.4;
  • Oracle Express 11g versión 2;
  • IBM DB2 Express-C 10.5;
  • Firebird 2.5.4;

Para cada uno de estos SGBD, se han desarrollado cuatro capas [DAO] diferentes:

  • una capa implementada con Spring JDBC;
  • una capa implementada con Spring JPA y el proveedor JPA Hibernate;
  • una capa implementada con Spring JPA y el proveedor JPA EclipseLink;
  • una capa implementada con Spring JPA y el proveedor JPA OpenJPA;

Por lo tanto, aquí se presenta un conjunto de veinticuatro configuraciones diferentes. Se ha realizado un gran esfuerzo de factorización:

  • la mayor parte del código se escribe solo una vez. Se basa en dos proyectos de configuración de Maven:
    • uno configura la capa JDBC;
    • el otro configura la capa JPA;

El proyecto de configuración de Maven de la capa JDBC [1] de un SGBD específico consta de dos pasos:

  • importar el archivo del controlador JDBC;
  • definir las credenciales de acceso a la base de datos utilizada y las diferentes órdenes SQL que la capa [DAO1] emitirá hacia el controlador JDBC. Aunque SQL está estandarizado, se han presentado problemas de portabilidad, principalmente debido a la presencia en las consultas de nombres de tablas y columnas que resultaron ser palabras clave prohibidas en ciertos SGBD (tabla ROLES para DB2, columna PASSWORD para Firebird). Por otra parte, aunque normalmente un nombre de columna no distingue entre mayúsculas y minúsculas, se presentó un problema con PostgreSQL en relación con la columna ID de la clave primaria de las tablas. El sistema exigía que se llamara id en minúsculas. Estos son ejemplos típicos de problemas de portabilidad inesperados;

Los tres proyectos Maven de configuración de la capa JPA [2] de un SGBD en particular también consisten en dos pasos:

  • importar el archivo de la implementación JPA;
  • configurar la implementación JPA utilizada para el SGBD específico conectado. De hecho, es la capa JPA la que envía las órdenes SQL a la capa JDBC. Para que esto funcione, debe conocer el SGBD a fin de enviarle las órdenes SQL que él reconocerá. Estas órdenes podrán utilizar el SQL, propietario de este SGBD, así como las características particulares de este último (tipos de datos, secuencias, disparadores, procedimientos, generación automática de claves primarias, etc.);

De este modo, contamos con veinticuatro proyectos (4 configuraciones × 6 SGBD) de configuración de Maven en los que se basarán todos los demás proyectos de operación de la base de datos. En los esquemas anteriores, dado que las capas [DAO1] y [DAO2] ofrecen la misma interfaz, las 24 configuraciones de las dos arquitecturas anteriores se probarán con una única clase de prueba [JUnitTestsDao]. Una vez verificadas estas arquitecturas, ya no hay dificultades:

  • el proyecto Maven para publicar la base de datos en la web se basa en estas dos arquitecturas. Por lo tanto, también hay 24 configuraciones posibles;
  • el proyecto Maven para la seguridad del acceso al servicio web se basa en el proyecto anterior y también cuenta con 24 configuraciones posibles;
  • por último, el proyecto Maven que permite las solicitudes entre dominios al servicio web seguro se basa en el proyecto anterior y también cuenta con 24 configuraciones posibles;

El estudio se realiza con SGBD, MySQL5 y la implementación JPA de Hibernate. A continuación, se realiza la adaptación a las implementaciones JPA (Eclipselink) y OpenJPA. Luego se realiza la migración a las demás bases de datos (PostgresQL, Oracle; SQL, Server; DB2, Firebird).

Este curso está dirigido a principiantes. Se explica la mayor parte de los conceptos utilizados. No es necesario tener conocimientos de programación de bases de datos ni de programación web. Sin embargo, se requieren conocimientos sólidos del lenguaje SQL, ya que no se explican las consultas SQL utilizadas.

Para entender los ejemplos, se requiere un conocimiento básico del lenguaje Java, que se puede encontrar en cualquier curso de introducción a este lenguaje. Los dos primeros capítulos del documento [Introducción al lenguaje Java (1998)] son suficientes. Se trata de un documento antiguo (de 1998, revisado en 2002), pero contiene los fundamentos básicos. Para un curso completo, se puede consultar el extenso libro de Jean-Marie Doudoux, [http://www.jmdoudoux.fr/java].

Este documento no es en absoluto exhaustivo. Su único propósito es ofrecer una metodología y códigos que se puedan reutilizar en contextos similares. El documento se ha redactado de tal manera que se pueda leer sin necesidad de tener una computadora a la mano. Por ello, se incluyen muchas capturas de pantalla.

Aunque no abarca todas las capacidades del lenguaje Java ni todos sus ámbitos de aplicación, este documento puede utilizarse como material de aprendizaje del lenguaje. Si sigue este documento, aunque no en su totalidad, el lector principiante alcanzará un nivel de «Java avanzado», tanto en el uso del lenguaje como en el del marco Spring. Podrá entonces continuar su formación en Java con las siguientes obras:

1.2. Sources

Este documento tiene dos fuentes principales:

Para profundizar en Spring, se pueden consultar las siguientes referencias:

  • el documento de referencia del marco Spring [http://docs.spring.io/spring/docs/current/spring-framework-reference/pdf/spring-framework-reference.pdf];
  • se pueden encontrar numerosos tutoriales de Spring en URL y [http://spring.io/guides];
  • el sitio web de [developpez.com] dedicado a Spring [http://spring.developpez.com/];
  • el tutorial [http://www.tutorialspoint.com/spring/spring_tutorial.pdf];

El lector que no cuente con los conocimientos suficientes podrá adquirir los conceptos básicos con el libro en el enlace URL [http://tahe.developpez.com/divers/sql-firebird/].

1.3. Las herramientas utilizadas

Los siguientes ejemplos se han probado en el siguiente entorno:

  • equipo con Windows 8.1 Pro de 64 bits;
  • JDK 1.8 (párrafo 23.1);
  • IDE Spring Tool Suite 3.6.3 (párrafo 1);
  • navegador Chrome (no se utilizaron otros navegadores);
  • extensión de Chrome [Advanced Rest Client] (párrafo 1);
  • SGBD MySQL 5.6 Community Edition (párrafo 23.4);
  • SGBD SQL Server 2014 Express (párrafo 23.9);
  • SGBD PostgreSQL 9.4 (párrafo 23.7);
  • SGBD Oracle Express 11g versión 2 (párrafo 23.6);
  • SGBD IBM DB2 Express-C 10.5 (párrafo 23.8);
  • SGBD Firebird 2.5.4 (párrafo 23.10);
  • los clientes de EMS Manager de sus seis SGBD (párrafo 23.5);

Tenga cuidado con JDK 1.8. Uno de los casos de estudio utiliza un método del paquete [java.lang] de Java 8.

La mayoría de los ejemplos son proyectos Maven que se pueden abrir tanto en Eclipse como en NetBeans. A continuación, las capturas de pantalla provienen de Spring Tool Suite, una variante de Eclipse.

1.4. Los ejemplos

Los ejemplos están disponibles en formato de archivo para descargar.

  • en [1], las carpetas de los ejemplos;
  • en [2], la carpeta [spring-core] contiene los proyectos de aprendizaje de Spring;
  • en [3], la carpeta [spring-database-config] contiene los proyectos de configuración JDBC y JPA de las seis bases de datos;
  • en [4], la configuración de Oracle de SGBD. En ella se encuentran tres carpetas:
    • [databases] contiene los scripts SQL para generar las dos bases de datos utilizadas por el documento;
    • [jdbc-driver] contiene el controlador JDBC de Oracle, así como un script para instalarlo en el repositorio local de Maven;
    • [eclipse] contiene [5] los cuatro proyectos de configuración de Oracle:
      • [oracle-config-jdbc] configura la capa de acceso JDBC a SGBD;
      • [oracle-config-jpa-hibernate] configura la capa JPA de acceso a SGBD con el proveedor JPA Hibernate;
      • [oracle-config-jpa-eclipselink] configura la capa JPA de acceso a SGBD con el proveedor JPA Eclipselink;
      • [oracle-config-jpa-openjpa] configura la capa de acceso JPA a SGBD con el proveedor JPA OpenJPA;
  • en [6], el archivo [eclipse config / launch configurations] contiene las configuraciones de ejecución que el usuario podrá importar a Eclipse para luego adaptarlas a su propio entorno;
  • en [7], la carpeta [spring-database-generic] contiene todo el código de acceso a SGBD, común a los seis SGBD y a los tres proveedores JPA;
  • en [8], [spring-jdbc] contiene cuatro proyectos que incluyen API, JDBC y Spring JDBC;
  • en [9], [spring-jpa / spring-jpa-generic] es el proyecto que utiliza una capa JPA para acceder a una base de datos. Los proyectos [generic-create-db*] son proyectos JPA que permiten crear las bases de datos utilizadas por la capa JPA;

  • en [10], la carpeta [spring-webjson] contiene los proyectos que exponen la base de datos en la web;

    • [spring-webjson-server-jdbc-generic] es el servicio web que expone la base de datos a la que se accede mediante Spring JDBC;
    • [spring-webjson-server-jpa-generic] es el servicio web que expone la base de datos a la que se accede mediante Spring JPA;
    • [spring-webjson-client-generic] es el único cliente que permite acceder a los dos servicios web anteriores;

  • en [11], la carpeta [spring-security] contiene los proyectos que exponen la base de datos en la web con acceso seguro;

    • [spring-security-server-jdbc-generic] es el servicio web seguro que expone la base de datos a la que se accede mediante Spring JDBC;
    • [spring-security-server-jpa-generic] es el servicio web seguro que expone la base de datos a la que se accede mediante Spring JPA;
    • [spring-security-client-generic] es el único cliente que permite acceder a los dos servicios web seguros anteriores;

  • en [12], la carpeta [spring-cors] contiene los proyectos que exponen la base de datos en la web con un acceso seguro que permite accesos entre dominios, como los que provienen del código JavaScript de un navegador;

    • [spring-cors-server-jdbc-generic] es el servicio web seguro que permite accesos entre dominios y que expone la base de datos a la que se accede mediante Spring JDBC;
    • [spring-cors-server-jpa-generic] es el servicio web seguro que permite el acceso entre dominios y que expone la base de datos a la que se accede mediante Spring JPA;
    • [spring-cors-client-generic] es una aplicación web que permite consultar los dos servicios web anteriores;
https://stahe.github.io
Este tutorial, escrito por Serge Tahé, se pone a disposición del público bajo los términos de la Creative Commons Reconocimiento – Sin uso comercial – Compartir igual 3.0 sin modificaciones.