Tabla de Contenidos

Creación de servicios con la técnica Top-down

— PEDRO DELGADO YARZA 2014/02/18 14:20

Para crear un servicio web propio el primer paso es diseñar el WSDL y los ficheros XSD necesarios para definir todas sus funcionalidades y tipos de datos. Este paso se puede realizar haciendo uso de los editores dispuestos en el IDE (Eclipse) para tal fin.

Antes de comenzar la creación de un servicio web, hemos de decir que dichos servicios se exponen en la ruta nombredelproyecto/services.

Creación del servicio web

Una vez tengamos diseñados dichos ficheros deberemos situarlos en la carpeta generacion→servicios_web→resources

Una vez creados los ficheros modificamos el fichero build.properties ajustando las siguientes propiedades: 

#Variables para GENERACION DE SERVICIOS WEB - JAX-WS -  SOAP
ws.wsdl.file=ConversorDivisa.wsdl
ws.ns.to.package.1=org.umu.atica.wservices

A su vez el uso de la propiedad ws.ns.to.package.1 nos permite mapear las urn concretas que contiene el WSDL a los paquetes que queramos para oganizar mejor el código. Un ejemplo de esto sería: 

#Namespaces y paquetes JAVA asociados:
# Namespace to package (1). Formato: namespace=NombrePaqueteJava
ns.to.package.1=urn:umu:eadmin:servicios:archivo=atica.umu.servicios.archivo
# Namespace to package (2). Formato: namespace=NombrePaqueteJava
ns.to.package.2=urn:umu:eadmin:servicios:archivo:esquema=atica.umu.servicios.archivo.esquema

Tras configurar el fichero lanzamos la tarea Ant que nos generará el servicio Web ws.WSDLToJavaWebService.generate la cual creará las clases y estructuras necesarias junto con un fichero plantilla de implementación del servicio que tendremos que rellenar con la lógica que queramos dar a cada método, el nombre del fichero de implementación será Nombre del servicio web+“Impl”.

Todas estas clases se generan en la carpeta build del directorio servicios_web.

Una vez generado el código, lo copiamos dentro de nuestro proyecto web junto con el WSDL que hemos creado que estará contenido en la carpeta wsdl del directorio WEB-INF de nuestro módulo web. Una vez listo debemos modificar el fichero sun-jaxws.xml situado en el directorio WEB-INF de nuestro módulo web, para añadir el punto de acceso (end-point) a nuestro servicio web.

Un ejemplo sería el siguiente: 

<?xml version="1.0" encoding="UTF-8"?>
<endpoints 
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/jax-ws/ri/runtime http://java.sun.com/webservices/docs/2.0/jaxws/sun-jaxws.xsd"
    xmlns="http://java.sun.com/xml/ns/jax-ws/ri/runtime" version="2.0">
 
    ...
 
    <endpoint name="ConversorDivisa"    
        implementation="org.umu.atica.wservices.ConversorDivisaImpl" 
        url-pattern="/services/ConversorDivisa" 
        wsdl="WEB-INF/wsdl/ConversorDivisa.wsdl"/>
 
</endpoints>

Tras dar de alta el end-point en este fichero el servicio web estará accesible cuando despleguemos el servidor.

Servicios web seguros

Si queremos que nuestro servicio web implemente algún tipo de seguridad, el proceso de creación será similar al anterior solo que tenemos que tener en consideración los requisitos que implicará el tipo de seguridad que queramos aplicar.

Para conocer en mayor profundidad cómo implementar un mecanismo de seguridad en nuestro servicio web podemos consultar esta guía: WS-Security in Metro

En esta guía se nos explica qué componentes se han de añadir a nuestros ficheros de configuración del servicio web: 

<!-- Definimos el tipo de validacion por usuario y contraseña -->
<wsp:PolicyReference xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"	URI="#UsernameToken" />
<wsp:Policy wsu:Id="UsernameToken" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
	xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
	<wsp:ExactlyOne>
		<wsp:All>
			<sp:SupportingTokens
				xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
				<wsp:Policy>
					<sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-ecuritypolicy/200702/IncludeToken/AlwaysToRecipient" />
				</wsp:Policy>
			</sp:SupportingTokens>
 
			<wsss:ValidatorConfiguration
				wspp:visibility="private" xmlns:wsss="http://schemas.sun.com/2006/03/wss/server"
				xmlns:wspp="http://java.sun.com/xml/ns/wsit/policy">
				<wsss:Validator name="usernameValidator" classname="org.umu.atica.secure.wservices.ValidadorWS" />
			</wsss:ValidatorConfiguration>
		</wsp:All>
	</wsp:ExactlyOne>
</wsp:Policy>

Un ejemplo de clase Java que actúa de validador: 

public class ValidadorWS implements PasswordValidator {
 
	@Override
	public boolean validate(
			com.sun.xml.wss.impl.callback.PasswordValidationCallback.Request request)
			throws PasswordValidationException {
		PasswordValidationCallback.PlainTextPasswordRequest ptreq = (PasswordValidationCallback.PlainTextPasswordRequest) request;
                ...
                ...
		return resultadoDeValidación;
	}
 
}

Una vez hecho esto, nuestro servicio web tendrá una política de validación definida que nos permitirá asegurar que sólo determinados clientes acceden a nuestro servicio.

Referencias