Los web services estaban llamados a revolucionar las tecnologías de la información. Prometían nada menos que un mundo de máquinas interrelacionadas, comunicando y colaborando entre sí para para dar servicio a las más variadas funcionalidades. Si la world wide web es la «internet para las personas», los servicios web serían la «internet de las máquinas».
Sin embargo, ya han pasado unos cuantos años desde la publicación de los estándares que forman esto que conocemos como web services y las expectativas, en mi opinión, no se han visto totalmente colmadas.
Después de tantos años la adopción de esta tecnología en las grandes empresas solamente ha sido parcial. ¿cuáles han sido la razones para ello? En mi opinión la siguientes:
  1. La alta complejidad de los estándares
  2. Problemas de interoperabilidad
  3. La irrupción de otras tecnologías más simples
Alta complejidad de los estándares
En realidad lo que conocemos como web services no es una especificación única, son varias y en la mayor parte de los casos muy complejas (se conocen con WS-*). Para hacerse una idea de la proliferación de estas especificaciones basta con ver la lista de los más importantes: SOAP, WSDL, WS-Addressing, WS-Policy, Attachments, WS-Security, XML Signature, XML Encryption, XML Key Management (XKMS), WS-Trust, WS-Federation Security Assertion Markup Language (SAML), XACML, WS-Reliability, etc. y continúa en aumento.
Evidentemente esta es una barrera muy importante para su adopción en las empresas.
Problemas de interoperabilidad
A pesar de la extensión y complejidad de las especificaciones que forman los web services, o quizás por este mismo motivo, existen infinidad de problemas de interoperabilidad entre aplicaciones (máxime cuando usan diferentes lenguajes y tecnologías como .NET y J2EE). Las especificaciones son en ocasiones tan ambiguas que dos aplicaciones pueden seguirla a pies juntillas y a pensar de todo no son capaces de entenderse. Por ejemplo, es posible que el cliente .NET codifique en XML los arrays de datos de una manera (legal según la especificación de SOAP) que no pueda entender el servidor hecho con J2EE.
Para evitar los problemas patentes de interoperabilidad en el uso de servicios web, la Organización para la Interoperabilidad de Servicios Web (Web Services Interoperability Organization WS-I),  ha recortado el conjunto de especificaciones eliminando todo aquello excesivamente complejo y ambiguo (por ejemplo define como han de ser los arrays de datos para que se puedan entender las dos partes). Este conjunto de normas se recogen en el llamado Basic Profile (1.0 y 1.1) acordado por los mayores fabricantes de la industria (Microsoft, IBM, BEA, Sun Microsystems, Novell, Oracle, SAP, etc.)
En conclusión, en la práctica los desarrollos de web services deben seguir el Basic Profile para lograr el objetivo para el que han sido inventados, poder comunicar dos aplicaciones entre sí.
Tecnologías más simples
  • REST (Representational state transfer).
    Uno de los principales autores del protoco HTTP, Roy Fielding,  lo introdujo en su tesis doctoral allá por el año 2000.
    Define una forma de comunicación entre aplicaciones basado en XML y HTTP sin las complicaciones de las especificaciones de web services. Se basa en un protocolo cliente-servidor sin estado, adapta el concepto de las operaciones HTTP (GET, POST , PUT y DELETE) considerandolas como operaciones CRUD.
    Sus principios de diseño son:
    Identificación de recursos: los recursos son identificados en las operaciones, normalmente mediante URIs.
    Manipulación de los recursos a través de las repesentaciones de los mismos que se envían al cliente.
    Los mensajes son autodescriptivosLas principales ventajas son su sencillez (en oposición a la gran curva de aprendizaje que tienen los web services), su rapidez de desarrollo, mayor escalabilidad que los web services (es un protocolo más liviano)
  • JSON (Javascript Object Notation)
    Es un formato ligero de intercambio de datos (hecho en javascript) que viene a sustituir al XML que tradicionalmente se venía usando para estos menesteres.
    JSON está siendo usado ampliamente ya en la actualidad, en el contexto de la llamada web 2.0. Con la ayuda del AJAX las aplicaciones de internet ricas, con profusión de uso de javascript, intercambian este tipo de mensajes con el servidor.
    ¿Sus ventajas? sencillez de uso (sobretodo en aplicaciones ricas basadas en frameworks javascript) y también el rendimiento. Se han hecho comparativas entre el uso con JSON y con XML y ha resultado ganador el primero con diferencia.
    Evidentemente, si el formato XML ya no es usado para la comunicaciones entre aplicaciones, por extensión, tampoco serán necesarios los web services que se basan en éste.
¿realmente estamos construyendo servicios web?
En la esencia de un web services está el tener un fichero de definición (WSDL) por el cual el servicio se auto describe a sí mismo. Para ello obviamente deben estar claro su interfaz de entrada/salida, su nombre, su tipo, etc.
Sin embargo, según mi experiencia, en la mayor parte de los casos los servicios web que existen no tienen este interfaz definido en el WSDL. Algunos los llaman servicios «genéricos», yo los llamo servicios de «formato churro». Estos servicios normalmente suelen tener un campo de entrada de tipo String y otro campo de salida en el que se inserta un mensaje en formato XML.
  • Flexibilidad: Sus defensores dicen que son muy «flexibles» porque en el caso de que se quiera cambiar el mensaje no es necesario volver a desplegar el servicio. Esto realmente no es así ya que si se añade un campo, por ejemplo, es necesario obviamente cambiar cliente y el servidor para que trate este nuevo campo.
  • No es autodescrito: Además, este tipo de servicios va contra la esencia misma del servicio web, ya no se describe a sí mismo. En lugar de esto, se tiene un campo de mensaje que en realidad es un cajón de sastre en el que cabe todo. Peor aún, la necesidad de describir el formato del mensaje sigue estándo ahí por lo que normalmente al pobrísimo WSDL de este servicio se acompaña un documento Word donde se explica al programador del cliente qué mensaje tiene que enviar ¿no es esto absurdo? ¿no se supone que los web services se han inventado para que dos máquinas se puedan entender e intercambiarse mensajes?.
  • ¿por qué no usar  HTTP/POST?: ¿por qué nos complicamos innecesariamente con el uso de una especificación tan compleja como los web services? Si hay que enviar un mensaje SOAP, hacer un cliente proxy, usar una herramienta específica para probar, etc. etc. ¿no sería más sencillo hacer un HTTP POST con XML como se ha hecho toda la vida?
Conclusiones
Si queremos que esta tecnología se adopte ampliamente se tendrá que hacer un esfuerzo de simplificación de las especificaciones y también un avance significativo en las herramientas de desarrollo. Tal vez la foto final pase por un modelo mixto de servicios (basados en SOAP) conviviendo con REST:
  • Dentro de una misma corporación, donde no se necesita unos interfaces o contratos rígidos, se podría adoptar REST por su facilidad, sencillez y rapidez de desarrollo
  • En la comunicación entre corporaciones, uso de servicios web con un contrato formal entre el que presta el servicio y el cliente.

Comparte este artículo…