Teoría básica de los WEBSERVICES
El siguiente artículo no lo trataremos de forma tan práctica como con otros anteriores.
Por lo tanto no consideraremos este texto como un tutorial sino como un artículo debido a que creemos que puede ser, de cualquier forma, de vuestro interés.
Es habitual el bombardeo por medio de páginas, spam, publicidad, banners… de términos ingleses muy novedosos que ni siquiera conocen quienes hablan de ellos.
1.- ¿Qué es un WebService?
La traducción literal de WebService es servicio web, con lo que podremos imaginar por donde irán los tiros. No son más que aplicaciones que proveen de datos Y/O servicios a otras aplicaciones. Se trata de un sistema de comunicación (que sigue unos estándares básicos basados en XML) entre diferentes servidores.
Dichas aplicaciones se encuentran “empaquetadas” en la red y contienen una colección de funciones. Cualquier aplicación puede acceder a un servicio web sin importar en que plataforma resida el servicio o en que lenguaje haya sido desarrollado. Para entenderlo de una manera sencilla, imagina la cada día más clásica tienda virtual. Si buscamos en la web encontraremos rápidamente WebServices que ofrecen un intercambio directo entre la tienda virtual y la entidad bancaria.
Otros ejemplos serían el caso de Amazon.com, que permite acceder directamente a sus servicios manejando el “carrito de la compra” o Google, el cuál puede invocar la búsqueda directamente usando una API.
El acceso a los servicios web suele ser vía http o https, ésta última mucho más segura. Sin embargo, los WS también pueden funcionar bajo los protocolos FTP, SMTP o TCP.
El uso de los WebServices (a partir de ahora WS), asegurarán pues, una interoperabilidad entre sistemas. Es de suma importancia analizar los beneficios que supone el uso de los WS ya no sólo para desarrolladores (que se liberarán de la tarea de desarrollar software propio), sino también para empresas (que permitirán que los desarrolladores dediquen su tiempo a enfocarse en el valor añadido de la compañía reduciendo así costes).
También podríamos hacer una descripción algo más técnica del término; se trata de una interface que se encuentra entre el código de aplicación y el código del usuario.
Todo esto está muy bien y es muy interesante pero, ¿como se invoca un WS?
2.-Invocación de los WS
Dichas aplicaciones se encuentran “empaquetadas” en la red y contienen una colección de funciones. Cualquier aplicación puede acceder a un servicio web sin importar en que plataforma resida el servicio o en que lenguaje haya sido desarrollado. Para entenderlo de una manera sencilla, imagina la cada día más clásica tienda virtual. Si buscamos en la web encontraremos rápidamente WebServices que ofrecen un intercambio directo entre la tienda virtual y la entidad bancaria.
Otros ejemplos serían el caso de Amazon.com, que permite acceder directamente a sus servicios manejando el “carrito de la compra” o Google, el cuál puede invocar la búsqueda directamente usando una API.
El acceso a los servicios web suele ser vía http o https, ésta última mucho más segura. Sin embargo, los WS también pueden funcionar bajo los protocolos FTP, SMTP o TCP.
El uso de los WebServices (a partir de ahora WS), asegurarán pues, una interoperabilidad entre sistemas. Es de suma importancia analizar los beneficios que supone el uso de los WS ya no sólo para desarrolladores (que se liberarán de la tarea de desarrollar software propio), sino también para empresas (que permitirán que los desarrolladores dediquen su tiempo a enfocarse en el valor añadido de la compañía reduciendo así costes).
También podríamos hacer una descripción algo más técnica del término; se trata de una interface que se encuentra entre el código de aplicación y el código del usuario.
Todo esto está muy bien y es muy interesante pero, ¿como se invoca un WS?
2.-Invocación de los WS
La invocación se basa en 4 capas: Descubrimiento (protocolo UDDI), descripción (protocolo WSDL), invocación (protocolo XML/SOAP) y transporte (protocolo TCP/SMTP/HTTP).
Capa 1 - Descubrimiento / Discovery: Se trata de obtener el WS que cumpla los requerimientos que “andamos buscando”. Por ejemplo, un WS que nos devuelve la población de cada una de las provincias de un país.
Capa 2 - Descripción / Description: Ahora que ya hemos localizado el servicio en la red, deberemos saber cómo invocarlo para obtener los resultados deseados. En el caso de que queramos saber los habitantes de Barcelona, ¿qué método deberemos utilizar; getBarcelona(), getPoblacion(String: ciudad,…)?
Capa 3 - Invocación / Packaging: Deberemos llamar al método correspondiente utilizando los parámetros correspondientes. Para ello se utiliza el protocolo SOAP, como norma general.
Capa 4 - Transporte / Transport: Se encarga del transporte de datos (respuesta) entre servidores.
3.-Creación y puesta en marcha de un WS
Como hemos comentado anteriormente, un WS puede es independiente de la plataforma y del código que se haya empleado. Sin embargo, el WS deberá ser publicado para que posteriormente pueda ser “descubierto”. Esto se realizará mediante un documento WSDL. El WS además será necesario que se publique en el registro UDDI, que no es más que una base de datos de WS.
WSDL, SOAP, UDDI… ¿como funciona cada protocolo?
Todos y cada uno de los protocolos se basan en el estándar XML.
a) SOAP (Simple Object Access Protocol): Este protocolo define un mecanismo para el paso de instrucciones (comandos) y parámetros entre clientes y servidores. Independiente tanto del modelo de datos, como del lenguaje de programación utilizado y de la plataforma.
b) WSDL (Web Services Description Language): Este protocolo indica qué operaciones puede realizar el WS, dónde se ubica, cómo se invoca…) WSDL describe un servicio como una colección de puertos (“communication endpoints”) capaces de intercambiar mensajes, pudiendo describir en forma abstracta operaciones y mensajes, prescindiendo de las especificaciones de protocolo y tipo de datos.
WSDL vincula las descripciones abstractas a una implementación concreta de protocolos y tipos de datos, permitiendo la reutilización de las definiciones abstractas. Este documento se puede crear de forma manual o utilizando alguna aplicación que lo genere de forma automática, como podría IBM Web Services Toolkit o Apache WebServices Toolkit.
c) UDDI (Universal Description Discovery and Integration): Este protocolo permite que se listen, busquen y descubran este tipo de software. Podríamos llegar a compararlo con las clásicas páginas amarillas.
WSDL, SOAP, UDDI… ¿como funciona cada protocolo?
Todos y cada uno de los protocolos se basan en el estándar XML.
a) SOAP (Simple Object Access Protocol): Este protocolo define un mecanismo para el paso de instrucciones (comandos) y parámetros entre clientes y servidores. Independiente tanto del modelo de datos, como del lenguaje de programación utilizado y de la plataforma.
b) WSDL (Web Services Description Language): Este protocolo indica qué operaciones puede realizar el WS, dónde se ubica, cómo se invoca…) WSDL describe un servicio como una colección de puertos (“communication endpoints”) capaces de intercambiar mensajes, pudiendo describir en forma abstracta operaciones y mensajes, prescindiendo de las especificaciones de protocolo y tipo de datos.
WSDL vincula las descripciones abstractas a una implementación concreta de protocolos y tipos de datos, permitiendo la reutilización de las definiciones abstractas. Este documento se puede crear de forma manual o utilizando alguna aplicación que lo genere de forma automática, como podría IBM Web Services Toolkit o Apache WebServices Toolkit.
c) UDDI (Universal Description Discovery and Integration): Este protocolo permite que se listen, busquen y descubran este tipo de software. Podríamos llegar a compararlo con las clásicas páginas amarillas.
No hay comentarios:
Publicar un comentario