Hace ya algún tiempo, en esta entrada del blog, sacaba a colación la poca implantación real de los servicios web (al menos en las aplicaciones de negocio de España). Bien, pues la realidad nos lleva, una y otra vez, a confirmar esta percepción. En la mayoría de los casos nos encontramos en que para comunicar los aplicativos de dos empresas, no se usan servicios web, o cuando sí se usan, no se hace de manera completa. Para ilustrar esta entrada, a modo de botón de muestra, citaré el caso del servicio de envío/recepción de SMS de Movistar (una de las mayores empresas de España y también a nivel mundial).

Y es que lo habitual, cuando existe un web service para interoperar entre dos compañias, este  suele ser del tipo que yo llamo “churro”. Esto quiere decir que en lugar de tener un interfaz claramente definido, donde se indica en su descriptor (el WSDL) los parámetros de entrada y salida, su estructura y su tipo, tenemos normalmente un campo del tipo “cadena de texto” de entrada y otro de salida. Dentro de este campo de texto, viajará el verdadero mensaje (normalmente en formato XML). Por supuesto, esto obliga a disponer de un documento  (el omnipresente fichero Word) donde se explica como componer este mensaje XML. ¿pero no es el objetivo del WSDL exactamente es? ¿explicar en un lenguaje estándar el formato del mensaje?. Si el interfaz del mensaje no está descrito donde tiene que estarlo, que no es otro que el WSDL, lo siento mucho, pero esto no es un servicio web.

En el caso de Movistar, felizmente observamos que sí está correctamente definido, con un interfaz claro y bien definido que se recoge en su WSDL.

Yendo un paso más allá, en aquellos casos en que el servicio web está descrito con su WSDL, nos encontramos con otro tipo de “carencias”.

No cumple el Basic Profile

Cito la entrada Principios de la Arquitectura Orientada a Servicios de este blog:

En las arquitecturas SOA, el problema de la falta de esta cualidad es uno de los más importantes. Hay que tener en cuenta que muchos de los servicios que intervienen se implementan con una tecnología diferente, incluso con un sistema operativo distinto. Por ejemplo, se puede tener un servicio realizado en Java ejecutándose sobre Linux que invoca a otro implementado en .net corriendo en una máquina con Windows. Históricamente las especificaciones que dan forma a los servicios web (como WSDL, SOAP, etc.) eran tan ambiguos que las dos partes estaban prácticamente condenadas a no entenderse. Iniciativas como el Basic Profile 1.0 han contribuido a eliminar estas ambiguedades, simplificando estos estándares, logrando que el consumidor y el proveedor del servicio puedan comunicarse entre sí.

Pues  bien, lo normal es que los servicios web no cumplan esta especificación. No es necesario remarcar, que en este caso, las comunicaciones entre el cliente y el proveedor del servicio pasarán por todo tipo de vicisitudes hasta lograr a pasar a producción.

En el caso de Movistar, no se cumple el Basic Profile, pero “por muy poco”. Únicamente se detecta un problema en la importación de esquema XSD que declara los tipos de datos usados en el servicio.

No implementa una seguridad estándar

La forma más fácil de securizar un servicio web, siendo una solución totalmente válida desde el punto de vista de la seguridad, es usar una autenticación de tipo BASIC sobre HTTPS. Con la seguridad BASIC se envía un revuelto del código de usuario y de la password en formato Base64. Por supuesto, alguien que estuviese escuchando por la red podría obtener esta password ya que en definitiva ésta va en claro. Pero si añadimos que el canal está securizado mediante HTTPS, estableciéndose una comunicación confidencial entre el emisor y el receptor, tendremos que la comunicación es totalmente segura. Por supuesto, esto aplica a la comunicación punto a punto entre el servidor de salida y el servidor de entrada (él ambito de la comunicación HTTPS), más allá de esto, por ejemplo si dentro de la organización de destino se reenvía a otro servidor, esta comunicación ya no sería por HTTPS por lo que estaríamos expuestos nuevamente a que alguien obtuviese la contraseña.

Posteriormente, en el mundo de los web services, se definió el estándar WS-Security, que define varios aspectos relativos a la confidencialidad del mensaje, la firma electrónica, etc. En este caso la seguridad se aplica a nivel del mensaje (no del canal). De este modo, no importa por cuantos o por que clase de servidores intermedios tenga que pasar el mensaje. Sólo el destinatario del mismo podrá desencriptar su contenido.

Bien, en el caso que nos ocupa, no se usa la autenticación BASIC, lo que se consideraría un estándar. En su lugar, se manda la contraseña como un campo más del mensaje de entrada (igual que otros parámetros de negocio del servicio). No está recogida en una cabecera técnica sino que está en el cuerpo del mensaje (el BODY del ENVELOPE del mensaej SOAP⁾. Desde del punto de vista de la seguridad, podemos decir que realmente es seguro (la petición va por HTTPS y por tanto se garantiza la confidencialidad de la la información) y se realiza correctamente la autenticación del usuario que invoca al servicio. Sin embargo, es una pena que no implemente un mecanismo de seguridad estándar (como es el BASIC) obligándonos a realizar un tratamiento de la seguridad en modo “programático” en lugar de permitirnos un modelo declarativo.

No es simétrico

En el caso de Movistar, resulta que únicamente se ha implementado como web service el envío de SMS desde nuestra aplicación a Movistar. Sin embargo, cuando un usuario final, desde su móvil, envía un SMS, desde Movistar se invoca a una URL mediante un POST HTTP. Osea que mediante web services sólo se puede enviar SMS, no recibirlos.

Esto es un poco extraño y sólo se entiende si están migrando desde los POST/HTTP a web services y se hayan a mitad de camino (aunque esta es la situación desde hace algún tiempo). Lo suyo sería que movistar distribuyese un WSDL que describiese el interfaz del servicio de recepción de SMS. La empresa que quiera desarrollar una aplicación de recepción tendría que implementar un web service a partir de este WSDL (en Java, por ejemplo, existen utilidades del tipo WSDL2Java que generan código Java a partir de un WSDL).

Conclusión

En cuanto al caso concreto del servicio de Movistar, desde el punto de su consideración como web services (no entro en su funcionalidad), si tuviera que darle una nota sería la de “insuficiente alto”. Con un poquito más, como la adopción completa del Basic Profile y un mecanismo estándar de seguridad pasaría fácilmente a una nota de “notable”. A este respecto, es de agradecer que se haya creado una comunidad de empresas usuarias del servicio en el que éstas aportan sugerencias y feedback que son tenidas muy en cuenta por los responsables del servicio y que hacen que se vaya mejorando con la ayuda de todos.

Mas allá de este caso concreto, parece claro de que a la implantación de los web services les queda todavía mucho camino que recorrer. Tal vez, de tanto esperar, en el camino se los merienden los servicios REST y ni siquiera lleguemos a ver una implantación real de los web services y que éstos por fin, sean vistos realmente como la forma habitual de interoperabilidad entre aplicaciones.

Comparte esta entrada:

Share

Anuncios