Para quien no la conozca, WS-I es la organización, creada hace una década, de la que forman parte los mayores fabricantes de software (Microsoft, Oracle e IBM). Como dice su nombre (Web Services Interoperability), su misión es asegurar la interoperabilidad entre clientes y proveedores de servicios web sin importar la tecnología, sistema operativo, o lenguaje en el que estén construidos cualquiera de las dos partes.

Para entender la importancia de esta organizacion es necesario contextualizar un poco:

Según mi punto de vista los servicios web tienen un par de problemas importantes:

  1. Su excesiva complejidad y dispersión de especificaciones. En realidad no hay una especificación única que defina exactamente lo que es un servicio web. En su lugar hay varias (algunas bastante complejas) que se ocupan de un determinado aspecto del mismo. Los más conocidos, por supuesto, serían los que definen el formato del fichero WSDL, el mensaje SOAP. También hay otros menos conocidos, y mucho menos usados, conocidos como la familia WS-* entre los que se encuentran WS-Security, WS-Addressing, WS-Transaction, etc. etc.
  2. “Quién mucho abarca poco aprieta“. Son un conjunto de especificaciones demasiado genéricas para llegar a cumplir uno de sus principales objetivos (la interoperabilidad entre dos aplicaciones). Desde un principio han querido abarcar tanta casuística que se llegó un un punto en el que dos partes, cada uno por ejemplo implementada en un lenguaje diferente (.NET y Java), aun siguiendo las dos al pie de la letra las especificaciones, les era imposible comunicarse entre sí. Por ejemplo, en la especificación del WSDL, no se restringe en absoluto el protocolo de comunicación: puede ser HTTP (lo normal), pero también admite el protocolo de colas (JMS en Java), SMTP (email) incluso hasta el FTP.
    Esta ambigüedad y falta de restricción y concreción provacaba en la práctica que no pueda existir una comunicación efectiva entre el cliente y el proveedor del servicio.

Viendo el desastre que se avecinaba, los mayores fabricantes de software se aliaron en el WS-I para definir unas buenas prácticas que garantizasen la interopoerabilidad entre proveedores y clientes de servicios web sin importar el lenguaje en el que estuvieran implementados, el sistema operativo o la máquina sobre la que se ejecutasen. El fruto de su trabajo, fue la publicación de los documentos que se conocen como perfiles.

Resumiendo un poco, lo que se recoge en estos perfiles es una “poda” o recorte en las especificaciones de servicios web (sobretodo la de WSDL y SOAP) de todo  aquello que puede ser problemático, causar ambigüedad o que pueda complicar la vida para lograr la comunicación entre las dos partes. Estos son algunos ejemplos de recortes:

  1. Un servicio web puede ser de cuatro tipos (la combinación del estilo “rpc” o “document” y la codificación “encoded” o “decoded”). Pues bien, resulta que cada fabricante entendía lo de “encoded”,como una codificación propia que se hace del mensaje SOAP. Como resultado si el cliente enviaba un mensaje SOAP de este tipo, el proveedor no lo entendía.
    Solución: prohibir el uso de mensajes “encoded”.
  2. Se limita el SOAP a la versión 1.1 y el protocolo es siempre HTTP
  3. Las colecciones de datos tipo “array”, con el nombre “arrayof”: Microsoft entendía por array algo diferente a lo que entendía IBM.
    Solución: prohibir los “arrayof”

Los perfiles publicados por WS-I, conocidos como Basic Profile, reciben varias versiones (la 1.0 y la 1.1 son las más usadas). En los últimos tiempos  han publicado la 1.2, 2.0 y el Reliable Secure Profile 1.0
Con la finalización de estos perfiles, WS-I entiende que ha finalizado su trabajo, pasándole el testigo a la organización OASIS (Organization for the Advancement of Structured Information Standards).

Las “malas lenguas” dicen que esta decisión por parte del WS-I se debe a la pérdida de pujanza de los web services, en favor de otras tecnologías (principalmente REST) más sencillas, menos complejas y sobre todo más rápidas de aprender y desarrollar.

En mi opinión Web Services y REST no deberían competir directamente, por que creo que se dirigen a un “nicho” distinto:

  • Los Web Services, con su WSDL, definen un contrato muy formal que es adecuado para la interoperabilidad entre diferentes divisiones dentro de la misma empresa y por supuesto entre diferentes empresas. Creo que en este escenario esta rigidez en el contrato es necesaria para que no haya ambigüedad en la comunicación (ya que ésta afecta más negativamente a la marcha del proyecto que la dificultad de uso de los estándares de servicios web).
  • Sin embargo, en otro escenario menos “formal”, por ejemplo dentro de un mismo desarrollo, para comunicar diferentes capas de una aplicación que son desarrolladas por el mismo equipo o por equipos muy cercanos, la flexibilidad y rapidez de desarrollo con REST puede aportar mucho. Me refiero por ejemplo, a la comunicación entre las pantallas del frontend con el backend. Aquí no es necesario un contrato tan rígido como entre dos empresas.

En conclusión:

Sin la aportación de WS-I, a mi entender, simplemente no hubiera sido posible el uso de la tecnología web services como protocolo estándar de comunicación.

Comparte esta entrada…

Share