Sunteți pe pagina 1din 14

GRADO

PRUEBA DE EVALUACIN CONTINUA


APLICACIONES DISTRIBUIDAS
WS | ENUNCIADO Y ORIENTACIONES PARA SU DESARROLLO

2012-2013

|Dr. Rafael Pastor Vargas


GRADO EN INGENIERA EN TECNOLOGAS DE LA INFORMACIN
UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIA

APLICACIONES DISTRIBUIDAS

1.- OBJETIVOS
La segunda parte consiste en realizar un sistema distribuido basado en tecnologa de servicios Web que
permita ejecutar un generador de seales y obtener los valores de tiempo y calculados por dicho generador.
Para ello se va a implementar la funcionalidad del servicio usando dos tecnologas especficas diferentes
basadas en la arquitectura SOA, y que estn asociadas a las tecnologas se servicios Web:
-

Servicios SOAP. Fue el primer estndar para publicar y consumir servicios Web. Es un estndar
basado en XML, y todos los mensajes involucrados en el proceso de uso/bsqueda/consumo/gestin
de procesos estn basados en el estndar SOAP (http://www.w3.org/TR/soap/). En el caso de Java,
existe un API especfico denominado JAX-WS (http://jax-ws.java.net/) que permite procesar la
informacin SOAP de los mensajes sin necesidad de un directorio de servicios. Este API fue
diseado originalmente por Sun (ahora Oracle) e implementada en su pila de servicios Web llamada
Metro (http://metro.java.net/)
Para el proceso de desarrollo, se puede partir de varias premisas a la hora de desarrollar un servicio
pero la ms habitual es partir de una clase/interface que implemente/defina las operaciones que
publicar el servicio Web (a esta clase/interface se le denomina POJO, Plain Old Java Object).
Posteriormente, se deben aadir anotaciones a la clase para indicar el comportamiento del servicio
Web.
Las
anotaciones
(http://devel.noip.org/programming/languages/java/tutorial/java/javaOO/annotations.html)
permiten
aadir
informacin al cdigo Java sin interferir en el propio cdigo. Esta informacin puede ser usada por
otros elementos en el proceso de desarrollo de cdigo java (el propio compilador) para aadir
elementos ejecutables (cdigo adicional, ficheros XML, etc.) a la aplicacin. En el caso de JAX-WS,
las anotaciones permiten definir, entre otras cosas, que interface/clase define al servicio web
(@WebService) o qu mtodos conforman el conjunto de operaciones del servicio (@WebMethod).
Por tanto, una vez desarrollada la clase que implementan las operaciones del servicio, se proceder
a anotar la clase para indicar las propiedades del servicio SOAP. Para una revisin completa de las
anotaciones disponibles en JAX-WS, se debe consultar el siguiente enlace: http://jax-ws.java.net/jaxws-ea3/docs/annotations.html
El procedimiento de desarrollo es bastante directo, pero puede ocurrir que los parmetros de las
operaciones puedan ser elementos complejos, como clases definidas por el usuario. En este caso es
necesario definir un mapeo de las clases de usuario a un formato XML que se pueda usar desde
SOAP (recuerde que SOAP es bsicamente XML). Para esto se emplea JAXB, que es un API de
procesamiento XML que permite hacer este trabajo automticamente, mediante anotaciones. Para
ms detalles, se debe leer el siguiente enlace:
http://ingmmurillo.blogspot.com.es/2010/08/utilizacion-de-jaxb-para-mapear-clases.html
Para la parte prctica, se va a definir una interface que define las operaciones del servicio JAX-WS
(como un objeto POJO):
package es.uned.scc.grados.appdist.trabajos.ws;
import javax.jws.WebParam;
import javax.jws.WebService;

UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIA

|Dr. Rafael Pastor Vargas


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;
@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);
}

Se puede observar que la interface, define el servicio Web y dispone de una anotacin especial para
nombrar el argumento de la operacin setSignalParameters().
-

Servicio REST. Al contrario que SOAP, REST (REpresentational State Transfer) no es un protocolo,
sino una forma ms simple que SOAP para crear servicios Web (ms bien, se puede decir que es
una arquitectura de desarrollo). Fue ideada por el Dr. Roy Fielding en su tesis doctoral, y
bsicamente consiste en emplear el modelo de comunicacin web tradicional (el protocolo HTTP)
para identificar/consumir servicios Web. Un servicio web creado sobre los principios de REST se
denomina servicio web RESTful. Igual que antes, para el caso de Java, existe un API de referencia
para la implementacin de dichos servicios: JAX-RS (http://jcp.org/en/jsr/detail?id=311). Existen
varias implementaciones de este API, por ejemplo el contenedor Jersey (http://jersey.java.net/) entre
otros. Se recomienda leer los siguientes enlaces para comprender los fundamentos de REST:
http://www.infoq.com/articles/rest-introduction
http://eamodeorubio.wordpress.com/2010/07/26/servicios-web-2-%C2%BFque-es-rest/
http://www.fing.edu.uy/inco/grupos/lins/seminario/2010/Introduccion_WS-REST.pdf
Bsicamente REST (http://www.dosideas.com/noticias/java/314-introduccion-a-los-servicios-webrestful.html) sigue cuatro principios de diseo fundamentales:
- Se emplean los mtodos HTTP de manera explcita para realizar las operaciones del servicio,
que manejan recursos:
o POST para crear un recurso en el servicio
o GET para obtener un recurso
o PUT para cambiar el estado de un recurso o actualizarlo
o DELETE para borrar un recurso
- No mantiene el estado de las peticiones
- Expone las operaciones del servicio como URIs (modelo general de identificacin de recursos,
el cual la especificacin de URL es la ms conocida y usada).
- Permite la transferencia de cualquier tipo de informacin codificada en varios formatos: texto,
XML, JavaScript Object Notation (JSON), etc.
Al igual que JAX-WS, JAX-RS dispone de sus propias anotaciones para definir el contrato del
servicio y las operaciones/recursos que ofrece. Para ms detalles, consultar el enlace de la
implementacin de referencia Jersey: http://jersey.java.net/nonav/documentation/latest/jax-rs.html,
donde se explican todas las anotaciones del estndar con ejemplos de su uso.

UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIA

APLICACIONES DISTRIBUIDAS
Las anotaciones ms importantes son:
o @Path, define el URI relativo de acceso al servicio/operacin
o @Method, define el mtodo HTTP de acceso a la operacin
o @Produces, define el formato de informacin que el servicio/operacin enviar en la llamada
al mtodo HTTP correspondiente (texto, JSON, XML, etc.)
o @Consumes, define el formato de informacin que el servicio/operacin espera en los
parmetros de la invocacin al mtodo HTTP correspondiente (texto, JSON, XML, etc.).
Para esta parte prctica, se va a definir una interface que define las operaciones del servicio JAX-RS
(como un objeto POJO), a cuya implementacin se le debern aadir las anotaciones JAX-RS
correspondientes:
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);
}

En las dos interfaces se usan las clases OperationInfo, SignalData y SignalParameters, y al igual que
en la parte anterior, se proporcionan en el espacio virtual del curso, y estn implementadas en el fichero
SignalModel.jar.
Se deben desarrollar los siguientes elementos:
1) Implementacin de la interface del servicio SOAP (JAX-WS) definida anteriormente (se debe
mantener tanto el nombre, como el paquete donde est definida dicha interface). La clase que
implementa dicha interface se debe denominar SignalGeneratorWSImpl y debe estar incluida en el
paquete es.uned.scc.grados.appdist.trabajos.ws. La clase que implementa el servicio SOAP
debe
emplear
la
clase
SignalGeneratorThread
(definida
en
el
paquete
es.uned.scc.grados.appdist.trabajos.signal.model) para la gestin de la ejecucin parada
del generador aleatorio. Vase el apartado de consideraciones de desarrollo para conocer cmo se
debe realizar la implementacin del objeto de servicio SOAP.
2) Desarrollo de un servidor que acte como contenedor del servicio SOAP y exponga dicho servicio
para ser consumido por clientes. La clase que implementa dicho servidor se debe llamar WSServer y
debe estar ubicada en el paquete es.uned.scc.grados.appdist.trabajos.ws.server. Vase
el apartado de consideraciones de desarrollo para conocer cmo se debe realizar la implementacin
del servidor SOAP.
3) Desarrollo de un cliente que consuma los servicios definidos por la clase que implementa el servicio
y que estar disponible a travs del servidor del punto 2. La clase se deber denominar WSClient y
deber estar definida en el paquete es.uned.scc.grados.appdist.trabajos.ws.soap. Vase el
apartado de consideraciones de desarrollo para obtener detalles sobre la generacin del cdigo que
representa al servicio Web, y su utilizacin en la clase cliente.

UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIA

|Dr. Rafael Pastor Vargas


4) Implementacin de la interface del servicio REST definida anteriormente (se debe mantener tanto el
nombre, como el paquete donde est definida dicha interface). La clase que implementa dicha
interface se debe denominar RESTSignalGeneratorWSImpl y debe estar incluida en el paquete
es.uned.scc.grados.appdist.trabajos.ws. La clase que implementa el servicio REST debe
emplear
la
clase
SignalGeneratorThread
(definida
en
el
paquete
es.uned.scc.grados.appdist.trabajos.signal.model) para la gestin de la ejecucin parada
del generador aleatorio. Vase el apartado de consideraciones de desarrollo para conocer cmo se
debe realizar la implementacin del objeto de servicio REST.
5) Desarrollo de un servidor que acte como contenedor del servicio REST y exponga dicho servicio
para ser consumido por clientes. La clase que implementa dicho servidor se debe llamar y
RESTWSServer
debe
estar
ubicada
en
el
paquete
es.uned.scc.grados.appdist.trabajos.ws.server. Vase el apartado de consideraciones de
desarrollo para conocer cmo se debe realizar la implementacin del servidor REST.
6) Desarrollo de un cliente que consuma los servicios definidos por la clase que implementa el servicio
REST y que estar disponible a travs del servidor del punto 5. La clase se deber denominar
RESTClient y deber estar definida en el paquete es.uned.scc.appdist.rest.client. Vase el
apartado de consideraciones de desarrollo para obtener detalles sobre el uso del protocolo HTTP
para el consumo de los recursos/operaciones del servicio REST.

2.- CONSIDERACIONES DE DESARROLLO


Para el desarrollo de esta parte, se va a emplear Apache CXF (http://cxf.apache.org/) ya que proporciona un
entorno de ejecucin e implementaciones de las APIs, tanto de JAX-WS como de JAX-RS. En particular, se
recomienda que se lean los ejemplos que estn ubicados en la documentacin del producto:
1) Escribir/Publicar/Consumir un servicio JAX-WS con CXF (http://cxf.apache.org/docs/a-simple-jax-wsservice.html)
2) Conceptos bsicos de JAX-RS (http://cxf.apache.org/docs/jax-rs-basics.html)
Otros enlaces interesantes que se deben revisar, son los siguientes:
http://www.javamexico.org/blogs/mariogarcia/servicios_web_con_apache_cxf_utilizando_jaxws_y_jaxrs
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=jaxwscxf (incluye la configuracin de CXF
en Eclipse y como crear clientes de servicios web a travs de su WDSL).
Es importante descargarse la distribucin CXF (la versin empleada es la 2.6.2, pero debera funcionar con
cualquiera superior) desde la web de cxf: http://cxf.apache.org/download.html. Para la compilacin/ejecucin
de los elementos de esta parte, hay que aadir los ficheros jar correspondientes a esta distribucin (o
configurar el IDE de manera adecuada).
2.1 Detalles de desarrollo en la implementacin del objeto de servicio SOAP.
Como se ha comentado anteriormente, se debe usar la clase SignalGeneratorThread para desarrollar el
objeto que implementa el servicio SOAP (JAX-WS). Esta clase y la clase SignalGenerator asociada estn
incluidas en el fichero SignalModel.jar. Se proporciona en el entorno virtual el cdigo de ambas clases
(SignalGeneratorThread, SignalGenerator).
La clase que implementa el servicio se denomina SignalGeneratorWSImpl, y debe tener las anotaciones
necesarias para marcar la clase como un servicio Web. Al implementar la interface correspondiente (que ya
est anotada como @WebService) automticamente se define como servicio Web, pero es necesario aadir

UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIA

APLICACIONES DISTRIBUIDAS
el cdigo asociado para identificar el punto de publicacin del servicio Web (que permite conocer su WDSL, y
el punto de invocacin de las operaciones por parte del cliente). De nuevo, es necesario usar las
anotaciones de JAX-WS para indicar esto. Las anotaciones permiten la herencia, as que podemos redefinir
la anotacin e indicar un conjunto de propiedades de la anotacin. En este caso, se necesita indicar que
interface define el conjunto de operaciones del servicio (propiedad endpointInterface) y el nombre a
travs del cual se acceder al servicio (serviceName). Por tanto, se deber aadir la anotacin a la clase
SignalGeneratorWSImpl, quedando la definicin de la clase as:
@WebService(endpointInterface =
"es.uned.scc.grados.appdist.trabajos.ws.SignalGeneratorWS",
serviceName = "SignalGenerator")
public class SignalGeneratorWSImpl implements SignalGeneratorWS {

Las implementaciones de los mtodos de la interface SignalGeneratorWS se debern realizar de manera


equivalente a la parte anterior desarrollada.
2.2 Detalles de desarrollo en la implementacin del servidor SOAP.
En el caso del servidor SOAP, es muy sencillo usar las funcionalidades de CXF para que ejecute un
contenedor de servicios JAX-WS, y publique en una URL conocida el servicio. El cdigo necesario (que se
puede encontrar en la documentacin de CXF) es el siguiente.
SignalGeneratorWSImpl implementor = new SignalGeneratorWSImpl(sampleTime);
String address = "http://localhost:9000/SignalGenerator";
Endpoint.publish(address, implementor);

Se puede ver que solo se necesita indicar la direccin de publicacin (address) y la clase que implementa el
servicio SOAP (se le pasa al constructor de la clase el tiempo asociado a la tarea definida en la clase
SignalGeneratorThread, pero el estudiante puede desarrollarlo de otra forma). Igual que se ha hecho
anteriormente, el servidor SOAP debe quedar ejecutndose. Para ello se puede usar un mecanismo de
entrada/salida que compruebe si el servidor debe parar o no.
Al ejecutar el servidor SOAP, deberan mostrarse unas lneas parecidas a estas:
Starting Server
28-nov-2012 21:23:55 org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass
INFO: Creating Service {http://ws.trabajos.appdist.grados.scc.uned.es/}SignalGenerator
from class es.uned.scc.grados.appdist.trabajos.ws.SignalGeneratorWS
28-nov-2012 21:23:55 org.apache.cxf.endpoint.ServerImpl initDestination
INFO: Setting the server's publish address to be http://localhost:9000/SignalGenerator
28-nov-2012 21:23:56 org.eclipse.jetty.server.Server doStart
INFO: jetty-7.5.4.v20111024
28-nov-2012 21:23:56 org.eclipse.jetty.server.AbstractConnector doStart
INFO: Started SelectChannelConnector@localhost:9000 STARTING
28-nov-2012 21:23:56 org.eclipse.jetty.server.handler.ContextHandler startContext
INFO: started o.e.j.s.h.ContextHandler{,null}
Server ready...
Enter 'yes' to exit...

Una vez que el servidor SOAP est ejecutndose, se debera poder visualizar el documento WDSL de
definicin del servicio en el siguiente enlace: http://localhost:9000/SignalGenerator?wsdl

UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIA

|Dr. Rafael Pastor Vargas


En la siguiente figura se puede ver el contenido del fichero WDSL.

2.3 Detalles de desarrollo en la implementacin del cliente SOAP.


El primer paso para desarrollar el cliente SOAP es obtener la representacin del servicio como clases Java.
Para ello, se debe usar el enlace de acceso al fichero WDSL y usar alguno de los siguientes mecanismos:
1) Usar los asistentes del IDE de desarrollo para generar las clases que representan al servicio. Puede
consultar los siguientes enlaces para ver como se hace en Eclipse
(http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.jst.ws.cxf.doc.user%2Ftasks%2Fcreate
_client.html) o Netbeans (http://netbeans.org/kb/docs/websvc/jax-ws.html, seccin Consuming the
Web Service, Client 1: Java Class in Java SE Application).
2) Usando la utilidad wdsl2java que viene con la distribucin de CXF. Se pueden ver las opciones de
las que dispone la utilidad en el siguiente enlace: http://cxf.apache.org/docs/wsdl-to-java.html. Este
comando generar las clases Java necesarias (que representan al servicio Web) que se deben
incorporarse al proyecto en el que se defina el cliente (importndolas o copindolas directamente en
el directorio donde se ubiquen las fuentes dl proyecto).
Se recomienda el uso de la primera opcin, ya que genera las clases dentro del propio proyecto. Una vez
que se han generado las clases, para poder usar el servicio web se debe usar la clase Proxy generada, que
se debera llamar SignalGeneratorWSProxy. Simplemente se debe instanciar y llamar al mtodo adecuado.
// Get service reference
SignalGeneratorWS service = new SignalGeneratorWSProxy();
OperationInfo info = service.start();

UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIA

APLICACIONES DISTRIBUIDAS
Para probar el funcionamiento del servidor SOAP, de nuevo, se debe emplear la clase auxiliar ClientGUI
incorporndola en el cdigo del cliente SOAP (mediante las clases que sean necesarias). Recurdese que,
para emplear esta funcin, es necesario que la clase cliente (o una auxiliar) implemente la interface
ClientPlot. El procedimiento es similar al desarrollado en la parte anterior.
2.4 Detalles de desarrollo en la implementacin del objeto de servicio REST.
Como se ha comentado anteriormente, se debe usar la clase SignalGeneratorThread para desarrollar el
objeto que implementa el servicio REST (JAX-RS). Esta clase y la clase SignalGenerator asociada estn
incluidas en el fichero SignalModel.jar. Se proporciona en el entorno virtual el cdigo de ambas clases
(SignalGeneratorThread, SignalGenerator).
La clase que implementa el servicio se denomina RESTSignalGeneratorWSImpl, y debe tener las
anotaciones necesarias para marcar la clase como un servicio REST. En este caso, la implementacin
asociada a la clase RESTSignalGeneratorWSImpl, debe definir las funciones de la interface y por tanto hay
que anotar las operaciones como URIs usando la anotacin @Path, definir que mtodo se usar para
invocar la operacin (@GET, @POST, @PUT, @DELETE) y que informacin consumir/producir
(@Consumes, @Produces). En la siguiente tabla se muestra cuales son los valores de las anotaciones para
las operaciones.
Opracin/Recurso

@Path

Mtodo @Consumes @Produces


HTTP

OperationInfo start();

@Path("start")

OperationInfo stop();

@Path("stop")

@Get

OperationInfo isRunning();

@Path("isrunning")

@Get

SignalData getSignalValue();

@Path("get")

@Get

SignalParameters
getSignalParameters();
void
setSignalParameters(SignalPara
meters signal_parameters);

@Path("getParams")

@Get

@Path("setParams")

@Post

@Get

No es
indicarlo
No es
indicarlo
No es
indicarlo
No es
indicarlo
No es
indicarlo
No es
indicarlo

necesario

@Produces({"text/xml"})

necesario

@Produces({"text/xml"})

necesario

@Produces({"text/xml"})

necesario

@Produces({"text/xml"})

necesario

@Produces({"text/xml"})

necesario

@Produces({"text/xml"})

Finalmente, es necesario anotar el @Path asociado al propio servicio (todos los @Path definidos en las
operaciones son relativos al @Path del servicio). Para ello se debe aadir al principio de la definicin de la
clase, la siguiente anotacin:
@Path("SignalGenerator")
public class RESTSignalGeneratorWSImpl implements RESTSignalGenerator{

De esta forma, para invocar la operacin start() del servicio REST se deber usar el siguiente URI relativo:
SignalGenerator/start. En la siguiente seccin, una vez desarrollado el servidor, se vern ejemplos de URIs
absolutas para el uso del servicio REST.
2.5 Detalles de desarrollo en la implementacin del servidor REST.
La creacin del servidor REST con CXF es muy sencilla, y consiste en cuatro pasos sencillos, que se
comentan a continuacin:

UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIA

|Dr. Rafael Pastor Vargas


// Create the JAX-RS Server with CXF
JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
// Set REST implementor class
sf.setResourceClasses(RESTSignalGeneratorWSImpl.class);
// Create absolute Path
sf.setAddress("http://localhost:9002/");
// Start JAX-RS Server
sf.create();

Por tanto, solo es necesario codificar la clase RESTWSServer con un mtodo main() que contenga las lneas
anteriores. Al arrancar el servidor REST deberan mostrarse las lneas de informacin sobre el servidor,
generadas por CXF (Jetty):
29-nov-2012 16:13:28 org.apache.cxf.endpoint.ServerImpl initDestination
INFO: Setting the server's publish address to be http://localhost:9002/
29-nov-2012 16:13:28 org.eclipse.jetty.server.Server doStart
INFO: jetty-7.5.4.v20111024
29-nov-2012 16:13:28 org.eclipse.jetty.server.AbstractConnector doStart
INFO: Started SelectChannelConnector@localhost:9002 STARTING
29-nov-2012 16:13:28 org.eclipse.jetty.server.handler.ContextHandler startContext
INFO: started o.e.j.s.h.ContextHandler{,null}

Una vez que se ejecute el servidor REST, se pueden invocar las operaciones del servicio usando cualquier
cliente HTTP (por ejemplo, un navegador web). Una sesin de trabajo tpica sera:
1) Arrancar el generador de seales: http://localhost:9002/SignalGenerator/start

2) Obtener el valor de la seal: http://localhost:9002/SignalGenerator/get

3) Comprobar si el generador est ejecutndose: http://localhost:9002/SignalGenerator/isrunning

4) Parar el generador de seales: http://localhost:9002/SignalGenerator/stop

UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIA

APLICACIONES DISTRIBUIDAS

5) Comprobar el estado del generador: http://localhost:9002/SignalGenerator/isrunning

2.6 Detalles de desarrollo en la implementacin del cliente REST.


Cualquier servicio REST se puede consumir usando un cliente Web, esto es, un cliente que permite realizar
operaciones HTTP. CXF dispone de una clase denominada WebClient, que permite al desarrollador no
tener que ocuparse de los detalles de implementacin del protocolo HTTP y le facilita el desarrollo de
clientes REST. La clase WebClient est definida en el paquete org.apache.cxf.jaxrs.client. y se
pueden ver un ejemplo de uso en el siguiente enlace: http://cxf.apache.org/docs/jax-rs-client-api.html
(seccin CXF WebClient API).
Para obtener los valores de los resultados complejos (se entienden por complejos, las clases Java definidas
por el desarrollador distintas a los tipos primitivos de java) de las invocaciones a los mtodos REST, es
necesario
usar
la
clase
ResponseReader
(ubicada
en
el
paquete
org.apache.cxf.jaxrs.client.ResponseReader). Esta clase es la responsable de representar el
resultado obtenido de una invocacin REST como una entidad XML (que es lo que enva el mtodo de
servicio, al ser anotado para producir XML). Una vez que se dispone de esa entidad XML, se puede convertir
a un objeto de la clase correspondiente haciendo una conversin directa (cast). Para usar ambas clases
(WebClient y ResponseReader) es necesario instanciar dos objetos asociados en cada clase, de la
siguiente forma:
ResponseReader reader = new ResponseReader();
WebClient client = WebClient.create(REST_SERVICE,Collections.singletonList(reader));

donde
REST_SERVICE
representa
el
(http://localhost:9002/SignalGenerator).

punto

de

publicacin

del

servicio

Una vez hecho esto (en el constructor de la clase cliente o en la propia definicin de los atributos de dich
clase), se deben implementar los diferentes mtodos que se invocarn desde la interface GUI proprocionada.
A modo de ejemplo, se muestra el cdigo asociado a una de esas funciones y como se realiza la invocacin
REST y la obtencin del dato de la invocacin con el objeto OperationInfo (proporcionado en el curso virtual).
public boolean startGenerator(){
// Set the class associated to the incoming XML entity form REST service

UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIA

10

|Dr. Rafael Pastor Vargas

reader.setEntityClass(OperationInfo.class);
// Set relative path to REST method
// REST_PATH_START = "start";
client.replacePath(REST_PATH_START);
// Set type of data received
client.type("application/xml");
// Call the REST method
Response r = client.get();
// Get the XML entity in response and cast to class
OperationInfo i = (OperationInfo)r.getEntity();
System.out.println("Response: " + i.getMessage());
return i.isOk();

La estructura del cdigo para el resto de mtodos del cliente son similares, y se debe modificar lo necesario
adaptndolo a la estructura del mtodo REST del servidor (la clase esperada y el @PATH del mtodo,
bsicamente).
Para probar el funcionamiento del servidor REST, de nuevo, se debe emplear la clase auxiliar ClientGUI
incorporndola en el cdigo del cliente REST (mediante las clases que sean necesarias). Recurdese que,
para emplear esta funcin, es necesario que la clase cliente (o una auxiliar) implemente la interface
ClientPlot. El procedimiento es similar al desarrollado en apartados anteriores.

3.- PRUEBAS
Una vez desarrolladas las clases necesarias, se debe probar la ejecucin de los servidores SOAP y REST,
usando los desarrollos de los clientes SOAP y REST. A continuacin se muestra el ejemplo desarrollado por
el equipo docente, que se encuentra disponible en el entorno virtual.
En primer lugar se debe ejecutar el servidor, tal y como se muestra en la siguiente figura.

Ejecucin de los servidores SOAP y REST

UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIA

11

APLICACIONES DISTRIBUIDAS

Si todo es correcto, debera mostrar un mensaje indicando que est disponible para gestionar conexiones de
clientes (tal y como aparece en la figura anterior). En este punto, se debe comprobar que los servidores
estn ofreciendo los respectivos servicios, tomando sendos pantallazos de los
1) SOAP Server. Pantallazo mostrado el fichero WSDL del servicio SOAP generado automticamente
(http://localhost:9000/SignalGenerator?wsdl)
2) REST Server. Pantallazos de una sesin de trabajo (descritos al final del apartado 2.5).
A continuacin se deben ejecutar los clientes, tal y como se muestra en la siguiente figura.

Figura 3. Ejecucin de los clientes SOAP y REST.

Si todo es correcto, debera mostrar el interface grfico (GUI) desarrollado por el equipo docente (en ambos
caos) y que permite probar la funcionalidad pedida. Se puede ver el aspecto inicial en la figura 4.

Figura 4. Aspecto inicial del GUI de prueba.

Para arrancar el generador de seales (es decir, llamar al mtodo start() del objeto remoto) se debe pulsar el
botn correspondiente. En la figura 5 se muestra una ejecucin de una seal sinusoidal de frecuencia 0.05
Hz y amplitud 10.

Figura 5. Ejemplo de ejecucin del cliente.

UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIA

12

|Dr. Rafael Pastor Vargas


Pruebas a desarrollar (con ambos clientes):
- Arrancar el cliente, usando el botn Start.
- Tomar un pantallazo de la GUI cuando el tiempo llegue al minuto (se deber incluir en la
documentacin)
- Cambiar la frecuencia de la seal a 0.1 (usando el botn Apply)
- Tomar un pantallazo de la GUI cuando el tiempo llegue a los dos minutos (se deber incluir en la
documentacin)
- Cambiar la amplitud de la seal a 5 (usando el botn Apply)
- Tomar un pantallazo de la GUI cuando el tiempo llegue a los dos minutos y medio (se deber incluir
en la documentacin)
- Cambiar el tipo de seal a triangular (usando el botn Apply)
- Tomar un pantallazo de la GUI cuando el tiempo llegue a los tres minutos (se deber incluir en la
documentacin)
- Cambiar el tipo de seal a cuadrada (usando el botn Apply)
- Tomar un pantallazo de la GUI cuando el tiempo llegue a los tres minutos y medio (se deber incluir
en la documentacin)
- Parar el generador, usando el botn Stop.
- Cambiar el tipo de seal a sinusoidal, con una amplitud de 1 y una frecuencia de 10;
- Arrancar el generador, usando el botn Start.
- Comprobar el efecto del slider inferior del GUI modificando los valores y utilizando los valores
mximo (1 segundo), mnimo (0.1 segundos) y medio (aproximadamente 0.5 segundos). Intentar
explicar cul es el efecto que produce en la representacin de la onda y porque ocurre.
- Parar el generador, usando el botn Stop.

4.- INFORME
Cmo informe del trabajo se debe entregar un fichero zip en la pestaa de Evaluacin del curso virtual en
aLF. El fichero debe llamarse Nombre_Alumno.zip, donde Nombre_Alumno 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:
-

Las clases compiladas y empaquetadas en tres ficheros jar:


o WS_Services.jar. Debe contener las clases correspondientes a los servidores SOAP y
REST.
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.
Deben estar situados en el directorio lib del fichero zip. Se deben incluir en dicho directorio, todas
los ficheros jar que se empleen en la ejecucin de los servidores/clientes SOAP y REST. En el caso
de las libreras CXF, no es necesario incluirlas (debido al gran tamao que tienen), pero en los
scripts de ejecucin se debern referenciar en el classpath con el path .\lib\apache-cxf-2.6.2\lib. De
esta forma, para que el equipo docente pueda probar la solucin del alumno, solo deber copiar
esas libreras a esa localizacin.

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

UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIA

13

APLICACIONES DISTRIBUIDAS
-

Documento en formato texto (puede ser word, txt o pdf) con la arquitectura desarrollada y
comentarios sobre los problemas encontrados durante el desarrollo y prueba de los
servidores/clientes SOAP/REST. Adems se deben incluir los pantallazos/comentarios pedidos en la
parte de pruebas. Este documento debe estar situado en el directorio doc del fichero zip.

Guiones de trabajo (scripts) para poder ejecutar las aplicaciones cliente y servidor, tanto de SOAP
como REST (usando los ficheros jar del directorio lib). Estos scripts deben estar situados en la raz
del fichero comprimido y deben considerar los paths relativos al subdirectorio lib al ejecutar dichos
scripts (tenga en cuenta adems, el path relativo a las libreras CXF y adicionales).

UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIA

14