BROADCASTS.com

Hoy te hablamos de una tecnolog\xeda que utiliza un conjunto de protocolos y est\xe1ndares facilitando el intercambio de informaci\xf3n entre sistemas. Estos sistemas o aplicaciones pueden estar programados en diferentes lenguajes de programaci\xf3n y funcionando en diferentes sistemas operativos. Hoy hablaremos de qu\xe9 son los servicios web.

Y como siempre, recuerda que tenemos activa la encuesta para los oyentes. Cualquier duda nos la puedes hacer llegar a trav\xe9s del formulario de contacto, por Twitter y Facebook. Y si quieres estar al d\xeda de las novedades de nuestra web la lista de distribuci\xf3n te est\xe1 esperando.

Antes de meternos en materia te queremos comunicar de una noticia que ha salido a principios de diciembre. Swift, el lenguaje de programaci\xf3n de Apple, ha sido liberado por fin. Tras el anuncio en la keynote de principios de a\xf1o, Apple a decidido compartir el c\xf3digo para la plataforma Linux.

Swift es un lenguaje de prop\xf3sito general, enfocado a desarrollar aplicaciones para m\xf3viles (iOS) y sobre mesa o port\xe1tiles (Mac OSX). Se puede considerar el hom\xf3logo de C# de Microsoft.

Pero, \xbfqu\xe9 quiere decir esto? en principio esto supondr\xeda que no necesitamos tener un Mac para programar aplicaciones para los sistemas operativos de Apple. Es un gran adelanto debido a que hasta d\xeda de hoy, solo si ten\xedas un Mac pod\xedas programar para sus plataformas. Veremos cuando est\xe1 disponible para Windows, si alg\xfan d\xeda lo est\xe1, para poder desarrollar aplicaciones Apple en Windows.

Si quieres saber m\xe1s sobre este lenguaje puedes acceder a los siguientes enlaces:

Web oficial
C\xf3digo fuente
Repositorio GitHub
Bueno pues comentada la noticia de esta semana, sigamos con el tema que nos lleva a este cap\xedtulo, los servicios web.

Un poco de historia

Los servicios web surgieron a principios de los a\xf1os 90, gracias a la r\xe1pida evoluci\xf3n de Internet, de las LAN y las WAN. En la d\xe9cada de los 80 se crearon muchas aplicaciones con diferentes lenguajes de programaci\xf3n y en sistemas operativos distintos. Surgi\xf3 la necesidad de intercambiar informaci\xf3n entre dichos sistemas y gracias a esto, surgieron los servicios web dando soluci\xf3n a este problema.

LAN (Local Area Network) red de \xe1rea local, una red que abarca un \xe1rea reducida como una oficina o una casa.

WAN (Wide Area Network) red de \xe1rea amplia, una red que engloba varias redes LAN y varias ubicaciones f\xedsicas. Si una LAN es una casa de un edificio, una WAN podr\xeda ser la red formada por todas esas redes LAN, el propio edificio.

Los servicios web pretenden solucionar el problema de intercambio de informaci\xf3n entre aplicaciones. Su nombre viene dado debido a que fueron dise\xf1ados para residir en un servidor web. La invocaci\xf3n de estos servicios suele ser a trav\xe9s de HTTP o HTTPS, es la forma m\xe1s com\xfan, esto nos asegura que pueda ser llamado por cualquier aplicaci\xf3n que tenga un puerto HTTP/HTTPS abierto, vamos, casi cualquier m\xe1quina.

En la actualidad se utiliza para multitud de aplicaciones como dispositivos m\xf3viles, webs, cloud computing, mantenimiento c\xf3digo heredado o legado, etc...

\xbfQu\xe9 es un servicio web?

Podemos describir un servicio web de forma t\xe9cnica como un componente de software que es accesible a trav\xe9s de la red. Engloba varias tecnolog\xedas aunque en s\xed mismo no podemos catalogarlo como una tecnolog\xeda. Yo dir\xeda que es m\xe1s bien un m\xe9todo o una forma de poder intercambiar informaci\xf3n a trav\xe9s de protocolos y de est\xe1ndares como, XML, HTTP, SOAP, REST y WSDL. Hablaremos m\xe1s detenidamente de estos t\xe9rminos m\xe1s adelante.

Los servicios web nos permiten dise\xf1ar software modular, software dividido en m\xf3dulos siendo m\xe1s mantenible y manejable, y servicios distribuidos en diferentes m\xe1quinas conectadas en red.

La clave de los servicios web es la interoperabilidad, el intercambio de informaci\xf3n entre sistemas sin importar el sistema operativo, el dispositivo o el lenguaje de programaci\xf3n. Un servicio web tiene un funcionamiento parecido al de un sitio web. Si en la web tradicional la respuesta del servidor es un archivo HTML, f\xe1cilmente entendible por los humanos, en los servicios web este archivo es un XML o un formato del tipo JSON, f\xe1cilmente entendible por las m\xe1quinas. Por este motivo los servicios web tambi\xe9n se conocen como la web para m\xe1quinas.

Caracter\xedsticas principales de los servicios web

La finalidad de los servicios web es la transmisi\xf3n de datos entre sistemas distintos, esto se puede hacer de muchas maneras pero, para que se considere un servicio web debe cumplir ciertas caracter\xedsticas.

Debe ser accesible a trav\xe9s de la red o Internet, normalmente mediante los protocolos HTTP.
La codificaci\xf3n de los mensajes deben ser en un lenguaje est\xe1ndar como XML o JSON.
Debe contener una descripci\xf3n de s\xed mismo para que cualquier aplicaci\xf3n pueda consumirlo de una forma autom\xe1tica.
Debe poder ser localizado y disponer de un mecanismo para encontrarlo de una manera autom\xe1tica.
Tipos de servicios web

Existen dos grandes tipos de servicios web SOAP y REST. Los dos cumplen las caracter\xedsticas especificadas anteriormente.

SOAP (Simple Object Access Protocol) Se trata de un protocolo de comunicaci\xf3n est\xe1ndar, bajo el amparo de la W3C, que define como se deben comunicar dos sistemas a trav\xe9s de archivos XML. Este protocolo puede ser utilizado de dos maneras diferentes seg\xfan convenga:

Mensajes orientados al documento. Este tipo de comunicaci\xf3n comparte la informaci\xf3n entre dos o m\xe1s aplicaciones a trav\xe9s de ficheros XML.
Mensajes orientados a RPC (Remote Procedure Calls), llamadas a procedimientos remotos. Es un mecanismo que permite invocar m\xe9todos, funciones o procedimientos de aplicaciones a trav\xe9s de un sistema de mensajes. Se env\xeda un mensaje que tiene el nombre del procedimiento junto con los par\xe1metros. La respuesta de la invocaci\xf3n del procedimiento se env\xeda al cliente a trav\xe9s de otro mensaje.
Este protocolo estipula los mensajes SOAP con una estructura definida. Se pueden consultar las especificaciones t\xe9cnicas que ofrece la W3C.

Para ver un ejemplo puedes ir a esta p\xe1gina web, ver\xe1s un mensaje SOAP t\xedpico y la respuesta por parte del servidor.

Una de las caracter\xedsticas de los servicios web es que tienen que tener la capacidad de ser descritos para que autom\xe1ticamente puedan ser invocados. Esto se hace a trav\xe9s del lenguaje de programaci\xf3n WDSL (Web Services Description Language) lenguaje de descripci\xf3n de servicios web. Este lenguaje describe los requisitos del protocolo y los formatos de los mensajes. Un ejemplo lo puedes encontrar aqu\xed.

El punto fuerte de los servicios web SOAP es la seguridad, esto es lo que le hace diferente a los servicios web REST que veremos a continuaci\xf3n.

REST (Representational State Transfer) Transferencia de estado representacional, tambi\xe9n llamados RESTful, es una arquitectura de software para sistemas distribuidos. Al igual que SOAP, tambi\xe9n permite el env\xedo de mensajes orientados al documento y mensajes orientados a RPC. Son servicios web m\xe1s f\xe1ciles que usar y se suele decir que es la manera \xe1gil de crear servicios web por su sencillez.

Este tipo permite el intercambio de diferentes formatos de archivos est\xe1ndar como XML y JSON. Sirve para obtener datos y para ejecutar operaciones sobre ellos. Se suelen utilizar a trav\xe9s del protocolo HTTP o HTTPS.

Se dice que este tipo de servicios est\xe1 orientado a los recursos. Normalmente cada recurso tiene asignado una URI donde accedemos. La respuesta es en los formatos ya mencionados XML o JSON, son los m\xe1s t\xedpicos aunque no los \xfanicos.

Un ejemplo puede ser la API de Spreaker, el hosting de nuestros cap\xedtulos del podcast. Por ejemplo, si quieres obtener la informaci\xf3n de nuestra cuenta en formato JSON solo tienes que acceder aqu\xed, esto ser\xeda un recurso. Si quieres obtener un listado de todos los episodios del pocast puedes acceder aqu\xed.

Como puedes comprobar en los enlaces anteriores, la informaci\xf3n presentada es poco legible para el ser humano pero, cr\xe9eme que para una m\xe1quina resulta muy sencillo.

Conclusi\xf3n

Los servicios web son un recurso muy importante cuando estamos trabajando con una aplicaci\xf3n que tiene versiones en diferentes plataformas (Windows, Mac OSX, Linux, Android o iOS) y dispositivos (m\xf3vil, tablet, web, desktop, Arduino oRaspberry Pi).

No hay un lenguaje espec\xedfico para crear servicios web, existen diferentes APIs, frameworks, librer\xedas y herramientas que nos facilitan esta tarea.

Si lo que realmente importa es la seguridad, SOAP es la soluci\xf3n, es m\xe1s complejo pero es m\xe1s seguro. Si por el contrario lo que necesitas es algo sencillo y escalable, es recomendable utilizar REST.

Por \xfaltimo no puedo dejar pasar la oportunidad de hacer menci\xf3n a WCF (Windows Communication Foundation) es un framework para la creaci\xf3n de aplicaciones orientadas a servicios. De esto hablaremos en otro cap\xedtulo de nuestro podcast.

Recurso del d\xeda

SoapUI

SoapUI es una soluci\xf3n multiplataforma de c\xf3digo abierto para testear y hacer pruebas funcionales con los servicios web de tu aplicaci\xf3n. Soporta los est\xe1ndares SOAP y REST. Gracias a su interfaz gr\xe1fica podr\xe1s automatizar la bater\xeda de pruebas que te asegure el buen funcionamiento de tu sistema. Si todav\xeda tu servicio web no est\xe1 creado, podr\xe1s simular su comportamiento a trav\xe9s de mocks gracias al MockServices. Tambi\xe9n incluye un sistema de informes bastante completo para obtener los reportes en PDF, HTML, Word o Excel.

Muchas gracias a todos por los comentarios y valoraciones que nos hac\xe9is en iVoox, iTunes y en Spreaker, nos dan mucho \xe1nimo para seguir con este proyecto.