Web services

INTRODUCCIÓN A LOS SERVICIOS WEB
Por azuluaga

En este artículo veremos qué es un servicio Web, por qué se destacan entre otras tecnologías y las características de su funcionamiento.
Antes de empezar de lleno con el tema, es necesario que veamos algunos conceptos un tanto simples para algunos, pero definitivamente necesarios.
Esos temas se refieren a RPC, sistemas distribuidos, XML, entre otros. Si consideras que ya conoces sobre el tema, puedes pasarlo por alto y empezar en por qué los servicios web.

1.LOS SISTEMAS DISTRIBUIDOS
Más o menos generalizando un sistema distribuido es aquel donde existen varios computadores cada uno con su procesador independiente de los demás, los cuales se comunican utilizando mensajes por la red.
En palabras más claras, un sistema distribuido nos permite tener varias máquinas para ejecutar el mismo proceso o ejecutar varios con el mismo fin y así entregar resultados mucho más rápido o permitir a una máquina concentrarse en las peticiones y dejar a otras el “trabajo pesado”. Pero esta definición puede ser bastante incompleta. Si se quiere saber más sobre sistemas distribuidos es mejor buscar en textos especializados o en la red. Quizá me anime y haga un artículo completo sobre el tema.

Veamos algunas de las características de un sistema distribuido:
Existen por lo menos dos computadores con procesadores independientes capaces de realizar procesos enfocados hacia el mismo objetivo.
La comunicación se hace por medio de una red (puede ser privada o por Internet) utilizando protocolos estándar o propietarios (claro, funcionando bajo los propios protocolos de la red).
Un sistema distribuido puede utilizar diferentes programas creados en el mismo o en diferentes lenguajes (es ahí donde nos detendremos).
La comunicación entre las máquinas puede ser sincrónica o asíncrona.
Los sistemas distribuidos se pueden usar para aprovechar el procesamiento en paralelo o las utilidades desarrolladas en diferentes lenguajes, plataformas, sistemas operativos, etc.
La idea es que no se necesita una máquina que funcione como servidor, sino que se puedan comunicar entre ellas sin tener que pasar por un sitio común.
Bueno, espero que quede más o menos claro lo que es un sistema distribuido; sino, no te preocupes que apenas estamos comenzando y esto es tan solo un acercamiento.

Existen muchas formas de hacer computación distribuida, muchas empresas tienen sus propias implementaciones, también hay grupos que se han preocupado por crear un modelo estándar que permita la comunicación entre esas diferentes tecnologías. Veamos algunas de ellas.

DCOM (Distributed Component Object Model)
La tecnología de Microsoft para comunicar aplicaciones hechas en sus lenguajes, tiene la gran ventaja de los productos Microsoft: es supremamente sencillo de usar, el programador no necesita profundizar en temas de protocolos para utilizarlo y el equipo Microsoft se esforzó por hacer transparente al cliente la ubicación de los objetos con que trabaja.

RMI (Remote Method Invocation)
Esta es la tecnología que utiliza java para comunicar aplicaciones entre sí. Es una tecnología de SUN Microsystems para invocar métodos y transportar objetos java.
A diferencia de otras tecnologías, RMI solo sirve para comunicar aplicaciones hechas en java. Esto hace que sea mucho más fácil de usar y que los programadores puedan crear sus propios protocolos con todas las ventajas que esto conlleva.
Su desventaja obviamente es que las aplicaciones hechas en otros lenguajes deberán traducirse a Java para que se puedan comunicar.

CORBA (Common Object Request Broker Architecture)
Esta es una propuesta hecha por un gran consorcio de importantes instituciones llamado OMG (Object Management Group). Es un intento por crear una tecnología mucho más abierta que DCOM y RMI, mediante la cual se puedan comunicar programas hechos en diferentes lenguajes (lo de diferentes sistemas operativos está resuelto con los protocolos de red).
CORBA es un avance con respecto a RMI y DCOM puesto que permite comunicar diferentes lenguajes usando el protocolo estándar IIOP (Internet Inter-ORB Protocol) también definido por OMG.
Se puede decir que CORBA es tan abierto como los servicios web pero no puedo ni debo afirmar lo uno ni lo otro, solamente diré que son dos tecnologías diferentes y quizá más adelante me anime a dar una apreciación subjetiva del panorama. Es necesario recordar dos características de CORBA que nos serán muy importantes a la hora de compararla con un servicio Web (claro hay muchas más, pero por ahora utilizaré estas dos):
1.CORBA utiliza el protocolo IIOP, especificado también por OMG.
2.Los datos son transportados en formato binario.

2. ¿POR QUÉ LOS SERVICIOS WEB?

Hasta ahora vimos las tres tecnologías que habían dominado la computación distribuida (siguen siendo muy utilizadas pero se ve una clara tendencia hacia los servicios Web).
DCOM y RMI son rápidos y permiten modelar estructuras complejas para ser transportadas, pero son tecnologías propietarias; por tanto no es posible mezclar DCOM y RMI a menos que realicemos implementaciones propias, por ejemplo sockets; pero esta no es una muy buena idea y habría que hacer una implementación para cada caso, dependiendo del lenguaje, protocolo, etc.
CORBA obviamente permite la comunicación entre muchos lenguajes siempre y cuando estos implementen el protocolo IIOP y permitan crear un IDL (Interface Definition Languaje, el lenguaje para definir interfaces CORBA) compatible con CORBA. De hecho hasta hace muy poco se consideraba el estándar para comunicaciones entre diferentes lenguajes.
Pero CORBA presenta dos grandes inconvenientes:
a)El protocolo IIOP no necesariamente está soportado por una red. A veces es necesario hacer configuraciones especiales a los cortafuegos para que permita usarlo, lo cual hace que no todos los lenguajes o redes puedan transportar objetos con este protocolo.
b)Dado que los datos son transportados en formato binario, es necesario que los lenguajes hagan implementaciones especiales para leer estos datos y convertirlos a sus propios tipos.

3.QUE SON Y COMO FUNCIONAN LOS SERVICIOS WEB
a)¿Qué son?
Los servicios Web nacen como una opción para la llamada de métodos remotos, esta vez superando las dos principales inconvenientes de CORBA: el protocolo y el formato de datos.
Para superar la incompatibilidad de protocolos, los servicios web son accedidos generalmente sobre el omnipresente http, el mismo protocolo para navegar a través de las páginas Web; como es obvio, este protocolo es comprendido por cualquier PC que pueda conectarse a Internet y tiene la ventaja de ser un protocolo sin estado, esto significa que no es necesario mantener una conexión permanente entre el cliente y el servidor. Dado que http es el protocolo más común para navegar en Internet, la gran mayoría de los lenguajes tiene implementaciones para soportarlo. Cabe anotar que http no es el único protocolo bajo el cual funcionan los servicios Web, si bien es el más utilizado, no hay motivos para no utilizarlos en un escenario diferente.
Otro de lo obstáculos que presenta CORBA es el formato de datos, pues aunque el trabajar con datos binarios permite modelar estructuras complejas y es rápido, exige un esfuerzo adicional al lenguaje o al programador para realizar una implementación de IIOP que pueda interpretar estos datos. Esta situación se solucionó utilizando el también omnipresente (especialmente en estos días de programación Web) lenguaje XML que puede utilizar caracteres (US-ASCCI, UTF-8 y UTF-16) comprensibles por cualquier editor de texto, o al menos por la gran mayoría.
Nos podríamos preguntar por que usar XML (que no tiene un tratamiento tan simple) en vez de texto normal quizá separado por comas o algo similar. Pues bien, la complejidad de XML fue lo que inclinó a muchas empresas a usarlo, dada su capacidad para modelar complejas estructuras de datos. Un archivo plano está bastante bien para enviar una cantidad de datos con el mismo significado como podría ser los precios de una serie de libros; pero no estaría tan bien para transportar datos acerca de varios libros, así como el autor, el género, precio, entre otros. ¿Y qué tal si tiene varios autores? Ya ves la utilidad del XML.

b) ¿Cómo funcionan?
Para utilizar un servicio web es necesario conocer su ubicación, que debe estár descrita por la dirección IP o dominio y el puerto por que está habilitado. A partir de esta información, podemos conocer los parámetros de entrada, salida y el nombre de los procedimientos que se ofrecen.

Ubicar el servicio: Conseguir su descripcion.
Si utilizamos servicios web desarrollados dentro de nuestra organización, pues bastará con pedirle la información a la persona que lo ha creado o quizá exista un directorio donde se almacenen todos los datos acerca de los servicios a los que tenemos acceso.
Existen también muchos servicios Web disponibles al público, los cuales tienen sus datos publicados generalmente en la página web de la organización o persona que lo ofrece. Por ejemplo google (www.google.com) ofrece servicios web que reciben un criterio de búsqueda y devuelven una lista de urls que cumplen con ese criterio, similar a como funciona su página web; amazon.com (www.amazon.com) nos permite conocer el precio de un libro dado su código. Así como estos existen muchos más por el estilo, puedes encontrar una lista interesante de servicios en la página http://www.xmethods.com.
Por último existe un servicio similar a las consultas en directorios: UDDI (Universal Description, Discovery, and Integration), el cuál es un estándar para describir y localizar los servicios web que provee una compañía o persona. UDDI es definido por varias empresas (entre ellas Sun Microsystems, Microsoft e IBM) en donde especifican esquemas para inscribir servicios web. Para usar UDDI es necesario publicar servicios web usando el protocolo SOAP que veremos más adelante, de este modo se pueden realizar búsquedas por palabras clave, empresas, funcionalidad e incluso existen directorios de páginas blancas, amarillas y verdes. Cualquier organización o persona puede registrarse y ofrecer sus servicios mediante UDDI (www.uddi.org), de esta manera cuando realizamos una búsqueda obtenemos los datos para invocar el servicio; estos datos son el nombre del procedimiento y los parámetros tanto de entrada como de salida.
Podemos también realizar una implementación interna de UDDI para nuestra organización, recordemos que es tan solo un estándar e incluso ellos mismo (uddi.org) nos proveen soluciones para realizarlo (uddi.org/solutions.html).

Leer la descripción del servicio: Ver su ubicación, nombre y parámetros.
Un servicio web se ubica por medio de una dirección IP (su nombre) y un puerto, por ejemplo: “www.miservicio.org:8080/servicio1” y para usarlo necesitamos también los nombres con los que debemos llamar los procedimientos y los parámetros que debemos enviar y vamos a recibir.
En general los servicios web trabajan sobre dos formatos: SOAP (Simple Object Access Protocol) y XML-RPC (XML – Remote Procedure Call), ambos basados en XML y diseñados específicamente para describir servicios web. XML-RPC es más sencillo de usar y SOAP más potente, por ejemplo con SOAP se puede elegir el tipo de caracteres que se van a transportar lo que puede resultar importante cuando se transmitan palabras con tilde o la eñe. Tanto SOAP como XML-RPC son definiciones del consorcio W3C (www.w3c.org).
Actualmente el protocolo más utilizado es SOAP, por su acogida entre las grandes empresas y su minuciosidad para transportar los datos; los servicios que ofrecen google y amazon son basados completamente en este protocolo, los lenguajes orientados a la web tienen implementaciones propias para “codificar” y “decodificar” documentos SOAP. Así que como veráz, no tendremos que matarnos creando utilidades para leer estos archivos ni realizar tareas complejas para invocar los servicios, por tanto es el protocolo al que nos referiremos de aquí en adelante.
El consorcio w3c define también un archivo llamado WSDL (Web Service Description Languaje) el cual nos describe el servicio que se ofrece, en un formato XML fácilmente comprensible por el programador, que además permite conocer en una única estructura la dirección del servicio, los nombres de los métodos, los parámetros de entrada/salida y la descripción de los tipos de datos que pueden ser primitivos (int, float, string), complejos (al estilo java beans) o listas (al estilo Collection). Conciendo todos estos valores podemos crear el cliente del servicio y definir los tipos de datos necesarios para almacenar los valores de entrada y/o salida.

Invocar el servicio y recibir los resultados.
Para invocar el servicio no es necesario programar utilidades para XML, HTTP y viajes por la red; puedes hacerlo si quieres (por curiosidad está bien), pero la verdad es que existen implentaciones completas para publicar e invocar servicios web. Con uno de estos paquetes es sólo cuestion de datos, incluso ni siquiera es necesario crear los tipos complejos por que las utilidades tienen la capacidad de almacenar estas estructuras en clases propias y ocultan toda la complejidad del parseo (conversión de los datos XML), el uso de protocolos y la comunicación remota.
SOAP define una estructura para el viaje de los datos en formato XML, esta es llamada mensaje SOAP y consta de dos partes:
El SOAP Envelope (Algo así como el sobre), define la estructura general de un mensaje SOAP, las partes del documento que nos deben interesar y además el protocolo de enlace (como ya dije, generalmente http).
La estructura particular del mensaje.
Posee un encabezado opcional (header) donde pueden viajar los datos que no tienen que ver con el negocio en sí, sino más bien estructuras adicionales de control o datos para la autenticación, etc. Cosas que necesitemos usar, pero no hacen parte de los datos solicitados.
El cuerpo del mensaje. Es la parte obligatoria y aquí van los datos que hemos solicitado en una estructura definida, con tipos de datos como los mencionados anteriormente; es la parte más importante del mensaje y son nuestro objetivo final al invocar el servicio.

Para finalizar
Ahora que tenemos los datos es cuestión de la lógica de nuestro negocio lo que debamos hacer con ellos, que puede ir desde una simple presentación en consola o realizar un proceso para invocar otro servicio web y finalmente tomar una decisión o alegrarnos por que la prueba funcionó.
Espero haber dejado claro el concepto de servicio web. No espero que tengas mucha idea de la parte técnica (para ello puedes dirigirte a nuestro laboratorio), sino que sepas bajo que escenarios sirve, cuando es mejor usar otras tecnologías, el por que de su estructura (XML – HTTP) y el proceso que se sigue para descubrirlo y ejecutarlo. Quizá en artículos posteriores analizemos con detalle Mensajes SOAP o archivos WSDL, pero esto es todo por ahora.

REFERENCIAS
CORBA vs Web Services
UDDI
Artículo completísimo (Quizá demasiado)
webservices.org
xmethods.com
w3c


Java Colombia. Programación con J2EE, Struts, JSP, EJB a la manera Colombiana

Etiquetas: , , ,

Anuncios