Proyecto de Aplicación Web

La definición de la plataforma Java en la Wikipedia en inglés es muy acertada:

Entre los programas que forman parte de la plataforma los dos más importantes son:

Una característica fundamental de Java es que los ficheros .class son, por tanto, multiplataforma. Y también lo son los ficheros .jar y .war, ficheros archivo en el se incluyen múltiples archivos .class y que constituyen las bibliotecas de clases Java que se distribuyen e instalan en los distintos sistemas operativos. No es necesario compilar distintas versiones de una determinada biblioteca para los distintos sistemas operativos, sino que la diversidad la trata el soporte de ejecución (la JVM) que interpreta estos ficheros JAR.

Dentro de la JVM hay un denominado compilador JIT (Just In Time) que optimiza el funcionamiento en tiempo de ejecución del código interpretado. De esta forma se consigue reducir muchísimo la diferencia en tiempo de ejecución entre un programa Java con bytecodes interpretado y un programa compilado a código nativo. La introducción de esta técnica en la JVM supuso un gran avance en la adopción de Java y una forma de vencer las críticas sobre la lentitud del código comparado con código nativo. Hoy en día ya casi nadie critica a Java por ese motivo e incluso el enfoque de la máquina virtual que interpreta código intermedio ha sido adoptado también por la plataforma .NET de Microsoft.

Otro elemento fundamental de la plataforma Java es su enorme biblioteca de clases (class libraries). Se trata de un conjunto de bibliotecas estándar que proporcionan una gran cantidad de utilidades y funciones para todo tipo de operaciones, como el procesamiento de expresiones regulares, el trabajo con distintos tipos de colecciones, funciones de bajo nivel de entrada-salida o el procesamiento de imágenes. Las librerías se distribuyen como ficheros JAR que se cargan de forma dinámica en el intérprete y a las que nuestras aplicaciones llaman en tiempo de ejecución.

El API de las bibliotecas Java depende de la plataforma de Java (Java SE o Java EE). Toda la biblioteca de funciones de Java SE está disponible en Java EE. La plataforma Java EE define un conjunto adicional de funcionalidades implementadas por más de 20 APIs.

Las aplicaciones en el servidor necesitan estar funcionando continuamente para responder a todas las peticiones que reciben. Por ejemplo, una aplicación web que recibe peticiones HTTP debe estar continuamente escuchando el puerto (normalmente el 80), recibiendo las peticiones GET o POST de los clientes (navegadores), procesándolas y contestándolas.

El desarrollo de este tipo de aplicaciones sería complicadísimo si tuviéramos que preocuparnos de todo su ciclo de vida. Por ejemplo, sería un infierno tener que implementar nosotros todo el bucle de procesamiento de las peticiones que llegan al servidor, utilizando hilos concurrentes que gestionan la entrada-salida y que lanzan las llamadas a los métodos que realizan el procesamiento.

En la plataforma Java EE se utiliza la idea de contenedor para solucionar este problema. El contenedor es la aplicación Java que se encarga de realizar todo el trabajo de infraestructura (como escuchar los puertos para recibir las peticiones) y que delega el procesamiento final en las aplicaciones (componentes) desplegadas en él. El desarrollador implementa estos componentes escribiendo las interfaces de las clases que se utilizan para definir los componentes. Un ejemplo concreto es el funcionamiento de los servlets que veremos en la primera asignatura del curso.

En palabras de Arun Gupta (en su libro Java EE 7 Essentials):

Los servidores de aplicaciones ofrecen tambien un conjunto de servicios relacionados con la alta disponibilidad, como son tolerancia a fallos, concurrencia o clustering.

En la actualidad Sun proporciona tres grandes distribuciones (o ediciones):

La historia de las versiones de estas distribuciones Java es la siguiente:

La plataforma Java EE 7 se define en la JSR 342. En la especificación se definen dos perfiles: el perfil web y el perfil completo. El perfil web está orientado a aplicaciones web básicas que no necesitan componentes transaccionales distribuidos. Las APIs que debe ofrecer el servidor de aplicaciones que soporta este perfil son las siguientes, agrupadas por la funcionalidad que proporcionan:

Veremos una gran parte de estas APIs a lo largo de la primera parte del curso.

La plataforma completa Java EE 7 añade a las APIs anteriores otro conjunto de características, orientadas sobre todo al soporte de aplicaciones transaccionales distribuidas:

Todas estas especificaciones se encuentran detalladas en distintas especficaciones denominadas JSRs (Java Specification Request). Cada JSR tiene un número de identificación y puede ser consultada en el sitio web Java Community Process. Todas las especificaciones de APIs sufren un largo proceso desde que comienza su propuesta hasta su aprobación final en una votación en la que participan todos los partners interesados en el API.

Por ejemplo, ahora mismo (el 22 de septiembre) se acaba de aprobar (con 24 votos a favor y ninguno en contra) que comience el desarrollo de la JSR 366 que definirá la nueva especificación de Java EE 8. Todas las JSRs de APIs de la plataforma Java EE (incluidas las ya retiradas) se encuentran en este enlace. Y, por ejemplo, la especificación de Java EE 7 se define en la JSR 342 que tardó dos años en ser completada.

Todas estas especificaciones sirven para que empresas independientes de Oracle (y también Oracle) desarrollen servidores de aplicaciones que compitan en rendimiento y funcionalidades adicionales, pero que sean todos compatibles entre si. El servidor GlassFish de Oracle es un servidor gratuito que sirve de plataforma de prueba de las especificaciones.

En la página de Oracle de compatibilidad de servidores de aplicaciones Java EE se listan los servidores de aplicaciones que han pasado las pruebas necesarias para obtener una compatibilidad con una determinada especificación Java EE. Existen muy pocos servidores de aplicaciones totalmente compatibles con Java EE 7, tanto en el perfil Web como en el perfil completo:

Por su mayor antiguedad, hay más servidores compatibles con Java EE 6:

El servidor de aplicaciones que vamos a utilizar en el curso es Wildfly, uno de los más avanzados, ligeros y competitivos. Está desarrollado por Red Hat y es muy posible que lo conozcas con el nombre que tenía anteriormente: JBoss. Es un servidor gratuito que tiene la posibilidad de contratar licencias comerciales para su uso en entornos que requieran un funcionamiento continuo y una disposición inmediata para solución de incidencias.

Ideas fundamentales:

El servicio REST proporciona el backend de la aplicación. Lo implementamos con la tecnología Java EE, que proporciona APIs para definir las distintas capas de la aplicación:

Dibujo y ejemplo concreto.

La aplicación cliente se ejecuta en dispositivos separados del servidor (navegadores web o dispositivos móviles), construye la interfaz con la que interactúan los usuarios y se comunica con el servicio REST usando HTTP.

La tendencia que está ganando cada vez más fuerza es construir la aplicación cliente como una aplicación JavaScript que corre en un navegador web usando algún framework de alto nivel como AngularJS o BackboneJS. La aplicación cliente lanza peticiones HTTP al servicio y pinta la interfaz de usuario y la rellena con los resultados de las peticiones.

Los apuntes, trasparencias y demás material docente se encuentran en un sitio web restringido a los alumnos del Experto. Puedes acceder a los materiales de cada módulo desde los enlaces disponibles en las páginas públicas de cada uno de las asignaturas del experto, accesibles desde el menú superior de las páginas públicas del Experto:

Cuando intentes acceder a la zona restringida del Experto Java aparecerá una página pidiéndote tu usuario y contraseña. El usuario será tu inicial (o iniciales) del nombre y tu primer apellido. Por ejemplo, el login de Juan Luis Pérez será jlperez.

Si deseas cambiar tu contraseña (o no la recuerdas), puedes pulsar en el enlace correspondiente. Se enviará un mensaje a tu dirección de correo con un enlace con el que podrás modificar la contraseña.

La Universidad de Alicante utiliza dos plataformas on-line para la interacción docente: Campus Virtual y Moodle. En nuestro título vamos a utilizar Moodle por considerarlo bastante más potente, flexible y fácil de utilizar que el Campus Virtual.

Para acceder a Moodle debes logearte en el CV de la UA y pulsar en el botón que hay en la parte inferior izquierda:

Vamos a utilizar Moodle como plataforma de trabajo colaborativo. La usaremos para gestionar los foros, las calificaciones de los ejercicios y alguna que otra encuesta que iremos presentando.

Uno de los elementos principales que utilizaremos de Moodle es el foro, que utilizaremos para resolver dudas que puedan surgir sobre el desarrollo de los ejercicios de las asignaturas o sobre cualquier tema relacionado con el título. Cualquiera puede publicar una entrada nueva en el foro o contestar a las ya existentes. Cada nueva entrada o contestación genera un correo electrónico que se envía a todos los profesores y estudiantes.

Para poder utilizar correctamente el foro es muy importante que actualices tu foto. Para esto debes pinchar en Administración > Ajustes de mi perfil > Editar perfil) y seleccionar Imagen del usuario. Allí puedes colocar tu foto. Cuando todos tenemos la foto es mucho más sencillo contestar e interactuar en el foro. La siguiente imagen muestra un ejemplo del foro general en la edición 2009-2010 del especialista:

En la página principal del curso podrás encontrar también:

Las clases se impartirán en un laboratorio gestionado por la EPS (los viernes, el laboratorio L17) y en un laboratorio gestionado por el Servicio de Informática (los sábados, en el Aulario I).

Para acceder los laboratorios de la EPS se debe contar con una cuenta de usuario (más información).

Al arrancar el ordenador deberás seleccionar como sistema operativo Windows. En este sistema operativo se encuentra el programa VirtualBox con el que se pondrá en marcha la MV en la que se realizarán las prácticas.

Trabajaremos directamente con la imagen de la MV en el disco externo SSD. Incluso en ordenadores con USB 2.0 el rendimiento será aceptable. En los ordenadores con USB 3.0 podrás aprovechar completamente la velocidad del disco SSD.

Buscar cuál es la disposición de puertos USB 3.0 en los ordenadores nuevos de la EPS.

Uno de los elementos más importantes de las prácticas del curso es la MV con una distribución de Linux Lubuntu y con las herramientas necesarias para realizar los ejercicios. Su uso te hace sencillo continuar en casa los ejercicios y prácticas realizados en clase y garantiza que todos utilizamos el mismo entorno de trabajo. También nos hace inmunes a posibles cambios en las instalaciones de los ordenadores de la universidad.

El disco imagen de la MV original se encuentra en el disco externo, y también comprimida en la zona restringida de apuntes de la web del Experto y dividida en 4 ficheros ZIP de unos 900 MB cada uno:

La MV Ubuntu es compatible con las últimas versiones VirtualBox. La versión de las Guest Additions instalada en la MV es la 4.3.14.

VirtualBox es multiplataforma y opensource. Existen versiones para Windows, Mac y Linux y es posible trabajar con la misma máquina virtual en distintos sistemas operativos. Puedes, por ejemplo, trabajar en la EPS en Windows y después continuar el trabajo en casa en Mac. Puedes bajar la última versión e instalarla en tu ordenador de casa desde la web de VirtualBox. Una vez instalado el programa VirtualBox, debes instalar también el VirtualBox Extension Pack que proporciona soporte para hardware adicional en el ordenador anfitrión, como el USB 2.0.

En la máquina virtual está instalada la versión 14.04 de Lubuntu, una versión más ligera del sistema operativo Ubuntu que usa una interfaz de usuario mínima y funcional basada en LXDE.

En la MV se ha creado el usuario expertojava con la contraseña expertojava. Tendrás que utilizar este login para entrar en el sistema, para ejecutar comandos en modo superusuario o cuando se bloquee la pantalla:

El disco de la máquina virtual tiene una capacidad máxima de 52 GB. Las aplicaciones instaladas ocupan inicialmente alrededor de 8 GB.

En la máquina virtual se ha instalado el software que vamos a utilizar a lo largo de todos los módulos del curso:

Lo primero que tenemos que hacer es crear con VirtualBox la máquina virtual en la que vamos a trabajar. Vamos a crear la MV para que trabaje con la imagen vdi en el disco externo (Experto_Java_2014.vdi).

La configuración de la máquina virtual creada se guarda en la carpeta VirtualBox VMs del directorio de usuario en el ordenador anfitrión. Como en los ordenadores de la universidad se restauran los discos duros frecuentemente, deberás repetir esto cada vez que empiece la sesión de prácticas. En tu ordenador de casa, bastará que lo hagas una vez.

Vamos a desarrollar todos los proyectos del experto utilizando el sistema de control de versiones distribuido Git. Con este sistema de control de versiones trabajaremos sobre un repositorio local y tendremos una réplica en un sitio remoto. Iremos confirmando (commit) todos los cambios que vamos realizando sobre el código fuente de nuestros proyectos en el repositorio local y luego subiremos (push) estos cambios al repositorio remoto. El repositorio remoto servirá de copia de seguridad y para compartir el código con los profesores.

Para la creación de los repositorios remotos utilizaremos el servicio Bitbucket.

Vamos a ver en cómo crear nuestro primer repositorio git. Podemos hacerlo primero en remoto y después bajarlo a nuestro ordenador o al revés.

Vamos a realizar una rápida introducción a la creación de proyectos y la sincronización con git y Bitbucket usando IntelliJ, el IDE que utilizaremos a lo largo de todo el curso.

En IntelliJ es importante diferenciar entre proyecto y módulo. El proyecto es el directorio principal de trabajo de IntelliJ, en el que se guarda la configuración de los distintos elementos que vamos creando en el entorno. Puede constituir un proyecto Java único, con sus clases, sus bibliotecas, sus ficheros de configuración, etc. O también puede contener más de un módulo, subdirectorios que constituyen subproyectos independientes pero que pueden compartir ciertos elementos situados en el proyecto principal.

Los proyectos y módulos del entorno se corresponden con directorios del sistema operativo y guardan la configuración en ficheros XML. La información de un proyecto se guarda en el directorio oculto .idea dentro del directorio con el nombre del proyecto. Por ejemplo, si creamos el proyecto prueba se creará un directorio con el mismo nombre que contendrá el directorio .idea. Lo podemos comprobar desde el terminal:

Los que conocen Eclipse pueden ver un proyecto IntelliJ como un workspace de Eclipse, con la diferencia de que en Eclipse no es posible usar un workspace como un proyecto con código fuente.

Cada módulo se guarda como un directorio con el nombre del módulo, en el que se crea un fichero <modulo>.iml con la configuración del módulo.

En IntelliJ podremos crear tres tipos de proyectos:

En todos los casos anteriores se puede definir un repositorio git en el proyecto principal, que contenga todos sus elementos (ya sea código fuente y/o otros subproyectos).

Vamos a empezar con un ejemplo del segundo tipo de proyectos: un proyecto vacío que contiene un par de módulos (programas Java) y que sincronizaremos posteriormente con Bitbucket. Lo hacemos paso a paso.

Maven ya viene preinstalado en la máquina virtual del experto. La instalación en Linux es muy sencilla.

En primer lugar debemos descargar la última versión de la página web oficial y descomprimirla en algún directorio del sistema. En el caso de la MV, lo hemos instalado en /usr/local/maven.

Maven es una aplicación Java, y utiliza la variable JAVA_HOME para encontrar el path del JDK. También es necesario añadir el directorio bin de Maven al PATH del sistema. Se pueden definir en el fichero de configuración .profile de un usuario. En nuestro caso hemos modificado el único usuario de la MV expertojava. La variabel de entorno M2_HOME es utilizada por IntelliJ para localizar la ubicación de Maven. El código que hemos añadido ha sido este:

Una característica del desarrollo de proyectos Java es la gran cantidad de librerías (ficheros JAR) necesarios para compilar y ejecutar un proyecto. Todas las librerías que se importan deben estar físicamente tanto en la máquina en la que se compila el proyecto como en la que posteriormente se ejecuta.

El proceso de mantener estas dependencias es tedioso y muy propenso a errores. Hay que obtener las librerías, cuidar que sean las versiones correctas, obtener las librerías de las que éstas dependen a su vez y distribuirlas todas ellas en todos los ordenadores de los desarrolladores y en los servidores en los que el proyecto se va a desplegar.

Por ejemplo, si nuestro proyecto necesita una implementación de JPA, como Hibernate, es necesario bajarse todos los JAR de Hibernate, junto con los JAR de los que depende, una lista de más de 15 ficheros. Es complicado hacerlo a mano y distribuir los ficheros en todos los ordenadores en los que el proyecto debe compilarse y ejecutarse. Para que Maven automatice el proceso sólo es necesario declarar en el fichero POM las siguientes líneas:

Maven se encarga de descargar todas las bibliotecas necesarias para un proyecto cuando ejecutamos el comando mvn install. Las guarda en el denominado repositorio local, el directorio oculto .m2 en el directorio raíz del usuario.

Los que hemos programado en C recordamos los ficheros Makefile en los que se especificaban las dependencias entre los distintos elementos de un proyecto y la secuencia de compilación necesaria para generar una librería o un ejecutable. En Java, el desarrollo de aplicaciones medianamente complejas es más complicado que en C. Estamos obligados a gestionar un gran número de recursos: código fuente, ficheros de configuración, librerías externas, librerías desarrolladas en la empresa, etc. Para gestionar este desarrollo es necesario algo de más nivel que las herramientas que proporciona Java (javac, jar, rmic, java, etc.)

¿En qué consiste el proceso de compilación y empaquetado en Java?. Básicamente en construir lo que Maven llama un artefacto (terminología de Maven que significa fichero) a partir de un proyecto Java definido con una estructura propia de Maven (apartado siguiente). Los posibles artefactos en los que podemos empaquetar un programa Java son:

Además, el ciclo de desarrollo de un proyecto es más complejo que esta construcción, ya que es necesario realizar un conjunto de tareas adicionales como gestionar las dependencias con librerías externas, integrar el código en repositorios de control de versiones (CVS, subversion o Git), lanzar tests o desplegar la aplicación en algún servidor de aplicaciones.

Podría pensarse que los entornos de desarrollo (Eclipse, Netbeans o IntelliJ) pueden dar una buena solución a la complejidad del proceso de construcción, pero no es así. Son imprescindibles para el desarrollo, pero no ayudan demasiado en la construcción del proyecto. La configuración de las dependencias se realiza mediante asistentes gráficos que no generan ficheros de texto comprensibles que podamos utilizar para comunicarnos con otros compañeros o equipos de desarrolladores y que pueden dar lugar a errores. El hecho de que sean entornos gráficos hacen complicado también usarlos en procesos de automatización y de integración continua.

La estructura de directorios de una aplicación web Maven es la que aparece en la siguiente figura.

El nombre del directorio raíz no influye en el proyecto Maven, podemos cambiarlo sin que afecte a ninguno de sus elementos. En ese directorio raíz se definen los siguientes directorios:

El elemento más importante de un proyecto Maven, a parte de su estructura, es su fichero POM en el que se define completamente el proyecto. Este fichero define elementos XML preestablecidos que deben ser definidos para el proyecto concreto que estamos desarrollando. Viendo algunos de ellos podemos entender también más características de Maven.

Vamos a utilizar como ejemplo la versión inicial del POM del proyecto web que vamos a construir en un rato. Veamos su fichero pom.xml. Al comienzo nos encontramos con la cabecera XML y la definición del proyecto:

A continuación se definen algunas propiedades del proyecto, que se utilizarán en los distintos procesos de Maven. En nuestro caso, por ahora, sólo la codificación de caracteres que estamos utilizando en el código fuente de nuestro proyecto:

Después vienen la definición de las dependencias del proyecto: librerías de las que dependen el proyecto. En nuestro caso:

Por último, definimos algunas características de los procesos de Maven que construyen el proyecto, definiendo parámetros para los pluging de Maven que se encargan de ejecutarlos.

Los proyectos software modernos necesitan un gran número de clases y librerías definidas en otros proyectos. Esos proyectos pueden ser otros desarrollados por nosotros en la empresa o librerías open source bajadas de Internet.

La tarea de mantener las dependencias de un proyecto es complicada, tanto para las dependencias entre nuestros proyectos como las dependencias con otros proyectos open source disponibles en Internet. Por ejemplo, si queremos utilizar un framework como Spring, tendremos que descargarnos no sólo los JAR desarrollados en el proyecto, sino también un buen número de otras librerías open source que usa. Cada librería es un fichero JAR. ¿Qué pasa si alguna de esas librerías ya las estamos usando y las tenemos ya descargadas? O, peor aún, ¿Qué pasa si estamos usando otras versiones de esas librerías en nuestros proyectos? ¿Podremos detectar los posibles conflictos?. Maven se encarga de gestionar estas dependencias directas y las dependencias transitivas mediante los ficheros POM:

Un elemento fundamental para gestionar las dependencias es poder identificar y nombrar un proyecto. En Maven el nombre de un proyecto se define mediante los siguientes elementos (que en Maven se denominan coordenadas):

En Maven un proyecto genera un artefacto. El artefacto puede ser un fichero JAR, WAR o EAR. El tipo de artefacto viene indicado en el tipo de empaquetamiento del proyecto.

El nombre final del fichero resultante de la construcción del proyecto es por defecto: <artifactId>-<version>.<packaging>.

Por ejemplo, Apache ha desarrollado el proyecto commons-email que proporciona una serie de utilidades para la gestión de correos electrónicos en Java. Sus coordenadas son:

El artefacto (fichero JAR) generado por el proyecto tiene como nombre email-1.1.jar

Cuando ejecutamos Maven por primera vez veremos que descarga un número de ficheros del repositorio remoto de Maven. Estos ficheros corresponden a plugins y librerías que necesita para construir el proyecto con el que estamos trabajando. Maven los descarga de un repositorio global a un repositorio local donde están disponibles para su uso. Sólo es necesario hacer esto la primera vez que se necesita la librería o el plugin. Las siguientes ocasiones ya está disponible en el repositorio local.

La direcciones en las que se encuentran los repositorios son las siguientes:

La estructura de directorios de los repositorios (tanto el central como el local) está directamente relacionada con las coordenadas de los proyectos. Los proyectos tienen la siguiente ruta, relativa a la raíz del repositorio:

Por ejemplo, el artefacto commons-email-1.1.jar, con coordenadas org.apache.commons:commons-email:1.1:jar está disponible en la ruta:

El estándar de Maven para los números de versiones es muy importante, porque permite definir reglas para gestionar correctamente las dependencias en caso de conflicto. El número de versión de un proyecto se define por un número principal, un número menor y un número incremental. También es posible definir un calificador, para indicar una versión alfa o beta. Los números se separan por puntos y el calificador por un guión. Por ejemplo, el número 1.3.5-alpha-03 define un número de versión principal 1, la versión menor 3, la versión incremental de 5 y el calificador de alpha-03.

Maven compara las versiones de una dependencia utilizando este orden. Por ejemplo, la versión 1.3.4 representa un build más reciente que la 1.0.9. Los clasificadores se comparan utilizando comparación de cadenas. Hay que tener cuidado, porque alpha10 es anterior a alpha2; habría que llamar al segundo alpha02.

Maven permite definir rangos de versiones en las dependencias, utilizando los operadores de rango exclusivos (, ) o inclusivos [, ]. Así, por ejemplo, si queremos indicar que nuestro proyecto necesita una versión de JUnit mayor o igual de 3.8, pero menor que 4.0, lo podemos indicar con el siguiente rango:

Si una dependencia transitiva necesita la versión 3.8.1, esa es la escoge Maven sin crear ningún conflicto.

Es posible también indicar rangos de mayor que o menor que dejando sin escribir ningún número de versión antes o después de la coma. Por ejemplo, [4.0,) representa cualquier número mayor o igual que 4.0, (,2.0) representa cualquier versión menor que la 2.0 y [1.2] significa sólo la versión 1.2 y ninguna otra.

Cuando dos proyectos necesitan dos versiones distintas de la misma librería, Maven intenta resolver el conflicto, descargándose la que satisface todos los rangos. Si no utilizamos los operadores de rango estamos indicando que preferimos esa versión, pero que podríamos utilizar alguna otra. Por ejemplo, es distinto especificar 3.1 y [3.1]. En el primer caso preferimos la versión 3.1, pero si otro proyecto necesitara la 3.2 Maven se descargaría esa. En el segundo caso exigimos que la versión descargada sea la 3.1. Si otro proyecto especifica otra versión obligatoria, por ejemplo 3.2, entonces el proyecto no se compilará.

Es posible utilizar la palabra SNAPSHOT en el número de versión para indicar que es una versión en desarrollo y que todavía no está lanzada. Se utiliza internamente en los proyectos en desarrollo. La idea es que antes de que terminemos el desarrollo de la versión 1.0 (o cualquier otro número de versión), utilizaremos el nombre 1.0-SNAPSHOT para indicar que se trata de "1.0 en desarrollo".

La utilización de la palabra SNAPSHOT en una dependencia hace que Maven descargue al repositorio local la última versión disponible del artefacto. Por ejemplo, si declaramos que necesitamos la librería foo-1.0-SNAPSHOT.jar cuando construyamos el proyecto Maven intentará buscar en el repositorio remoto la última versión de esta librería, incluso aunque ya exista en el repositorio local. Si encuentra en el repositorio remoto la versión foo-1.0.-20110506.110000-1.jar (versión que fue generada el 2011/05/06 a las 11:00:00) la descarga y sustituye la que tiene en el local. De forma inversa, cuando ejecutamos el goal install y se despliega el artefacto en el servidor remoto, Maven sustituye el palabra SNAPSHOT por la fecha actual.

Hemos visto que una de las características principales de Maven es la posibilidad de definir las dependencias de un proyecto. En la sección dependencies del fichero POM se declaran las librerías necesarias para compilar, testear y ejecutar nuestra aplicación. Maven obtiene estas dependencias del repositorio central o de algún repositorio local configurado por nuestra empresa y las guarda en el directorio .$HOME/.m2/repository. Si utilizamos la misma librería en un varios proyectos, sólo se descargará una vez, lo que nos ahorrará espacio de disco y tiempo. Y lo que es más importante, el proyecto será mucho más ligero y portable, porque no llevará incluidas las librerías que necesita para su construcción.

Ya hemos visto en apartados anteriores cómo se declaran las dependencias en el fichero POM. Cada dependencia se define de forma unívoca utilizando sus coordenadas. El mecanismo de declaración de las dependencias es el mismo para las dependencias de librerías externas como para las definidas dentro de la organización.

Para definir una dependencia hay que identificar también el número de versión que se quiere utilizar, utilizando la nomenclatura del apartado anterior. Por ejemplo, la siguiente dependencia especifica una versión 3.0 o posterior de hibernate.

Un concepto fundamental en Maven es el de dependencia transitiva. En los repositorios no solo se depositan los artefactos generados por los proyectos, sino también el fichero POM del proyecto. Y en ese fichero se definen las dependencias propias del proyecto. Por ejemplo, junto con el artefacto hibernate-3.0.jar se encuentra el fichero POM hibernate-3.0.pom.xml en el que se definen sus propias dependencias, librerías necesarias para Hibernate-3.0. Estas librerías son dependencias transitivas de nuestro proyecto. Si nuestro proyecto necesita Hibernate, e Hibernate necesita estas otra librería B, nuestro proyecto también necesita (de forma transitiva) la librería B. A su vez esa librería B tendrá también otras dependencias, y así sucesivamente.

Maven se encarga de resolver todas las dependencias transitivas y de descargar al respositorio local todos los artefactos necesarios para que nuestro proyecto se construya correctamente.

Otro elemento importante es el ámbito (scope) en el que se define la dependencia. El ámbito por defecto es compile y define librerías necesarias para la compilación del proyecto. También es posible especificar otros ámbitos. Por ejemplo test, indicando que la librería es necesaria para realizar pruebas del proyecto:

Otros ámbitos posibles son provided y runtime. Una dependencia se define provided cuando es necesaria para compilar la aplicación, pero que no se incluirá en el WAR y no será desplegada. Por ejemplo las APIs de servlets:

Las dependencias runtime son dependencias que no se necesitan para la compilación, sólo para la ejecución. Por ejemplo los drivers de JDBC para conectarse a la base de datos:

Una herramienta muy útil es el informe de dependencia. Este informe se genera cuando se ejecuta el objetivo site. Maven construye un sitio web con información sobre el proyecto y coloca el informe en el fichero target/dependencies.html:

El informe muestra una lista de dependencias directas y transitivas y su ámbito.

El concepto de ciclo de vida es central para Maven. El ciclo de vida de un proyecto Maven es una secuencia de fases que hay que seguir de forma ordenada para construir el artefacto final.

Las fases principales del ciclo de vida por defecto son:

Todas estas fases se lanzan especificándolas como parámetro en el comando mvn. Si ejecutamos una fase, Maven se asegura que el proyecto pasa por todas las fases anteriores. Por ejemplo:

Esta llamada realiza la compilación, los tests, el empaquetado los tests de integración y la instalación del paquete resultante en el repositorio local de Maven.

Los tests de unidad son una parte importante de cualquier metodología moderna de desarrollo, y juegan un papel fundamental en el ciclo de vida de desarrollo de Maven. Por defecto, Maven obliga a pasar los tests antes de empaquetar el proyecto. Maven permite utilizar los frameworks de prueba JUnit y TestNG. Las clases de prueba deben colocarse en el directorio src/test.

Para ejecutar los tests se lanza el comando mvn test:

Maven compilará los tests si es necesario. Por defecto, los tests deben colocarse en el directorio src/test siguiendo una estructura idéntica a la estructura de clases del proyecto. Maven ejecutará todas las clases que comiencen o terminen con Test o que terminen con TestCase.

Los resultados detallados de los tests se producen en texto y en XML y se dejan en el directorio target/surefire-reports. Es posible también generar los resultados en HTML utilizando el comando:

El informe HTML se generará en el fichero target/site/surefire-report.html.

IntelliJ reconoce los proyectos Maven a través del POM. Para importar un proyecto Maven en el IDE debes pulsar en el POM del proyecto. IntelliJ analiza el POM, descarga todas las librerías necesarias, identifica los directorios de la aplicación y los configura como directorios de fuentes, de tests, etc.

En la siguiente imagen vemos la estructura de directorios y las librerías de una versión inicial del proyecto web cargado. Podemos ver este panel en la parte superior izquierda de IntelliJ.

En la parte superior derecha de IntelliJ podemos ver el panel de Maven. Desde este panel podemos interactuar con el comando Maven.

Otra característica interesante de IntelliJ es que permite añadir dependencias en el POM de forma interactiva. Desde el fichero pom.xml pulsamos el botón derecho y seleccionamos Generate…​ (o pulsamos Alt+Insertar) y aparecerá el siguiente menú que permite modificar elementos del POM de forma interactiva:

Por ejemplo, seleccionando Dependency aparece una herramienta de búsqueda de librerías que permite filtrar por nombre y explorar las distintas versiones de las librerías disponibles en el repositorio central de Maven:

Para crear un repositorio Git con un proyecto Maven, hay que hacer lo habitual: inicializar Git en la raíz del proyecto y añadir todos sus ficheros. Hay que tener cuidado de añadir en el repositorio sólo los ficheros fuente. Todos los ficheros de artefacto que crea Maven a partir de los ficheros fuente originales deben ser ignorados. Para ello basta con ignorar el directorio target.

El siguiente fichero .gitignore contiene las reglas que determinan los ficheros ignorados en un proyecto Maven en el que trabajamos con IntelliJ. Es recomendable ignorar también el fichero .idea/workspace.xml que contiene el estado de trabajo del IDE (pestañas abiertas, dimensiones de la ventana actual, etc.).

A partir de un supuesto básico de la gestión de una biblioteca, vamos a crear un caso de estudio completo que evolucionará conforme estudiemos las diferentes tecnologías de la plataforma Java Enterprise.

El objetivo de esta sesión es introducir el caso de estudio que vamos a desarrollar, obtener una visión global del proyecto, fijando los casos de uso y requisitos principales y definiendo el esqueleto inicial del problema.

El Instituto de Educación Secundaria "jUA" nos ha encargado que desarrollemos una aplicación para la gestión de los préstamos realizados en la biblioteca del centro, lo que implica tanto una gestión de los libros como de los alumnos y profesores que realizan estos prestamos.

Tras una serie de entrevistas y reuniones con diferente personal del centro, hemos decidido hacer un prototipo inicial que servirá para probar el funcionamiento de la parte de la aplicación destinada a los clientes de la biblioteca: profesores y alumnos que van a poder solicitar préstamos de libros a través de la aplicación.

En concreto, las características que vamos a implementar en este prototipo serán las siguientes:

Estas funcionalidades las vamos a convertir más adelante en casos de uso y las vamos a implementar a lo largo del curso, conforme vaya avanzando el proyecto de integración.

Los requisitos de información resumen la información persistente que nos interesa almacenar relacionada con el sistema.

Respecto a un usuario, nos interesa almacenar:

Respecto a un libro, nos interesa almacenar:

Queremos que la aplicación realice también recomendaciones de libros, de forma que para un libro a prestar se muestre una lista de libros relacionados. Esta lista de libros se obtendrá a partir de los libros que han tomado prestado usuarios que han tomado prestado el libro original.

Para ello cada vez que un usuario tome prestado un libro -libro1- se incrementará en 1 la frecuencia de la pareja (libro1, libro-X) para todos los _libro-X- que ha tomado prestado el usuario en el curso actual. De esta forma obtendremos una tabla de frecuencias de préstamo conjunto de libros.

Respecto a un ejemplar, almacenaremos:

Un préstamo relaciona ejemplares y usuarios. En cada préstamo guardaremos:

Cuando un usuario se retrase en la devolución de un libro, se le creará una multa. Nos han comunicado que quieren mantener un histórico de las multas que ha tenido un usuario. De cada multa nos interesa saber:

Los casos de uso son bastante sencillos. Vamos a centrarnos sólo en la parte del usuario registrado en la biblioteca, dejando para otro momento la parte de la aplicación del bibliotecario en la que se realizaría una gestión (altas, bajas y modificaciones) de los libros, ejemplares y usuarios. El siguiente esquema muestra los casos de uso de un usuario logeado en el sistema:

El usuario podrá consultar los libros disponibles en la biblioteca y obtener más información sobre aquellos en los que esté interesado, accediendo a la pantalla de detalle del libro. Desde esta pantalla de detalle podrá solicitar el préstamo del libro y ver la información de libros recomendados relacionados con el actual.

Para hacerse una idea mejor del funcionamiento de la aplicación es conveniente hacer diseños iniciales o mockups de estas pantallas, junto con un esquema de navegación de las mismas. Los vemos a continuación.

Esquema de navegación:

Pantalla con el listado de libros:

Pantalla con el detalle de libro:

Pantalla con los libros que tiene prestados un usuario:

Estos son bocetos iniciales de pantallas. A partir de ellas, del modelo de datos y de las reglas de negocio que veremos más adelante, diseñaremos el API REST con las funcionalidades que ofrecerá nuestro servicio.

Podemos resumir en la siguiente tabla las restricciones a aplicar a los casos de uso anteriores:

El máximo de libros prestados de un alumno es 6. Los libros prestados los tiene que devolver antes de 7 días.

En el momento que un usuario tenga una demora en la devolución de un préstamo, se considerará al usuario moroso y se le impondrá una penalización del doble de días de desfase durante los cuales no podrá ni reservar ni realizar préstamos de libros.

A partir de los requisitos y tras unas sesiones de modelado, hemos llegado al siguiente modelo de clases conceptual representado mediante el siguiente diagrama UML:

Utilizaremos un modelo de clases como punto de partida del modelo de datos. En la siguiente sesión construiremos el modelo de datos basándonos en este modelo de clases y utilizando JPA (Java Persistence API). Veremos que este enfoque se denomina ORM (Object Relational Mapping), porque permite definir una relación directa (mapping) entre clases Java y tablas de la base de datos. La relación entre clases Java y tablas se define por medio de anotaciones JPA añadidas en el código fuente de las clases.

Vemos que casi todas las clases tienen un atributo id de tipo Long. Será la clave primaria de la tabla asociada a la clase y será generado automáticamente por la base de datos. Durante un tiempo de la vida del objeto, antes de ser insertado en la base de datos, este identificador va a ser null. Tenemos que tener en cuenta esto a la hora de definir correctamente los métodos equals y hashCode.

Las clases de dominio representan las entidades que van a hacerse persistentes y con las que van a trabajar las capas de persistencia y de lógica de dominio de la aplicación. En las siguientes sesiones, cuando veamos JPA, veremos cómo se podrán definir la capa de persistencia de la aplicación directamente a partir de estas clases y cómo se utilizarán para encapsular los datos pasados como parámetros y devueltos por las funciones de la capa de negocio implementadas por componentes EJB.

Para asegurarnos que todos nuestros objetos de dominio tienen una estructura común, definimos una clase abstracta, que será la clase padre de todas las clases de dominio. Definiremos en esa clase los métodos equals() y hashCode() para obligar a que las clases hijas implementen y redefinan la igualdad. Estos métodos son necesarios para poder guardar los objetos en colecciones.

Todas las entidades las vamos a definir dentro del paquete org.expertojava.jbibrest.modelo. Cada objeto de dominio se compone de sus atributos, relaciones y de todos los getter/setter que encapsulan al objeto.

Vamos a definir las clases Libro y Ejemplar. Define también la otra clase (pero vacía, sin incluir código) PrestadoJuntoCon para que no haya errores de compilación.

Empezamos por la clase Libro:

Y definimos también la clase Ejemplar:

Todos los métodos se pueden generar usando el asistente de IntelliJ, con la opción Generate…​.

Vamos a implementar una versión inicial de la jerarquía de clases usuario, definiendo un esqueleto de clases que ampliaremos más adelante.

En primer lugar la clase padre abstracta Usuario que hereda de ClaseDominio y que define los atributos comunes login y password. Los métodos equals y hashCode de todas las subclases se basan en estos atributos, porque definen unas claves naturales para estas clases. Definimos entonces esos métodos en la clase padre Usuario. Y escogemos como clave natural el login del usuario, de forma que dos usuarios serán iguales cuando tengan el mismo login.

Definimos las clases hijas, junto con su constructores:

Es conveniente definir una clase de excepciones para encapsular en ellas todos los errores generados en la aplicación. Vamos a definir una excepción genérica de tipo unchecked (BibliotecaException), que será la excepción padre de todas las excepciones de aplicación de la biblioteca.

En principio la definimos unchecked porque todos los errores que vamos a capturar tienen que ver con el mal uso del API. En general, un método debe realizar su funcionalidad y terminar correctamente cuando todo ha funcionado bien. Se lanzará una excepción si algo falla. Por ejemplo, cuando definamos un método prestar(libro,usuario) lanzaremos excepciones cuando no se cumplan las condiciones que hacen que el libro pueda ser prestado al usuario. Al lanzar excepciones no chequeadas permitimos que el programador chequee las condiciones antes de llamar al método y no tenga que obligatoriamente capturar una excepción que sabemos que no se va a producir. Si es necesario más adelante añadiremos una excepción checked.

Definimos las excepciones en el paquete org.expertojava.jbibrest.utils.

Podemos observar como, al sobrecargar el constructor con los parámetros {String, Throwable}, nuestra excepción permitirá su uso como Nested Exception.

Es común agrupar las reglas de negocio de una aplicación en una o más clases (dependiendo de los diferentes subsistemas de la aplicación), para evitar que estén dispersas por la aplicación y acopladas a un gran número de clases.

En nuestro caso, vamos a crear un Singleton, al que llamaremos BibliotecaBR (BR = Business Rules). En principio, los valores estarán escritos directamente sobre la clase, pero en un futuro podríamos querer leer los valores de las reglas de negocio de un fichero de configuración).

El código inicial de nuestras reglas de negocio será el siguiente:

Como último paso de esta parte guiada del proyecto vamos a cambiar la página frontal para probar la aplicación se despliega correctamente. Modificamos la página index.jsp para recoger una cadena de texto que simula un ISBN de un libro

Y cambiamos también el servlet holamundo para que haga una acción muy sencilla como crear un libro y mostrarlo:

Con esto terminamos la parte guiada.

Los tests estarán funcionando correctamente y la página web de prueba deberá mostrar el libro creado correctamente. Puedes borrar las clases Nombre, Genero y NombreTest del principio de la clase.

En la capa de persistencia tenemos que convertir las clases de modelo en entidades, utilizando las anotaciones JPA y bean validation necesarias. Crearemos también las clases DAO que encapsulan las operaciones sobre estas entidades.