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.

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:

ws.wsdl.file: Nos permite indicar la ruta local del fichero wsdl que queremos generar.
ws.ns.to.package.1: Nombre del paquete en el que queremos encapsular las clases Java que se generen.

#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.

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:

<wsp:PolicyReference>: Nos permite establecer la política de seguridad que queremos implementar.

<!-- 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>: Configura los parámetros de la política de seguridad que implementamos. Dentro de esta última debemos destacar una propiedad:
- <wsss:ValidatorConfiguration>: Configura cómo vamos a validar las peticiones a nuestro servicio web. Para ello nos permite definir validadores, haciendo uso del tag <wsss:Validator> donde mapeamos el validador a una clase Java de nuestro proyecto.

<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.

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

Creación del servicio web

Servicios web seguros

Referencias