El objetivo fundamental de esta práctica es aprender a modelar e implementar el nivel de presentación de aplicaciones Web usando la plataforma JEE.

Para ello la práctica se ha dividido en dos partes:

• PARTE I: Consiste en la instalación del servidor Web y cuatro ejercicios cortos, la solución de los cuales se dará en clase.
• PARTE II: Consiste en construir una pequeña aplicación Web. Se proporcionará un esqueleto básico de solución que habrá que modificar y extender.

El objetivo de esta segunda parte de la práctica 2 es el de modelar e implementar el subsistema del perfil de cliente de la aplicación de Gestión de Actividades Deportivas. Para ello, reutilizaremos por un lado el código de nivel de datos que se desarrolló en la resolución de la práctica 1, pero, por otro lado, implementaremos una nueva interfaz para interactuar con el sistema. En concreto, se desarrollará una interfaz Web, utilizando para ello tecnologías JEE (servlets y JSP).
 

Para instrucciones relativas a la instalación del servidor Tomcat, podéis mirar la parte I de esta práctica.
 

En esta práctica se debe realizar una aplicación Web usando servlets y JSPs que incluya los cuatro puntos de funcionalidad que se indican a continuación. Realmente la aplicación a desarrollar se corresponde exactamente con el subsistema de perfil de cliente de la aplicación "Gestor de Actividades Deportivas", pero en esta ocasión usando como vista una interfaz Web en lugar de una interfaz textual.

Incluso con esta restricción respecto a la tecnología a ser usada (servlets y JSPs), la aplicación Web a realizar se puede implementar de diferentes maneras (por ejemplo usando sólo servlets, sólo JSPs, ...). Este conjunto de diferentes posibilidades se ve limitado por las siguientes dos condiciones impuestas que debe cumplir la aplicación:

• Se debe hacer un uso adecuado de los servlets y JSP, de acuerdo a la arquitectura MVC (Modelo Vista Controlador). Se puede obtener información adicional acerca de este aspecto en el siguiente enlace de Sun MVC Java blueprint.
• Se debe reutilizar el módulo de datos que se desarrolló en la práctica anterior de nivel de datos, y del cuál se proporcionaron todos los ficheros, con excepción del DBInteraction.java que tuvisteis que implementar.
• Es obligatorio que en vuestra solución incluyáis apropiadamente al menos un JavaBean.

1. Aplicación Básica

La aplicación básica es una versión simplificada de la aplicación Gestor de Actividades Deportivas descrita en la práctica 1. Nos referiremos a esta aplicación reducida como aplicación de Búsqueda de Actividades Deportivas.

Modelo de Datos

El modelo de datos para la aplicación de Búsqueda de Actividades Deportivas se compone de las tablas de PABELLONES y ACTIVIDADES de la práctica 1.

Funcionalidad

A diferencia de la aplicación Gestor de Actividades Deportivas, sólo hay un tipo de perfil de usuario en la aplicación de Búsqueda de Actividades Deportivas. En esta aplicación simplificada, el usuario debe ser capaz de realizar las siguientes búsquedas en la base de datos:

• Listar todas las actividades
• Listar todos los pabellones
• Listar las actividades para las cuales hay actualmente plazas libres
• Listar las actividades para las cuales hay actualmente plazas libres y además tienen un precio menor a una cierta cantidad
• Listar las actividades para las cuales hay plazas libres y que tienen lugar en un cierto pabellón
• Presentar toda la información sobre una determinada actividad

Cuando se listen pabellones, para cada pabellón, la aplicación debe mostrar todos los campos de la tabla de PABELLONES. Cuando se listen actividades, para cada actividad, la aplicación debe mostrar todos los campos de la tabla de ACTIVIDADES.

Una página Web de entrada de datos única debe ser usada, en la cual el usuario introduce su criterio de búsqueda. Cada página Web presentada al usuario debe contener la misma imagen arriba y un texto de copyright debajo (pista: usar include).

Ejercicio

En clase se os proporcionará una solución a este problema. Dicha solución está implementada usando sólo servlets y un archivo HTML. Debéis modificar dicha solución de la siguiente manera:

1. Cuando se crean las tablas, añadir una " restricción (constraint) que asegure la "integridad referencial" (por ejemplo CASCADE ) cuando se borren elementos de esas tablas.
2. La aplicación debe usar tanto servlets como JSPs en un modo que sea acorde con el patrón de diseño MVC, tal como se ha comentado más arriba.
3. La aplicación debe reutilizar el módulo de datos de la práctica anterior sobre el nivel de datos.

La solución dada en clase también se encuentra aquí:

• index.html
• web.xml
• Buscador.java
• base_datos.txt

2. Formulario de Registro

Supongamos que la Universidad desea restringir el acceso a la aplicación "Buscador de Actividades Deportivas" y sólo va a proveer acceso a clientes registrados. En este punto, se requiere implementar un mecanismo para que nuevos usuarios de la aplicación se puedan registrar vía Web. La restricción real de acceso se deja para el punto número 3.

En la página inicial, el usuario elige entre una opción de "registro" y una opción de "Usuario ya registrado". Si el usuario elige "Usuario ya registrado", se muestra la página inicial del ejercicio anterior. Si el usuario elige la opción de "registro", se le muestra un formulario Web que permite a los usuarios registrase, pidiéndoles los datos necesarios (nombre, apellidos, dirección, número de teléfono, nombre de login y contraseña). Cuando el usuario envía los datos de registro, al usuario seguidamente se le presentan en otra página todos los datos de registro que ha introducido, preguntándole si son correctos. Si la respuesta es negativa, la página de registro se le muestra de nuevo, pero esta vez con los campos del formulario conteniendo los datos que previamente rellenó el usuario, con la posibilidad de editarlos. Si la respuesta es afirmativa, se le mostrará un mensaje indicando que el registro se ha completado exitosamente, junto con instrucciones sobre cómo entrar a la aplicación, por ejemplo sobre cómo ir a la página inicial del ejercicio anterior. Además, la información de registro se debe guardar en la base de datos, mediante una tercera tabla CLIENTES, que tiene la siguiente estructura:

Tabla CLIENTES

En una aplicación más realista, el usuario introduciría una dirección de e-mail en lugar de una password y una contraseña generada por la herramienta sería enviada a esa dirección de e-mail (tambien haría falta un mecanismo para cambiar la contraseña).

3. Acceso restringido a la aplicación de búsqueda de actividades deportivas

Supongamos que la Universidad desea restringir el acceso a la aplicación "Buscador de Actividades Deportivas" y sólo va a proveer acceso a clientes registrados. En este punto, se requiere implementar un sistema en la aplicación que permita sólo el acceso de usuarios registrados a la misma.

Al igual que ocurría en el anterior ejercicio, en la página inicial de la aplicación el usuario eligirá entre una opción de "registro" y "Usuario ya registrado". Si el usuario elige la primera, el resultado será como en el ejercicio previo. Si el usuario elige "Usuario ya registrado", entonces el usuario no tendrá directamente acceso a la aplicación, y en su lugar se le mostrará una página de login preguntándole por su login y contraseña. Si el usuario introduce un login no existente o una contraseña incorrecta, la aplicación debe mostrar la página de login de nuevo, pero esta vez con un mensaje de error. En el tercer intento incorrecto de login, se le debe mostrar la página de inicio con la elección entre las opciones de "registro" y "Usuario ya registrado". Si introduce una combinación login/contraseña correctas, entonces se le debe mostrar la página de inicio del primer ejercicio. El login/contraseña que introduzca un usuario en el formulario será comprobado con respecto a la tabla de CLIENTES que contiene la información sobre usuarios registrados.

Es importante remarcar que un usuario no podrá bajo ninguna circunstancia tener acceso a la aplicación de "Buscador de Actividades Deportivas" (desarrollada en el punto 1) cuya localización se describe por una URL diferente a la de la página de login, sin haber previamente introducido un login y password correctos en la página de login apropiada. Si un usuario intenta hacer eso, entonces se le debe mostrar la página de inicio. Adicionalmente, cada página Web de la aplicación que está protegida de esta manera debe contener un botón de logout; si el usuario selecciona este botón se termina la sesión y se muestra la página inicial.

Pista: Debéis usar apropiadamente los conceptos de sesión para resolver este ejercicio.

4. Extensión del perfil del Cliente

En este cuarto paso, se debe extender el perfil del cliente con las opciones para inscribirse, y desinscribirse de actividades. Es decir que en el menú ofrecido al cliente hay que añadir las siguientes opciones:

• Listar las actividades en las que estoy inscrito
• Apuntarse a una actividad
• Desapuntarse de una actividad

Por tanto, habrá que almacenar la información sobre inscripciones en la base de datos, utilizando para ello una tabla específica: la tabla de INSCRIPCIONES, que tiene la siguiente estructura:

Tabla INSCRIPCIONES

Téngase en cuenta que, al añadir la tabla de INSCRIPCIONES, se hace necesario mantener la coherencia de estado entre esta tabla y la de ACTIVIDADES, ya que los valores del atributo PLAZAS_OCUPADAS en la tabla ACTIVIDADES tienen que estar en correspondencia con el número de inscripciones para la actividad en cuestión en la tabla de INSCRIPCIONES.

Observaciones

• La aplicación DEBE funcionar correctamente incluso si el usuario desactiva las cookies en su navegador.
• NO es obligatorio que vuestra aplicación trate bien la concurrencia, aunque se valorará que lo haga. A este respecto es interestante saber que la interfaz SingleThreadModel está deprecated a partir de servlet 2.4. Por tanto, no es recomendable su uso y los problemas derivados de la concurrencia se deberían tratar con un uso apropiado de bloques synchronized de Java o con otros métodos.
• Debéis asegurar que vuestra aplicación funciona bien en los casos siguientes: (i) con el cliente y el servidor ejecutándose en máquinas distintas, (ii) con más de un cliente con una sesión de pedir listados activa a la vez, (iii) con más de un cliente intentando registrarse a la vez, (iv) con más de un cliente intentando hacer login a la vez, en particular, con dos clientes que utilizan ambos un nombre de usuario inexistente o clave incorrecta.
• Las tablas de la base de datos pueden ser creadas desde fuera de la aplicación.

Puntualizaciones adicionales

Es importante distinguir entre la transferencia de control a otro recurso dentro del servidor y la generación de una respuesta HTTP que puede llevar a una nueva solicitud HTTP del cliente a otro recurso en ese u otro servidor. En concreto:

• La diferencia entre el método forward y el sendRedirect es precisamente que el primero transfiere directamente el control a otro recurso del servidor, que será el encargado de generar la respuesta. Por el contrario, el segundo genera una respuesta HTTP con un código de estado 307 (redirección temporal, Temporary redirect), enviando la URL argumento de sendRedirect al navegador del cliente a través de la cabecera HTTP Location. Al recibir el navegador la redirección, genera una nueva solicitud HTTP con el método GET, con los mismos parámetros que la anterior, pero dirigida a la URL indicada por la redirección. Por tanto, el sendRedirect implica un proceso de ida-y-vuelta en el que se involucra al navegador del cliente, con lo que raramente estará justificado utilizar esta técnica para hacer redirecciones a recursos dentro del mismo servidor.
• Igualmente, cuando el contenido de una página JSP contiene una referencia a un servlet (para procesar por ejemplo un formulario generado por la página) no es correcto decir que la página "redirige al servlet". En este caso, la ejecución de la página JSP generaría código HTML que el servidor manda a través de una respuesta HTTP al cliente. Al visualizar este código, el cliente podría llevar a cabo acciones (por ejemplo, rellenar y enviar el formulario) que implicarían la generación de una nueva solicitud HTTP, encaminada en este caso al servlet. Así pues, de nuevo tenemos un proceso de ida-y-vuelta en el que el navegador del cliente, e incluso, el propio usuario, se ven involucrados.
• Por último, cuando se implemente el requisito de que la aplicación funcione con independencia de que el usuario tenga o no activadas las cookies, utilizando para ello el mecanismo de URL rewriting, no es necesario tratar las URLs cuando se pasa el control entre elementos del mismo servidor, únicamente aquellas que se incluyen en código HTML que se le envía al cliente.
   

El nivel de datos de esta aplicación es similar en parte al de la práctica 1.

Recordad que:

• Existe un servidor de bases de datos MySQL instalado en la máquina mysql.lab.it.uc3m.es.
• Se han habilitado cuentas en ese servidor para cada grupo, cuyo login y contraseña se proporcionaron en la práctica 1. En caso de que todavía no dispongas de una, debes solicitarla por e-mail al profesor Norberto Fernández. Para cada usuario, hay un schema (o database, en la terminología de MySQL) ya creado cuyo nombre coincide con el login.
• Para conectaros a la base de datos mediante el cliente de MySQL, deberéis hacer:

  mysql -h mysql.lab.it.uc3m.es -u usuario -p

La solución se debe entregar a través de Aula Global 2, concretamente, a través de la página web siguiente:

página de entrega, nivel de presentación, grupo español (91)

Vuestra entrega debe contener los siguientes elementos:

• Ficheros JSP
• Un fichero web.xml (descriptor de despliegue)
• Ficheros Java (servlets y Java beans)
• Los ficheros correspondientes class (los ficheros Java compilados)

La entrega debe realizarse en la forma de un archivo Web, o fichero war, denominado presentation.war. Si organizáis el directorio de la aplicación de acuerdo con la estructura dada en la parte 1 de esta práctica, es sencillo crear un fichero war en el formato deseado. Simplemente, ejecutad el comando siguiente en el directorio de más alto nivel de la aplicación:

jar cvf archiveName.war .

Sin embargo, hay una diferencia con respecto a un fichero war estándar: hay que incluir también el código fuente. A este fin, se añade otro directorio llamado src que contiene todo el código fuente (servlets y JavaBeans) en el directorio de más alto nivel de la aplicación. Mirad la sección adecuada del tutorial jar si queréis más detalles sobre los ficheros jar/war.

Si vuestro fichero war está creado correctamente, entonces debería ser posible desplegar la aplicación simplemente colocando dicho fichero WAR debajo del directorio webapps (si el nombre de vuestro fichero war es presentation.war, las URL para acceder a las páginas de vuestra aplicación tendrán la siguiente forma: http://dominio:8080/presentation/...). Es importante verificar esto antes de entregar la práctica. También debéis comprobar que vuestra aplicación funciona si se renombra el fichero war.

Como siempre, el código debe estar adecuadamente comentado (esto no significa que los comentarios deban ser excesivamente verbosos). El programa debe poder ser compilado y funcionar correctamente en el entorno del laboratorio para todos los diferentes casos y de acuerdo con las instrucciones dadas en la sección de Descripción de la práctica.

Fecha límite para entrega: 18/12/09

Hora límite: 12:00 h

Véanse en la página Web de la asignatura:

• los enlaces sobre SQL / JDBC
• los enlaces sobre servlets y JSPs

• los enlaces sobre SQL / JDBC
• los enlaces sobre servlets y JSPs