Desarrollar un webservice desde WSDL con Axis2

July 24, 2007

Siguiendo con el motor de webservices Axis2, en esta ocasión toca hablar sobre cómo desarrollar un webservice. Logicamente existen diversas formas de desarrollar un webservice, en el siguiente texto voy a contar cómo desarrollar un webservice siguiendo la metodología conocida por WSDL to Java y qué ventajas reporta. Antes permitidme introduciros brevemente en el mundo de los webservices.

Presentaciones
Un webservice o servicio web es una aplicación modular, auto-contenida, auto-descriptiva, sin estado y accesible a través de Internet. Su objetivo es la interoperabilidad entre aplicaciones, con un mínimo acoplamiento e independientemente de la tecnología con la que hayan sido desarrolladas.

webservices

Para lograr la interoperabilidad, aparte de basarse en estándares, un webservice se comunica mediante mensajes XML utilizando el protocolo SOAP. El interfaz de un webservice se describe en un documento XML utilizando el estándar WSDL. En este fichero, que recibe el mismo nombre WSDL, se definen los detalles de cómo usar un webservice, como las operaciones, el formato de los mensajes, el tipo y el protocolo de transporte del webservice.

El WSDL es, por tanto, básico a la hora de crear un cliente para un webservice y debería ser cuidadosamente diseñado. Un buen diseño evitará problemas de interoperabilidad aunque se empleen tecnologías diferentes a la del webservice para crear los clientes. Por ello, debería ser de máxima importancia durante el desarrollo de un webservice.

Empezando la casa por el tejado
Sin embargo, y descartando la opción de parsear los XML a pelo, es habitual encontrarse con un enfoque radicalmente contrario. Partiendo de la implementación de la lógica del webservice (una clase Java) se genera de forma automática el WSDL correspondiente. El nombre de este método es Java to WSDL. Pero al seguirlo estamos condicionando la interoperabilidad del webservice a la bondad de la herramienta empleada para generar el WSDL. A cambio se facilita el desarrollo (ahora incluso con anotaciones) del webservice.

Este enfoque funciona bien para servicios web realmente sencillos, con métodos de pocos parametros de tipo básico. Pero puede (casi seguro) dar problemas de interoperabilidad en webservices con mensajes complejos si se usan tecnologías distintas (aunque sean del mismo lenguaje) para el webservice y los clientes. No se puede obviar que diferentes herramientas generan diferentes WSDLs a partir de la misma clase Java…

Otra desventaja de usar este enfoque es que estamos haciendo al interfaz del webservice depender de la implementación. Adiós abstracción entonces. Si mañana cambia la implementación es más que posible que deba cambiar el interfaz (WSDL) y, por tanto, también todos los clientes que se hubieran creado. Además habremos perdido el control sobre el diseño del interface del webservice, en realidad la cara de todo servicio web, lo que todo el mundo que va a ver y donde merece la pena emplear tiempo para que sea lo más amigable y comprensible.

El camino
La alternativa que en este tutorial se propone es actuar justo al revés y de forma más natural. Primero se define el interfaz del webservice, es decir, el WSDL, donde se describen las operaciones, el formato de los mensajes, el tipo y protocolo de comunicación. Entonces se generan de forma automática las clases Java que implementan tanto el esqueleto del webservice como sus mensajes. Este método se llama WSDL to Java.

No sólo es más natural el orden de hacer las cosas, primero el interfaz, luego la implementación. También es mucho más natural y ágil describir los mensajes XML del webservice usando schemas XML en vez de clases Java. Otras ventajas son evitar los posibles efectos colaterales en la interoperabilidad sufridos por la generación automática del WSDL, y no perder el control sobre su diseño.

En realidad, y como veremos, crear un WSDL no es tan complicado, mientras no vayamos la primera vez en plan comando con un editor de textos básico. Tranquilidad, porque además no hace falta empollarse la especificación del W3C, sólo un buen IDE y tener claros un par de conceptos. No me enrollo más. Allá vamos!

(more…)