PRUEBA DE EVALUACIÓN CONTINUA

GRADO APLICACIONES DISTRIBUIDAS

PRÁCTICA FINAL | ENUNCIADO Y ORIENTACIONES PARA SU DESARROLLO

|Dr. Andrés Duque Fernández, Dr. Rafael Pastor Vargas

GRADO EN INGENIERÍA EN TECNOLOGÍAS DE LA INFORMACIÓN

2018-2019

UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA

 APLICACIONES DISTRIBUIDAS

1.- OBJETIVOS

La práctica final de la asignatura consiste en la implementación de un sistema distribuido basado en la

tecnología de servicios Web, y su despliegue en un contenedor web con soporte como servidor de servlets
como es Tomcat (http://tomcat.apache.org/). Este sistema permitirá ejecutar un generador de señales y
obtener y representar los valores calculados por dicho generador. El despliegue se realizará tanto de forma
local como utilizando una plataforma de computación en la nube como es Amazon Web Services, o AWS
(https://aws.amazon.com/es/), a través de su programa académico AWS Educate
(https://aws.amazon.com/es/education/awseducate/). De esta manera se pretende que el estudiante se
familiarice con las estrategias de publicación y consumo de servicios web que se utilizan en el entorno
profesional.

Para ello se va a implementar la funcionalidad del servicio usando las dos tecnologías específicas diferentes
basadas en la arquitectura SOA que se han utilizado en la segunda práctica de la asignatura, y que están
asociadas a las tecnologías de servicios Web: SOAP y REST.

Creación y despliegue de servicios en Tomcat:

Un servlet es, en esencia, un programa escrito en código Java que se ejecuta en un servidor Web (por
ejemplo, Tomcat), y extiende sus funcionalidades, ofreciendo un servicio específico, de tal forma que el
servidor es capaz de detectar un tipo particular de solicitud e invocar al servlet para generar una respuesta
que pueda ser consumida por el cliente.

Un archivo WAR (Web application Archive) es básicamente un archivo JAR que se utiliza para empaquetar y
distribuir todos los archivos necesarios para construir una aplicación web. Dentro de un archivo WAR se
pueden empaquetar colecciones JSP, clases Java, servlets, archivos XML, bibliotecas de tags, páginas
HTML y archivos asociados. Una vez generado, el archivo WAR se puede guardar en una carpeta específica
dentro de Tomcat para que los servicios contenidos se desplieguen al levantar el contenedor Web, o se
puede desplegar una vez que dicho contenedor ya se está ejecutando utilizando el mánager de Tomcat.

Se deben desarrollar los siguientes elementos:

1) Al igual que ocurría en la segunda práctica de la asignatura, para la generación de nuestros servicios
web será necesario generar interfaces (como objetos POJO) que definan las operaciones de los
servicios. En el caso del servicio SOAP dicha interfaz deberá utilizar el API específico JAX-WS
(http://jax-ws.java.net/), mientras que para el servicio REST el API de referencia será JAX-RS
(http://jcp.org/en/jsr/detail?id=311):

- Interface para el servicio SOAP:

package es.uned.scc.grados.appdist.trabajos.ws;

import javax.jws.WebParam;
import javax.jws.WebService;

import es.uned.scc.grados.appdist.trabajos.signal.model.data.OperationInfo;
import es.uned.scc.grados.appdist.trabajos.signal.model.data.SignalData;
import es.uned.scc.grados.appdist.trabajos.signal.model.data.SignalParameters;

UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA 2

 |Dr. Andrés Duque Fernández, Dr. Rafael Pastor Vargas

@WebService
public interface SignalGeneratorWS {
public OperationInfo start();
public OperationInfo stop();
public OperationInfo isRunning();
public SignalData getSignalValue();
public SignalParameters getSignalParameters();
public void setSignalParameters(
@WebParam(name="signal_parameters")SignalParameters signal_parameters);

- Interface para el servicio REST:

package es.uned.scc.grados.appdist.trabajos.ws;

import es.uned.scc.grados.appdist.trabajos.signal.model.data.SignalData;
import es.uned.scc.grados.appdist.trabajos.signal.model.data.SignalParameters;
import es.uned.scc.grados.appdist.trabajos.signal.model.data.OperationInfo;

public interface RESTSignalGenerator {

public OperationInfo start();
public OperationInfo stop();
public OperationInfo isRunning();
public SignalData getSignalValue();
public SignalParameters getSignalParameters();
public void setSignalParameters(SignalParameters signal_parameters);
}

2) Igualmente, en ambos casos será necesario realizar una implementación de la interface

(SignalGeneratorWSImpl en el caso de SOAP y RESTSignalGeneratorWSImpl en el caso de
REST), que deberá estar incluida en el paquete es.uned.scc.grados.appdist.trabajos.ws.
Estas clases deberán emplear la clase SignalGeneratorThread (definida en el paquete
es.uned.scc.grados.appdist.trabajos.signal.model) para la gestión de la ejecución/parada
del generador aleatorio.
Sin embargo, dado que vamos a desplegar nuestros servicios web en un contenedor como Tomcat,
en este caso no será necesario implementar ninguna clase que desarrolle el servidor (contenedor del
servicio SOAP o REST) y lo publique para ser consumido por los clientes, ya que el propio
contenedor web se encargará de realizar esta función.
Véase el apartado de consideraciones de desarrollo para conocer cómo se debe realizar la
implementación de los servidores SOAP y REST.

3) También se deberán generar los clientes SOAP y REST que consuman cada uno de los servicios
correspondientes. En el caso de SOAP, la clase se deberá denominar WSClient y deberá estar
definida en el paquete es.uned.scc.grados.appdist.trabajos.ws.soap. En el caso de REST,
la clase se denominará RESTClient y deberá estar definida en el paquete
es.uned.scc.appdist.trabajos.rest.client. Véase el apartado de consideraciones de
desarrollo para obtener detalles sobre la generación del código que representa al servicio Web, y su
utilización en la clase cliente.

4) Generación del archivo WAR correspondiente a los servicios SOAP y REST y despliegue en Tomcat,
de tal manera que pueda ser consumido por los clientes SOAP y REST desarrollados en el apartado

UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA 3

 APLICACIONES DISTRIBUIDAS

anterior. Véase el apartado de consideraciones de desarrollo para obtener detalles sobre la

generación del archivo WAR y su despliegue en Tomcat, tanto en local como en la plataforma AWS.

Tanto en el servicio SOAP como en el servicio REST se utilizan las clases OperationInfo, SignalData y
SignalParameters, las cuáles se proporcionan en el espacio virtual del curso, y están implementadas en el
fichero SignalModel.jar.

IMPORTANTE: Ha de tenerse en cuenta que el servidor Tomcat se ejecuta sobre el puerto 8080, por lo
que será necesario asegurarse de que nuestros clientes hacen uso de dicho puerto a la hora de
definir la dirección a la que se conectan para consumir los servicios. Por tanto, la dirección del
servidor Tomcat instalado en local será http://localhost:8080, mientras que si utilizamos una máquina
externa proporcionada por AWS deberemos averiguar su dirección DNS pública para conectarnos a
la dirección http://PUBLIC_DNS:8080.

Cloud computing, AWS Educate y las instancias EC2 de AWS:

La computación en la nube o cloud computing es un concepto que engloba la oferta y el acceso a todo tipo
de recursos hardware y software aprovechando las posibilidades de conectividad y gran escala que nos
brinda Internet, democratizando la utilización de servidores, sistemas de almacenamiento de datos y solución
de aplicaciones de forma sencilla, con un acceso fácil y bajo demanda, y con buena seguridad y
mantenimiento.

En este contexto, Amazon Web Services (AWS) es una plataforma que proporciona una amplia gama de
servicios de infraestructura para su utilización profesional, como potencia de cómputo, almacenamiento,
redes o bases de datos. Dentro de su enorme oferta, para la realización de esta práctica es de especial
interés Amazon Elastic Compute Cloud (EC2), parte central de su plataforma basada en el alquiler de
computadoras virtuales (denominadas instancias) en las cuáles el cliente puede ejecutar sus aplicaciones.
Estas instancias presentan multitud de configuraciones hardware y software, por lo que el usuario puede
seleccionar aquéllas que mejor se adecuen a sus intereses particulares.

Además, AWS dispone también de la plataforma AWS Educate, a través de la cuál se ofrece gran parte de
los servicios de AWS a instituciones académicas para poder ser utilizadas de forma gratuita por los
educadores y estudiantes. Para esta asignatura, se ha creado una classroom de AWS Educate, la cuál se
utilizará a modo de laboratorio virtual en la nube, como un entorno de aprendizaje que ofrece una serie de
servicios que podrán ser utilizados por los estudiantes. A través de estas classroom los profesores pueden
invitar a los estudiantes a unirse, así como monitorizar su actividad. Se enviará una invitación por correo
electrónico a la cuenta UNED de estudiante para que se den de alta con dicha cuenta y puedan empezar
a utilizar los servicios ofrecidos.

Al acceder al enlace que encontraréis en el correo electrónico que AWS Educate enviará a los estudiantes
una vez aprobadas sus cuentas, podréis daros de alta en la plataforma. Para ello, el estudiante deberá
seleccionar “Universidad Nacional de Educacion a Distancia – Escuela Tecnica Superior de Ingeniería
Informática” en la parte de “Institution”, y rellenar sus datos personales:

UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA 4

 |Dr. Andrés Duque Fernández, Dr. Rafael Pastor Vargas

Figura 1: AWS Educate: Introducción de datos personales

El estudiante deberá introducir su nombre y apellido, mes y año de nacimiento, comprobar el correo
electrónico (utilizar siempre la cuenta de estudiante UNED) y seleccionar “Information Technology” como
área de conocimiento y “Undergraduate-Adv Courses” como tipo de estudios. También deberá indicar el mes
y año previsto de finalización de estudios (se trata únicamente de una estimación, no hace falta que sea
estricto).
En la siguiente pantalla deberá seleccionar como tipo de cuenta “AWS Educate Starter Account”:

Figura 2: AWS Educate: Tipo de cuenta

Una vez hecho esto se accederá a la pantalla que confirma la creación de la cuenta:

UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA 5

 APLICACIONES DISTRIBUIDAS

Figura 3: AWS Educate: Confirmación

El estudiante recibirá un nuevo correo electrónico para verificar su dirección. Una vez hecho esto, se
accederá a una página para aceptar los términos y condiciones de uso del servicio, y al aceptar las
condiciones aparecerá el siguiente mensaje:

Figura 4: AWS Educate: Revisión de la solicitud

AWS Educate revisará la solicitud de cuenta para dar acceso al estudiante, lo cuál puede tardar un día o
dos, por lo que se recomienda darse de alta en AWS Educate en cuanto se reciba el correo de
invitación, aunque el estudiante no vaya a empezar a trabajar con la plataforma en ese momento. Una
vez que AWS aprueba la cuenta, el estudiante podrá acceder a la misma (siempre utilizando la cuenta de
estudiante UNED) desde la dirección https://www.awseducate.com/signin/SiteLogin.

Para familiarizarse con la plataforma AWS Educate y con el proceso de lanzamiento de una instancia EC2 y
su configuración para alojar un servidor Tomcat, es necesario que el estudiante visualice los siguientes
vídeos subidos al canal de la asignatura:

UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA 6

 |Dr. Andrés Duque Fernández, Dr. Rafael Pastor Vargas
• AWS 1 (Crear una instancia EC2 en AWS): https://youtu.be/z-cCRA71nTY
• AWS 2 (Configurar la instancia EC2 para ejecutar Tomcat/CXF): https://youtu.be/OkZf52lteYo
• AWS 3 (Despliegue de la aplicación/servicios en TOMCAT/AWS): https://youtu.be/1Ceabi-lVKs

Más información sobre la instalación de Tomcat en Ubuntu 18.04 se puede encontrar en el siguiente enlace:
https://www.digitalocean.com/community/tutorials/install-tomcat-9-ubuntu-1804. En dicho enlace se describe
también la utilización del mánager de Tomcat para desplegar archivos WAR, lo cual puede ser una
alternativa a la transferencia del archivo y su almacenamiento en la carpeta webapps de Tomcat.

Por tanto, se pide la realización de la práctica en dos partes diferenciadas:

• Primera parte (6 puntos): En la primera parte, se deberán desarrollar los servicios Web descritos
anteriormente y, una vez empaquetados como archivo WAR, se deberán desplegar en local
utilizando un servidor Tomcat. Se deberán desarrollar y probar los clientes SOAP y REST que
consuman los servicios Web desarrollados y desplegados en local, a través de dicho servidor
Tomcat. Este servidor se puede ejecutar desde un entorno de desarrollo como Eclipse o puede
instalarse y ejecutarse directamente en la máquina.

• Segunda parte (4 puntos): En la segunda parte, se deberá lanzar y configurar una instancia EC2 de
AWS, para poder levantar en ella un servidor Tomcat que despliegue los servicios Web
empaquetados en nuestro archivo WAR. Se deberán desarrollar (modificando lo necesario en el
código) y probar los clientes SOAP y REST que consuman los servicios Web desplegados en la
instancia EC2.

Notas importantes:

• El estudiante debe recordar detener (stop) o terminar (terminate) la instancia EC2 que utilice
una vez que termine de trabajar con ella, siguiendo las acciones que se describen en los
vídeos mencionados anteriormente.

• Al utilizar la consola AWS (es decir, después de haber accedido a la classroom de AWS
Educate y pinchado sobre el botón “AWS Console” → ver a partir del minuto 3:40 del primer
vídeo), se debe comprobar que la región en la que se está trabajando es “us-east-1”: esto lo
podemos ver tanto en la dirección que indica el navegador como la pestaña de arriba a la
derecha, la cuál debe indicar “N. Virginia”. Si no fuese así, se ha de desplegar esta pestaña y
seleccionar “US East (N. Virginia)”.

Figura 5: Región de trabajo

UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA 7

 APLICACIONES DISTRIBUIDAS

2.- CONSIDERACIONES DE DESARROLLO

Para el desarrollo de esta parte, al igual que en la segunda práctica de la asignatura, se va a emplear
Apache CXF (http://cxf.apache.org/) ya que proporciona un entorno de ejecución e implementaciones de las
APIs, tanto de JAX-WS como de JAX-RS.

2.1 Detalles de desarrollo en la implementación de los objetos de servicio.

Se recomienda la utilización de Eclipse para la implementación del proyecto, ya que ofrece una
automatización de los procesos a realizar que facilitará en gran medida el desarrollo del mismo,
especialmente en lo que se refiere a la parte de servidor de los servicios web. Para ello, el proyecto ha de
ser de tipo “Dynamic Web Project”, y se deberá seleccionar la opción que permite crear el archivo “web.xml”,
en el que se indicarán las configuraciones necesarias para el despliegue de los servicios web.

El árbol del proyecto debería quedar más o menos de la siguiente manera:

Figura 6: Árbol del proyecto

Bajo Java Resources/src se almacenarán las interfaces de definición de los servicios web así como las
clases Java que implementen dichas interfaces. Los archivos .jar auxiliares, proporcionadas por el equipo
docente (SignalModel.jar y SignalPlot.jar) se pueden añadir bajo la carpeta WebContent/WEB-INF/lib.

Como podemos observar, bajo la carpeta WebContent/WEB-INF encontramos los dos ficheros de
configuración de los servicios web que tendremos que manejar: el fichero web.xml, que proporciona
información de configuración y despliegue sobre los servlets que se van a publicar, y el fichero cxf-
beans.xml (puede tener otro nombre, ya que su ruta se especifica en web.xml), que define la configuración
de los servicios propiamente dicha (puntos de acceso, publicación del fichero wsdl en el caso de SOAP,
etc.). Este fichero cxf-beans.xml se genera de forma automática si lanzamos un Web service basado en el
proyecto directamente desde Eclipse. Para ello, se debe seleccionar File → New → Web Service, e indicar
la clase en la que se define la implementación del servicio (por ejemplo,
es.uned.scc.grados.appdist.trabajos.ws.SignalGeneratorWSIMpl en el caso de SOAP). Es

UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA 8

 |Dr. Andrés Duque Fernández, Dr. Rafael Pastor Vargas
importante seleccionar como Web Service runtime “Apache CXF 2.x”, y por supuesto tener instalado un
servidor Tomcat en nuestra máquina.

El aspecto de los ficheros web.xml y cxf-beans.xml debería ser más o menos el siguiente:

Figura 7: Fichero web.xml

Podemos observar la declaración del servlet, que utiliza el Endpoint de Apache CXF, y el mapping que indica
la ruta relativa en la que se van a publicar los servicios (“/services/*”). Igualmente, se define el archivo en el
que se configuran los servicios propiamente dichos y su ruta (“WEB-INF/cxf-beans.xml”). Este archivo
web.xml se proporcionará en el espacio virtual (ALF) de la asignatura. Si utiliza dicho archivo (recuerde que
también se genera automáticamente al construir el proyecto como Dynamic Web Project en Eclipse), el
estudiante deberá mantener el nombre de su proyecto (en la etiqueta <display-name>), así como modificar,
si lo necesitase, el nombre y la ruta del archivo “cxf-beans.xml”.

UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA 9

 APLICACIONES DISTRIBUIDAS

Figura 8: Fichero cxf-beans.xml

En este fichero se define la configuración propiamente dicha de los servicios. Como podemos observar
tenemos un servicio SOAP (configuración de JAX-WS) y un servicio REST (configuración de JAX-RS). El
servicio SOAP deberá definir la localización del Endpoint, el implementor, la localización del archivo wsdl y la
dirección del servicio, mientras que en el caso del servicio REST simplemente se ha definido un bean que
apunta a la localización de la clase que implementa el servicio, para posteriormente apuntar a dicho bean en
la definición del servicio REST.

Como se ha indicado anteriormente, este archivo se puede generar automáticamente al lanzar el servicio
desde Eclipse, o se puede configurar manualmente.

Importante: Hay que tener en cuenta siempre los nombres que se utilizan para nombrar las clases y
las direcciones en las que se publican los servicios, para que no haya errores a la hora de acceder a
los mismos por parte de los clientes.

Una vez implementados y configurados los servicios Web, podremos exportar el proyecto como archivo WAR
(botón derecho sobre el proyecto, Export → WAR File). También es importante tener en cuenta el nombre
de nuestro archivo WAR, ya que Tomcat desplegará el servicio con dicho nombre. En resumen, es
fundamental que la nomenclatura que se hace sea congruente para evitar errores al publicar y acceder al
servicio.

2.2 Detalles de desarrollo en la implementación de los clientes SOAP y REST.

Los clientes SOAP y REST que se han de implementar son prácticamente similares a los implementados en
la segunda práctica de la asignatura. Las únicas diferencias que se han de tener en cuenta tienen que ver
con las rutas de publicación de los servicios en el servidor Tomcat (hay que recordar que Tomcat trabaja
sobre el puerto 8080), así como las rutas relativas que hayamos indicado en los ficheros web.xml y cxf-
beans.xml.

UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA 10

 |Dr. Andrés Duque Fernández, Dr. Rafael Pastor Vargas

2.3 Detalles de desarrollo en el despliegue de los servicios

Como ya se ha indicado anteriormente, el despliegue de los servicios se ha de realizar tanto de forma local
(dirección http://localhost:8080) como utilizando una instancia EC2 de AWS, de la que se tendrá que utilizar
su dirección DNS pública (dirección http://PUBLIC_DNS:8080). Las indicaciones de instalación de Tomcat
disponibles en los vídeos especificados en la sección 1 sirven perfectamente para la instalación de Tomcat
en local y para el despliegue de una aplicación.

Como se indica en dichos vídeos, el archivo WAR puede ser añadido a la carpeta “webapps” bajo la carpeta
de instalación de Tomcat, o puede desplegarse utilizando el mánager de Tomcat
(http://localhost:8080/manager), una vez definidos un usuario y contraseña para acceder a dicho mánager.
Para definir el usuario y contraseña se ha de modificar el archivo “tomcat-users.xml” tal y como se indica en
https://www.digitalocean.com/community/tutorials/install-tomcat-9-ubuntu-1804 (Step 7 – Configure Tomcat
Web Management Interface).

Una vez desplegados los servicios se puede comprobar si ambos están corriendo correctamente, añadiendo
la ruta (“/NOMBRE_SERVICIO/services/”) a las direcciones indicadas anteriormente (siempre que en el
fichero web.xml hayamos especificado “/services/*” como patrón URL para la publicación de los servicios).
Si el WAR se ha desplegado correctamente, deberíamos encontrar la siguiente pantalla:

Figura 9: Servicios disponibles en Tomcat

Como podemos observar, tenemos dos servicios corriendo bajo esa dirección: un servicio SOAP y un
servicio REST.

3.- PRUEBAS

Una vez desarrolladas las clases necesarias, se debe probar la ejecución de los servidores SOAP y REST,
tanto en local como en una instancia EC2 de AWS usando los desarrollos de los clientes SOAP y REST.

En ambos casos, se deberá levantar el servidor Tomcat y acceder a los servicios disponibles publicados
(como se muestra en la figura previa). El estudiante deberá capturar un pantallazo mostrando la misma
figura, en la que aparezca la información que el equipo docente ha ocultado.

En este punto, se debe comprobar que los servidores están ofreciendo los respectivos servicios, tomando
sendos pantallazos de:
1) SOAP Server. Pantallazo mostrado el fichero WSDL del servicio SOAP generado automáticamente.
2) REST Server. Pantallazo mostrado el fichero WADL del servicio SOAP generado automáticamente.
A continuación, se deben ejecutar los clientes, y si todo es correcto, se debería mostrar el interfaz gráfico
(GUI) desarrollado por el equipo docente y que permite probar la funcionalidad pedida:

UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA 11

 APLICACIONES DISTRIBUIDAS

Figura 10: Aspecto inicial del GUI de prueba

Para arrancar el generador de señales (es decir, llamar al método start() del objeto remoto) se debe pulsar el
botón correspondiente. En la siguiente figura se muestra una ejecución de una señal sinusoidal de
frecuencia 0.05 Hz y amplitud 10.

Figura 11: Ejemplo de ejecución del cliente

Pruebas a desarrollar (con ambos clientes, y tanto en local como en el servidor levantado en la instancia EC2
de AWS):

- Arrancar el cliente, usando el botón Start.

- Tomar un pantallazo de la GUI cuando el tiempo llegue al minuto (se deberá incluir en la
documentación)
- Cambiar la frecuencia de la señal a 0.1 (usando el botón Apply)
- Tomar un pantallazo de la GUI cuando el tiempo llegue a los dos minutos (se deberá incluir en la
documentación)
- Cambiar la amplitud de la señal a 5 (usando el botón Apply)
- Tomar un pantallazo de la GUI cuando el tiempo llegue a los dos minutos y medio (se deberá incluir
en la documentación)
- Cambiar el tipo de señal a triangular (usando el botón Apply)
- Tomar un pantallazo de la GUI cuando el tiempo llegue a los tres minutos (se deberá incluir en la
documentación)
- Cambiar el tipo de señal a cuadrada (usando el botón Apply)
- Tomar un pantallazo de la GUI cuando el tiempo llegue a los tres minutos y medio (se deberá incluir
en la documentación)
- Parar el generador, usando el botón Stop.

UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA 12

 |Dr. Andrés Duque Fernández, Dr. Rafael Pastor Vargas
- Cambiar el tipo de señal a sinusoidal, con una amplitud de 1 y una frecuencia de 10;

4.- INFORME

Como informe del trabajo se debe entregar un fichero zip en la pestaña de Evaluación del curso virtual en
aLF. El fichero debe llamarse “Nombre_Estudiante”.zip, donde Nombre_Estudiante debe contener el nombre
completo del estudiante, sin usar acentos y usando guiones bajos (_) en vez de espacios en blanco entre
nombre y apellidos.

En este fichero deben aparecer los siguientes ficheros/subdirectorios:

- Un fichero WAR denominado WS_Services.war que empaquete los servicios web SOAP y REST.
Dicho fichero deberá poder ser desplegado utilizando un servidor Tomcat tanto en local como en una
instancia de AWS EC2.
- Las clases de los clientes SOAP y REST compiladas y empaquetadas en
o WS_SOAP_Client.jar. Debe contener las clases correspondientes al cliente SOAP.
o WS_REST_Client.jar. Debe contener las clases correspondientes al cliente REST.

Tanto el fichero WAR como los ficheros JAR deben estar situados en el directorio lib del fichero zip.
Se deben incluir en dicho directorio todos los ficheros jar que se empleen en la ejecución de los
clientes SOAP y REST. En el caso de las librerías CXF, no es necesario incluirlas (debido al gran
tamaño que tienen), pero en los scripts de ejecución de los clientes se deberán referenciar en el
classpath con el path .\lib\apache-cxf-3.1.3\lib. De esta forma, para que el equipo docente pueda
probar la solución del estudiante, solo deberá copiar esas librerías a esa localización.

- Los ficheros fuentes de las clases generadas por los estudiantes durante el desarrollo, situados en el
directorio sources, manteniendo la estructura de paquetes (esto es, los subdirectorios asociados).

- Dos documentos en formato texto (puede ser word, txt o pdf), correspondientes a las dos partes de
la práctica (desarrollo y despliegue en local por una parte, y despliegue en la nube por otra) con la
arquitectura desarrollada y comentarios sobre los problemas encontrados durante el desarrollo y
prueba de los servidores/clientes SOAP/REST. Además, se deben incluir los
pantallazos/comentarios pedidos en la parte de pruebas. Estos documentos deben estar situados en
el directorio doc del fichero zip, y deberán indicar a qué parte de la práctica se refieren añadiendo al
final de su nombre (antes de la extensión) “_local” o “_cloud”, respectivamente. Por ejemplo, los
nombres de estos documentos pueden ser “Documentacion_local” y “Documentacion_cloud”.

- Guiones de trabajo (scripts) para poder ejecutar las aplicaciones cliente, tanto de SOAP como REST
(usando los ficheros jar del directorio lib). Estos scripts deben estar situados en la raíz del fichero
comprimido y deben considerar los paths relativos al subdirectorio lib al ejecutar dichos scripts
(tenga en cuenta, además, el path relativo a las librerías CXF y adicionales). Es importante
proporcionar, para cada servicio Web (SOAP o REST), un script relativo a su conexión con un
servidor instalado en local, o con un servidor instalado en la nube, en una instancia EC2. Al igual que
en el punto anterior, el script deberá indicar en su nombre si se refiere a un cliente de un servidor
local (añadir “_local” a su nombre) o a un cliente de un servidor en la nube (añadir “_cloud” a su
nombre). Por ejemplo, los nombres de estos scripts podrían ser “run_SOAP_client_local.bat” y
“run_SOAP_client_cloud.bat” para el servicio SOAP, y “run_REST_client_local.bat” y
“run_REST_client_cloud.bat” para el servicio REST.

UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA 13

 APLICACIONES DISTRIBUIDAS

Muy importante: Se ha de tener en cuenta que en el caso de los clientes que se conectan a un
servidor levantado sobre una instancia EC2, la dirección DNS pública variará para cada
instancia. Ya que no es posible que las instancias se queden levantadas hasta que el equipo
docente evalúe las prácticas, el estudiante ha de proporcionar un mecanismo (por ejemplo, a
través de parámetros que reciba el cliente Java por consola) que permita indicar la dirección
DNS pública de la instancia a la que se ha de conectar. Así mismo, se deberá indicar cómo se
ha resuelto este aspecto y la forma de utilizar el cliente, así como cualquier otra
consideración que el estudiante estime necesaria en un fichero Readme.txt, que se deberá
incluir también en la raíz del fichero comprimido.

UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA 14