ClawGrip

Intento de explicar qué son los servicios Web, para que valen, de donde provienen y que hay de fondo en toda la repercusión tecnológica que están teniendo. Espero que os sea útil.

Para empezar entendiendo a fondo los servicios Web es mejor tomarlos como un intento de normalización tecnológica de una arquitectura clásica cliente servidor, recordemos que especto tenía:

Disponemos de un servidor, que ofrece una serie de servicios a través de la red, los cuales son accedidos por clientes en diferentes extremos. Simple y efectivo, pero entonces ¿Donde está el problema? El gran problema es que es solo un dibujo de arquitectura, cada uno puede implementarlo como desee, usando las tecnologías que prefiera, lo cual nos deja muy lejos de una arquitectura uniforme e interoperable, que sería lo deseable.

Bien, busquemos entonces una definición de normativas más o menos estricta que nos permita crear servicios interoperables sea cual sea la plataforma o el fabricante de donde provenga tanto el servidor como los clientes... Empecemos paso a paso ¿Que necesitamos normalizar?

El formato de los mensajes

Como el diálogo es entre máquinas y no hay necesidad de que sea legible por personas, parece lógico que se tratase de un formato binario (nativo para las máquinas) y cuyo proceso automático sea lo más eficiente posible, a ser posible que esté ya normalizado y bien probado (mejor si es ya un estándar internacional) y como la comunicación cliente-servidor va a ser por una red de comunicaciones, sería bueno también que el formato estuviese optimizado para su transmisión por redes (mínimo tamaño de metadatos, información compactada, etc.).

El protocolo de transmisión

Necesitaríamos que fuese el óptimo para el formato de mensajes elegido y que permitiese una operación orientada a conexión ¿Por que orientado a conexión? Voy a poner un ejemplo tontísimo de conversación para dejar claras las diferencias:

Orientado a Conexión:

(Tomás llama a Susana)
Tomás: Hola Susana, soy Tomás ¿Vienes a la inaguración de mi casa nueva esta noche?
Susana: Vale, pero te tengo que confesar algo que he estado ocultando... Estoy casada.
(Segundos de silencio por la sorpresa...)
Tomás: Pues no te lo vas a creer, yo también te he estado ocultando algo: ¡También yo estoy casado! ¿Quedamos entonces a las 23:30?
Susana: ¡Ok! Me llevaré a mi marido para que le conozcas ¿Estará también tu mujer?
(Segundos de silencio mientras Tomás se lo piensa...)
Tomás: Pues supongo que sí... Venga nos vemos en un rato ¡Hasta ahora!
Susana: ¡Hasta ahora!
(Fin de la llamada)

No orientado a Conexión:

(Tomás llama a Susana)
Tomás: Hola Susana, soy Tomás ¿Vienes a la inaguración de mi casa nueva esta noche?
Susana: Vale, pero te tengo que confesar algo que he estado ocultando... Estoy casada.
La llamada se corta, Tomás vuelve a llamar a Susana...
Tomás: Hola, soy yo otra vez, que antes se ha cortado. Pues no te lo vas a creer, yo también te he estado ocultando algo: ¡También yo estoy casado! ¿Quedamos entonces a las 23:30?
Susana: ¡Ok! Me llevaré a mi marido para que le conozcas ¿Estará también tu mujer?
La llamada se corta, Tomás vuelve a llamar a Susana...
Tomás: Soy Tomás, otra vez se ha cortado, te sigo contando: Pues supongo que sí... Venga nos vemos en un rato ¡Hasta ahora!
Susana: ¡Hasta ahora!
(Fin de la llamada)

¿Veis la diferencia? En el segundo caso a Tomás le toca hacer tres llamadas (establecer tres conexiones), lo cual tiene un coste telefónico mayor (igualmente las conexiones de red suponen un coste), además de tener que recordarle a Susana que es él de nuevo para reanudar la conversación (mantener la sesión entre conexiones). En el primer caso Tomás hace solo una llamada y la conversación no se corta (menor coste, menos tiempo de charla y diálogo fluido), pero nada impedía a Tomás cortar en cualquier momento la llamada y volver a marcar después (porque un protocolo orientado a conexión se puede forzar para que actúe como no orientado a conexión, pero no al contrario). Supongo que ya tenemos claro la conveniencia de utilizar un protocolo orientado a conexión ¿No?

Ok, ya tenemos claros los requerimientos, vamos entonces a analizar las tecnologías que forman la base de los servicios Web:

Formato de los mensajes: XML

XML: Enorme cantidad de metadatos (más tamaño), no optimizado para su transmisión por redes de comunicación, legible por personas, pero costoso (recursos de procesador y memoria) de procesar y analizar por máquinas, y eso sí, normalizado por la industria.

Protocolo de transmisión: HTTP

Optimizado para el transporte de SGML (lo cual resulta óptimo dada la elección de XML), pero no orientado a conexión.

¿Por que? ¿Por que usar las tecnologías más inadecuadas? Solo hay un motivo: Los cortafuegos.

Recordemos brevemente el funcionamiento de los cortafuegos:
Si, por poner un ejemplo, tengo una red interna a mi organización que da un solo servicio externo (que es el servicio Web) y unos cuantos más servicios internos (directorio y ficheros compartidos por ejemplo), sería deseable contar con mecanismos que asegurasen que desde fuera solo se va a poder acceder al servicio Web, mientras que desde dentro la operativa no va a estar limitada. Pues esto es lo que hace el cortafuegos. En este caso el cortafuegos solo dejaría entrar conexiones externas si van dirigidas al puerto 80 (puerto del servicio Web), con protocolo HTTP (protocolo Web) y transfiriendo algún tipo de SGML (páginas Web).

Y si ya tengo puesto un cortafuegos en mi red (configurado como en el ejemplo) y quiero montar una arquitectura cliente-servidor hacia fuera ¿Como lo hago? Pues hay dos opciones, o modifico la configuración del cortafuegos o fuerzo a mi sistema cliente servidor a usar el puerto 80, el protocolo HTTP y a intercambiar XML (tipo de SGML). Ya lo tenemos: Los servicios Web actuales.

Está bien claro que hubiese sido más fácil reconfigurar el cortafuegos, pero ya no tiene remedio. Uno de los culpables de esta auténtica perversión tecnológica es XML: Por moda o por friquismo XML se ve como la solución universal a todos los problemas de formato, y evidentemente no lo es...

Seguiremos en los póximos capítulos desarrollando el tema ¡No os los perdais!

# posted by ClawGrip @ 22:07