Web Services usando XML (XML Web Services)

XML Web Services fue diseñado para que sistemas heterogéneos puedan interactuar, comunicándose e intercambiando información.

En el marco que nos ocupa, la heterogeneidad está orientada a sistema operativo, lenguaje o arquitectura.

Para esta interacción, XML Web Service usan HTTP, XML y SOAP, es decir, standards en el mundo Internet, lo cual es coherente con el objetivo de interoperabilidad. De esta manera, el servicio es accesible desde cualquier cliente. Estos servicios pueden verse como caja negras (black boxes). La aplicación que los invoca se abstrae de la funcionalidad: la aplicación necesita saber qué hacen, no cómo lo hacen. (Molinari & Javier Diaz, 2004, pág. 80)

Para poder accederlos deben saber cómo invocarlos y qué retornará de la ejecución (que, obviamente, será remota).

52 En otras palabras: los desarrolladores crean métodos y los exponen para que otros los usen.

Veamos tres protocolos que rigen este intercambio entre el cliente y el XML Web Service. (Molinari & Javier Diaz, 2004, pág.

80)

 HTTP GET: el XML Web Service es invocado usando un requerimiento GET sobre HTTP. El input se pone en un string (query string) y el resultado vuelve como un documento XML.

 HTTP POST: el XML Web Service es invocado usando un requerimiento POST sobre HTTP. Los valores de input se ponen en el cuerpo del HTTP POST y el resultado vuelve como un documento XML.

 SOAP: el XML Web Services es invocado usando un mensaje SOAP sobre

HTTP. Los valores de input se ponen en el cuerpo del mensaje SOAP y el resultado vuelve como un documento XML.

El uso de uno u otro está limitado por el tipo de datos: para tipos simples, como strings o enteros, los argumentos de input pueden hacerse a través de un query string, form post o usando un mensaje SOAP. Pero para tipos complejos, como imágenes, objetos o data sets, se serializan los argumentos a XML y son incluidos en el cuerpo de un mensaje SOAP. (Molinari & Javier Diaz, 2004, pág. 80)

¿Cómo se expone el servicio al cliente?

El usuario que desarrolló el servicio, necesita exponerlo, para que aquellos usuarios interesados puedan accederlos.

¿Cómo publicita el desarrollador su servicio? Si bien siempre se puede hacer llegar al desarrollador interesado directamente la URL del lugar donde está el servicio, existe una forma más práctica: registrar el servicio en un site, que funciona como una guía de los servicios en la Red, una gran base de datos de servicios. (Molinari &

Javier Diaz, 2004, pág. 80)

53 Esta es la función de la base de datos UDDI (Universal description, Discovery and Integration). Más adelante se detallan las características de UDDI.

UDDI es una organización para el registro, esencialmente, de XML Web Services.

De esta manera, potenciales clientes que precisan determinado servicio, lo pueden buscar en UDDI, y si existe, saben cómo accederlo y dónde.

¿Cómo invoca el cliente el servicio?

Cuando se crea el XML Web Service, se debe considerar que el cliente que lo necesite lo invocará.

Para ello, debe informarse cómo hacerlo, cuáles son los métodos que lo forman, cuáles serán los argumentos de llamada y qué devolverá.

Para eso se agrega al XML Web Service, un documento con toda esta descripción. Este documento está construido en WSDL.

En el registro UDDI correspondiente al servicio, se hace referencia a la URL donde está este documento WDSL. Ese documento WSDL tendrá toda la información necesaria para acceder al XML Web Service. (Molinari &

Javier Diaz, 2004, pág. 81)

El documento WSDL describe como los argumentos de invocación al servicio incluyendo tipo de dato y nombre, para la invocación HTTP GET, HTTP POST y SOAP.

Si bien el proveedor del servicio puede hacer cambios en la lógica dentro de los métodos, mientras no modifique la invocación, el documento WSDL no cambiará.

Se podría, por ejemplo, cambiar las bases de datos a las cuales se conecta el servicio, y el cliente lo invoca no se enteraría.

El consumidor y el retorno del XML Web Services

Evidentemente, XML Web Service se basa en un modelo donde existe un proveedor (la aplicación que

54 expone el XML Web Service) y un consumidor (la aplicación que usa el XML Web Service).

Supongamos que un usuario de una aplicación usa el XML Web service. Cuando se dice que el servicio retorna un documento XML, el usuario no debería necesariamente, ver ese documento. Es más: lo deseable, para obtener la abstracción deseada es que no lo vea.

(Molinari & Javier Diaz, 2004, pág. 81)

La aplicación que recibe la respuesta del XML Web Service, debe estar preparada para “consumir” ese XML, y transferir la información que está en él a la aplicación de usuario, de una manera amigable.

O sea: una aplicación Web actúa como consumidor, invoca al XML Web Service, recibe el documento XML que retorna, y lo muestra de manera apropiada al usuario.

Figura N° 2.6 – El consumidor y el retorno del XML Web Services

Fuente: Arquitecturas orientadas a Web Services (Esquema de Doug Seveni)

El ciclo de uso de un XML Web Service sería entonces:

a) El usuario que necesita el servicio, lo busca en el registro UDDI (o accederlo directamente si se tiene la URL donde está).

b) Si está, requiere el documento WSDL.

c) El proveedor envía el documento WSDL en formato XML.

55 d) El proveedor hace un requerimiento del XML WEB

SERVICE que figura en el WDSL, pasando los argumentos según la forma enunciada en el WSDL.

e) El proveedor procesa el requerimiento y retorna el resultado en un documento XML o en un mensaje SOAP.

2.2.13.1. ¿Qué es SOAP?

SOAP fue definido por W3C como “a lightweight protocol for information exchange in a decentralized, distributed environment”.

El éxito de SOAP es que está basado en texto (usando XML) lo que lo hace independiente de distintas plataformas (y vendedores). (Molinari & Javier Diaz, 2004, pág. 85)

De esta forma al invocar un método, no es necesario saber en qué lenguaje está desarrollado, si es remoto o no, etc.

SOAP no incluye, por sí mismo:

 Garbage collection distribuido

 Manejo de objetos por referencia (requiere garbage collection)

 Activación (requiere manejo de objeto por referencia)

 SOAP es lo que se llama “lightweight protocol”. Tiene capacidades fundamentales como:

 Poder enviar y recibir paquetes HTTP o de otros protocolos

56

 Poder procesar XML

Lo interesante de estas tecnologías que utilizan XML y SOAP es que pueden integrarse en aplicaciones ya existentes sin demasiada complejidad. (Molinari & Javier Diaz, 2004, pág. 85)

Productos que usan SOAP, pueden usar servidores HTTP existentes y procesadores XML que tenga el cliente.

Si en cambio, se utiliza CORBA, DCOM o Java RMI se debe instalar el ambiente apropiado, configurar el sistema para adaptarlo a la nueva infraestructura distribuida. También puede exigir reconfigurar firewalls. Por eso a esta tecnología se lo asocia con

“heavyweights systems”.

SOAP permite serializar la invocación de métodos remotos, transformando la llamada al método en la forma adecuada para su transmisión sobre la red, sobre una capa de transporte que lleve esos datos inherentes al método entre los sistemas remotos.

(Molinari & Javier Diaz, 2004, pág. 86) Figura N° 2.7 – Composición de un mensaje SOAP

Fuente: Artículo de revista Servicios Web