1. Incorporación de los ficheros de la segunda entrega

Dado que en este proceso se van a incluir nuevos ficheros en el proyecto, es recomendable hacer backup del mismo antes de empezar (p.ej. haciendo un ZIP del proyecto).

Una vez hecho esto, debes descargar el fichero ZIP que está disponible en Moovi con los ficheros que debes añadir para la segunda entrega.

A continuación, sigue los siguientes pasos:

1. Sitúa el fichero ZIP descargado en la raíz del proyecto.
2. Descomprime el fichero ZIP.
3. Edita el fichero pom.xml para hacer los siguientes cambios:

• HybridServerFirstReleaseTestSuite → HybridServerSecondReleaseTestSuite
• hybrid-server-${group.name}.r1 → hybrid-server-${group.name}.r2
• assembly-first-release.xml → assembly-second-release.xml

4. Añade a HybridServer el constructor HybridServer(Configuration).

En esta segunda entrega no se va a requerir superar los tests de la segunda semana (base de datos en memoria), por lo que, si se quiere, se pueden eliminar los tests de esta semana e incluso el constructor HybridServer(Map<String, String>) y las clases asociadas.

2. Datos en Memoria y en Base de Datos

Esta segunda entrega está completamente orientada a base de datos, por lo que no es necesario dar soporte al trabajo con XML, XSLT y XSD con los datos en memoria. Esto significa que no hay que ampliar el DAO "en memoria" e, incluso, se puede eliminar (incluyendo el constructor HybridServer(Map<String, String>)).

3. Fichero de Configuración

El fichero de configuración que se utilizará tendrá la misma estructura que el fichero configuration.xml disponible en el directorio tests del proyecto. Únicamente variarán los datos de configuración.

El fichero de validación configuracion.xsd deberá estar en la raíz del proyecto, de modo que al ser ejecutado pueda ser localizado con una cabecera como la del fichero de ejemplo.

La validación de los ficheros de configuración con XMLConfigurationLoader deberá hacerse mediante validación externa utilizando el fichero configuration.xsd.

4. Base de Datos

A la base de datos utilizada en la primera entrega habrá que añadirle las siguientes tablas con los campos indicados y respetando mayúsculas y minúsculas:

• XML
  • uuid de tipo CHAR(36). Será la clave primaria.
  • content de tipo TEXT en MySQL o LONG VARCHAR en JavaDB.
• XSD
  • uuid de tipo CHAR(36). Será la clave primaria.
  • content de tipo TEXT en MySQL o LONG VARCHAR en JavaDB.
• XSLT
  • uuid de tipo CHAR(36). Será la clave primaria.
  • content de tipo TEXT en MySQL o LONG VARCHAR en JavaDB.
  • xsd de tipo CHAR(36). No se debe configurar como clave foránea hacia XSD.

La base de datos estará creada, por lo que el servidor no debe contener ninguna sentencia ni función de creación de la base de datos.

5. Bases de Datos para P2P

Los tests de la semana 11 necesitan que exista una base de datos para cada uno de los cuatro servidores que se levantarán. Las bases de datos deben tener las mismas tablas que la base de datos que utilizamos hasta el momento, pero deben llamarse: hstestdb1, hstestdb2, hstestdb3 y hstestdb4.

El usuario hsdb debe tener los mismos permisos sobre estas bases de datos que para la base de datos hstestdb.

6. Respuesta a Peticiones

En el caso de una solicitud de creación de XSLT (POST), si no se envía contenido o si la petición no incluye el parámetro "xsd" (p.ej. http://localhost/xslt?xsd=uuid-del-xsd), entonces debe devolverse un error 400 Bad Request. Si el XSD indicado no existe debe devolverse un error 404 Not Found. En caso de producirse cualquier otro error deberá devolverse un error 500 Internal Server Error.

En el caso de una solicitud de XML transformado con un XSLT, si el XSD asociado no existe o el XML no es válido deberá devolverse un error 400 Bad Request. En el caso de que el XML o el XSLT no existan, deberá devolverse un error 404 Not Found. Si se produjese cualquier otro error, deberá devolverse un error 500 Internal Server Error.

7. Configuración del Servicio Web

En la configuración del servicio web, el namespace y el nombre del servicio son fijos y deben tener el siguiente valor:

• namespace: http://hybridserver.dai.esei.uvigo.es/
• service: HybridServerService

Para ello se recomienda hacer uso de los parámetros de la anotación @WebService.

8. Inicio y Parada de los Servicios Web

Los servicios web deben publicarse en el método start() de la clase HybridServer y detenerse en el método stop() de la misma clase.

9. Error porque el Nombre y Namespace del Servicio Web no es el Esperado

Si se utiliza la configuración por defecto de los servicios web, al ejecutar los tests ocurrirá una excepción en la que se indica que no se ha encontrado el servicio web con el nombre HybridServerService y namespace http://hybridserver.dai.esei.uvigo.es/. Estos son los valores que aparecen en los ficheros de configuración (test/configuration1.xml y similares) y que no coinciden con los que JAX-WS le asigna a los servicios web creados por defecto.

Solucionar este problema es sencillo, ya que simplemente habrá que modificar la configuración de la publicación de los servicios a través de las anotaciones del SEI y/o SIB.

10. Errores por Exceso de Conexiones con la Base de Datos

Al ejecutar los últimos tests del proyecto es posible que, a partir de un momento determinado, todos los tests fallen debido a que el límite de conexiones se ha superado. Este error es un síntoma de que las conexiones con la base de datos no se están cerrando cuando finaliza su uso y, por lo tanto, estamos desperdiciando recursos.

La solución a este problema pasa por tener en cuenta lo siguiente:

1. Cuando un hilo de servicio finaliza deben cerrarse las conexiones que se hayan abierto.
2. Al detener el servidor, el servicio web debe cerrar las conexiones que tenga abiertas. Una forma de implementar esto es que el objeto SIB tenga un método close() que no sea un método web (no debe estar anotado con @WebMethod) al que llamemos cuando se llame a HybridServer.stop() y se detenga el servicio web. Ten en cuenta que el método close() del SIB debe llamarse después de parar el servicio web y no antes.