La primera vez que un programador se enfrenta a la tarea de tener que realizar un servicio web (en adelante WS, Web Service) se suele encontrar un poco perdido. Normalmente se recurre a internet o a algún libro especializado. El problema es que son tantas las tecnologías con las que se puede desarrollar un WS, y son tantos los tipos de WS que existen, protocolos y demás, que a no ser que alguien ayude pueden pasar horas hasta que el programador obtenga el resultado deseado.
En mi caso he desarrollado muchos WS en distintos lenguajes como java, python y php; y distintas tecnologías, como XMLRPC, SOAP, MAVEN, AXIS, AXIS2… y os comento que me he encontrado con muchos problemas, siendo algunos de ellos de solución muy compleja.
Desde hace un tiempo sigo mi propia metodología para realizar WS. En realidad lo que os voy a contar no es de mi propia cosecha, sino que fue una gran aportación de un amigo (JT). Evidentemente yo hice mis cambios y lo adapté a mi forma de trabajar, pero sirvan estos posts como agradecimiento.
Durante cuatro posts, este inclusive, voy a contar lo que es un WS. No voy a hacer como muchos libros que profundizan tanto en los detalles que no se sabe por donde cogerlos, sino que voy a ir al grano. La estructura a seguir será la siguiente:
- En este primer post, daré una explicación light de lo que es un WS y comentaré el ejemplo que realizaré.
- En el segundo post programaré una aplicación “productor”.
- El tercer post será un ejemplo de manejo de la interfaz de eclipse para obtener datos del “productor”.
- El cuarto y último post lo usaré para crear un “cliente” y una aplicación que use dicho “cliente”.
Así pues, que comience el espectáculo:
¿Qué es un Web Service?
Para responder a esta pregunta, me remito a la descripción dada en la Wikipedia: Un servicio web (en inglés, Web services) es una tecnología que utiliza un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden utilizar los servicios web para intercambiar datos en redes de ordenadores como Internet. La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la arquitectura y reglamentación de los servicios Web. Para mejorar la interoperabilidad entre distintas implementaciones de servicios Web se ha creado el organismo WS-I, encargado de desarrollar diversos perfiles para definir de manera más exhaustiva estos estándares. Es una máquina que atiende las peticiones de los clientes web y les envía los recursos solicitados.
¿Y esto que significa?
Imaginemos la siguiente situación: Tenemos una aplicación (llamada A) que almacena datos de películas. Dicha aplicación sólo está accesible vía web, y queremos que otra aplicación distinta (llamémosla B) muestre los datos de la aplicación A. En este ejemplo la aplicación A se llama productor, ya que produce los datos, y la aplicación B se llama consumidor o cliente.
Para que la aplicación A pueda compartir los datos, es necesario que publique un archivo de descripción del servicio. Dicho archivo debe estar bien formado y contiene una descripción de los métodos que acepta el WS, y de los datos que utiliza tanto si son de llamada como de retorno. Además si dichos datos son clases propias de la aplicación, también deben estar descritas en el archivo. A dicho archivo se le denomina WSDL (Web Services Description Language). En realidad esto es una verdad a medias, puesto que los tipos de datos no son necesarios que estén. Lo que pasa es que si el WSDL está completo el cliente se puede generar de forma automática, ya sea con maven, con eclipse o con cualquier otra aplicación que lo permita. Si no lo estuviera es requisito indispensable que el programador que va a realizar el cliente conozca a la perfección los tipos de datos, etc.
Como podéis imaginar realizar este archivo a mano resulta una tarea tediosa, ya que cualquier error en el mismo hace que no funcione, y para colmo estos errores son difíciles de localizar. Ahora pensad, si hacer un simple xsd es complicado, imaginad un super xsd, es decir, un WSDL.
Sigamos con la teoría. Tenemos una aplicación productora que además de producir datos, publica un archivo que describe que operaciones se pueden realizar con ella. Pues lo que nos quedaría sería leer dicho archivo, y generar una aplicación que sea capaz de usar los métodos y los datos definidos en el WSDL. La aplicación productora a su vez publica una url a la que conectaremos el cliente, y así las dos aplicaciones se comunicarán y pasarán información entre ellas.
Diagrama de funcionamiento de un WS
En resumen:
El productor publica un archivo WSDL que describe como interactuar con él, y además dispone de una url para poder realizar dicha interacción.
El cliente interactúa con el productor y muestra los datos en su aplicación. El WSDL sirve para generar las clases y llamadas a métodos que usará el cliente.
En el próximo post realizaremos una aplicación que será el productor del WS.
Saludos.
