Servicios web (1): SOAP no, gracias

Hola a todos, lamento no haber escrito un post la semana pasada, pero la celebración de la copa del mundo de fútbol, junto con algunos imprevistos, lo impidió. Con este post pienso comenzar una serie que trate sobre como hacer servicios web usando el enfoque REST, de paso descansamos un poco de todo el tema del Agile y el TDD, aunque no os preocupeis ya volveré a dar la brasa sobre esos temas.

En este primer post de la serie pretendo hacer una introducción a los servicios web y explicar por qué la tecnología SOAP y WSDL (junto con toda la pila WS-*) no es una buena aproximación a la implementación de servicios web. Para ello tendremos que aclarar primero una cuestión fundamental, ¿qué entendemos por servicio web? Un servicio web es una pieza de software que posee las siguientes propiedades:

• Proporciona una funcionalidad de negocio.
• Esta funcionalidad es accesible en remoto a través de la web. Ojo, accesible a través de la web, no a través de un protocolo especial, ni de una infraestructura especial, ni en una topología de red especial. Fijaos que esta condición excluye tecnologías como por ejemplo CORBA, ya que ésta última no usa protocolos web. Esta condición garantiza que la invocación de un servicio web se pueda realizar aprovechando la infraestructura de la web ya existente, sin necesidad de instalar nada especial. La tecnología elegida para publicar servicios web debería aprovechar lo mejor posible la infraestructura web ya existente, para conseguir una mejor interoperabilidad y calidad de servicio.
• Proporciona una interface bien definida, ocultando la implementación real. El servicio puede estar implementado en cualquier tecnología, por ejemplo COBOL. La tecnología real de implementación, y los detalles de ésta, no son importantes y no deben ser visibles al consumidor del servicio.
• Interoperable, el proveedor del servicio y el consumidor pueden estar en tecnologías distintas, y aun así poder interactuar. Como comenté anteriormente no debería ser necesario montar una infraestructura especial para que un cliente pueda invocar a un servicio.

Desde el punto de vista del nivel de interoperabilidad de los servicios web, yo distingo tres categorías:

• Privados. El servicio web sólo va a ser consumido por clientes desarrollados por la misma organización que lo creó.
• Públicos. El servicio web, puede además ser consumido por clientes de otras organizaciones, con los que previamente se ha negociado el modo de acceso. Como caso típico tenemos los escenarios B2B. Un ejemplo es el tarificador de seguros que es llamado por un portal de búsqueda para comparar precios para tu seguro del automóvil.
• Globales. El servicio web puede ser consumido por cualquier cliente en el mundo. No es factible realizar una negociación sobre el modo de acceso al servicio. Normalmente en este caso se crea una página web documentando la API del servicio y qué protocolo se va a usar. Algunas organizaciones como eBay, Amazon, Google, Yahoo, Facebook o Twitter necesitan este nivel de interoperabilidad.

Es claro que cuanto mayor nivel de interoperabilidad queramos alcanzar, necesitamos un menor nivel de acoplamiento entre el consumidor y el proveedor del servicio. El acoplamiento será mayor cuanta más información necesite el cliente para poder invocar al servicio. Cuanto mayor acoplamiento, mayor cantidad de documentación tendrá qué leer el desarrollador del cliente, y más esfuerzo se necesitará para la programación de éste. El hecho de que los servicios web oculten los detalles de su implementación a través de una interface es bueno en este sentido, ya que el cliente no necesita saber detalles sobre cómo implementa el servicio su funcionalidad para invocarlo. Otra buena práctica de desacoplamiento es que el servicio sea stateless, de esta manera el cliente no necesita almacenar el estado de la conversación para poder invocar al servicio correctamente, sólo necesita comprender los parámetros que va a enviar.

Armados con estos conocimientos básicos estamos en condiciones de comparar distintas tecnologías para construir servicios web. Nos fijaremos en la capacidad de la tecnología para usar la infraestructura web, si es capaz de ofrecer una interfaz que oculte la implementación, si permite el uso de distintas tecnologías en el lado cliente y servidor, y el grado de interoperabilidad que puede proporcionar, es decir, el nivel de desacoplamiento que ofrece.

Analicemos la tecnología más popular para hacer servicios web, la pila WS-*. La pila WS-* es un conjunto de protocolos y estándares para realizar servicios web basados en XML. La verdad es que son muchos protocolos y estándares, y bastante complejos, tantos y tan complejos que yo no conozco dos implementaciones completas de la pila WS-* en funcionamiento e interoperables entre si a todos los niveles. Sin embargo, dentro de todos estos estándares, nos podemos fijar en los dos más usados (y casi los únicos): SOAP y WSDL.

SOAP nos permite invocar procedimientos remotos usando XML. Actualmente SOAP se ha extendido para que soporte adjuntos binarios. La verdad es que si ya de por si, el XML es un formato de datos muy poco conciso, el formato SOAP es bastante verbose (al igual que mis posts). Esto evidentemente es un problema cuando queremos trabajar con anchos de banda reducidos (modems, móviles 3G, etc.). Otra característica importance de SOAP es que es neutral con respecto a la infraestructura. Esto te permite invocar procedimientos remotos a través de distintos protocolos, como por ejemplo SMTP, MQSeries, y como no, HTTP. Fijaos que SOAP no fue diseñado para aprovechar HTTP, sino que permite usar HTTP entre otros protocolos. ¡Qué chulo! debieron de pensar los arquitectos de SOAP. Bueno, lamento comunicar que a mi lo que me interesan son los servicios web, lo que me interesa es invocar a un servicio de la forma más eficiente usando la web, el hecho de que SOAP pueda invocar servicios no web me parece irrelevante, no me interesa. El hecho de que SOAP sea neutral con respecto a la infraestructura, evita que éste pueda aprovechar cualquier ventaja de la infraestructura web, e incluso en algunas ocasiones puede provocar problemas.

Por otro lado, tenemos WSDL, que es un formato XML que te permite describir, de forma declarativa, el modo de acceso al servicio. El WSDL es el documento o contrato que debe distribuirse a todos los clientes para que éstos tengan toda la información necesaria que les permita acceder al servicio. También es usado por los frameworks de publicación de servicios web y por las herramientas de generación de código, tanto a nivel cliente como servidor. En un documento WSDL hay que definir varios artefactos: tipos de datos, mensajes, operaciones, portTypes, bindings, ports y services. Casi nada. Los tipos de datos se definen con XML Schema, recordemos que SOAP sólo usa XML. Los mensajes definen los documentos XML que van a moverse entre el cliente y el servidor. Para definir un mensaje hay que especificar de que partes o secciones se conforma este y de que tipo de datos son cada una de estas secciones. Las operaciones definen parámetros de entrada y salida y posibles excepciones. Cada parámetro y excepción debe corresponderse con un mensaje. Por fin llegamos al portType, que es simplemente la interfaz del servicio, es decir, el conjunto de operaciones que soporta el servicio. Hasta aquí la parte «abstracta» o lógica del WSDL. Daos cuenta de todo lo que hemos tenido que definir para especificar una interface. Si os fijais el enfoque real de todo esto es RPC, aunque existan cosas como «SOAP Document binding». Ahora viene la parte «concreta» del WSDL. Como SOAP es neutral al protocolo tenemos que definir que protocolos se va a usar y como se va a usar. Para ello tenemos los bindings, que define el protocolo a usar (en este caso siempre SOAP) y como se va a codificar los mensajes usando SOAP (RPC o Document), para cada mensaje y operación. Después está el port, que define la dirección donde se va a publicar cada binding, dirección que depende del protocolo de transporte usado. En caso de usar HTTP, será una URI. Finalmente el servicio es el contenedor de todos los ports disponibles. Imaginaos escribir todo esto para un sistema de verdad, imaginaos tener que leer todo esto para consumir un servicio. Como veis en un WSDL hay mucha información y muy compleja, lo que genera mucho acoplamiento entre el consumidor y el proveedor del servicio.

Bien el resultado de las primeras versiones de esto del SOAP y del WSDL a nivel de interoperabilidad, fueron… como decirlo… una buena pifia. Basicamente la interoperabilidad era muy limitada. La complejidad del estándar llevó a implementaciones de distintos fabricantes no interoperables. Debido a esta situación se sacó otro estándar el WS-I Basic Profile, encargado de aclarar y simplificar SOAP y WSDL para una mayor interoperabilidad. En el fondo se recomienda usar una versión restringida de SOAP y aclara aspectos del WSDL. Con el tiempo, y este nuevo estándar, se ha llegado a conseguir una interoperabilidad aceptable, desde mi punto de vista se puede conseguir interoperabilidad a nivel público, pero a nivel global es más discutible.

El nivel de complejidad de estos estándares hace que un programador normal no sea capaz de publicar un servicio web o de consumirlo. La única manera práctica de trabajar con esta tecnología es usar herramientas potentes de generación de código en conjunción con un framework potente. Este enfoque tiene varios problemas a mi manera de ver las cosas:

• Normalmente estas herramientas suelen costar dinero. Afortunadamente esta circunstancia está desapareciendo.
• El código generado por las herramientas es siempre inmantenible.
• La configuración generada por las herramientas suele ser inmantenible.
• El WSDL hay que escribirlo. Aunque lo hagas con un editor visual, tienes que seguir entendiendo como combinar portTypes, messages, ports, etc. Este WSDL hay que mantenerlo después.
• En el caso de que puedas generar el WSDL a partir de la interfaz que hayas programado en tu lenguaje favorito, tienes que cerciorarte que sigue WS-I Basic Profile, para que sea interoperable.

Desde el punto de vista del mantenimiento surge el problema de que nadie entiende nada de lo que hace el sistema, es muy difícil de razonar lo que está ocurriendo. Es curioso, hace unos meses ayudé a un compañero a resolver un bug en un web service basado en SOAP. Aparte de que fue infernal, lo gracioso es que para poder averiguar donde estaba el fallo, tuvimos que rastrear los mensajes HTTP, para averiguar que una cabecera estaba siendo enviada mal, y pudimos cambiar el binding del WSDL para arreglarlo. Es irónico, se supone que SOAP te esconde del HTTP, pero tuvimos que aplicar nuestros conocimientos de HTTP para poder averiguar donde estaba el error. No quiero saber lo que hubiera pasado con alguien que no supiera HTTP.

Otro problema de SOAP es que consume bastantes recursos de computación, con lo que es difícil que pueda ser usado por clientes como móviles o aplicaciones RIA (recordemos que el JavaScript no es muy rápido que digamos en los browsers actuales). Esto es un fallo grave, ya que lo ideal es que una aplicación móvil o RIA pudiera acceder a servicios web.

En resumen, los problemas de SOAP/WSDL son:

• Es complejo y difícil de entender.
• Necesitas un framework complejo.
• Necesitas una herramienta compleja para que te genere el código, código generado que es inmantenible.
• No funciona muy bien con dispositivos móviles y aplicaciones RIA basadas en javascript.
• Es ineficiente desde el punto de vista del ancho de banda.
• Sólo sirve para XML (con adjuntos binarios)
• No aprovecha la infraestructura web, como caches, negociación de formatos, negociación de idioma, seguridad, sistema de concurrencia optimista, etc. Por supuesto no es firewall friendly. Aunque lo hayan vendido como tal, no lo es. SOAP usa el protocolo HTTP como un mero medio de transporte. No aprovecha sus características, y subvierte la semántica de este último. Esto hace que las llamadas SOAP sean «opacas» desde el punto de vista de la infraestructura web, como caches o firewalls. De hecho necesitas un nuevo tipo de firewall, el firewall de aplicación, que entienda SOAP y que necesita parsear todo el cuerpo de la petición para poder aplicar reglas de seguridad. Adios a securizar por URLs, puertos y verbo HTTP.
• El programador necesita ser un «master del universo» y saber rezar.
• Rellene aquí su experiencia de terror favorita con SOAP:__________________________________

Debido a todas estas complicaciones, algunos movimientos como SOA y BPM no han tenido una implantación real (aunque sí fingida) en las empresas. Si ya hay problemas para usar SOAP para comunicación punto a punto, imaginaos la que se monta con todo esto del SOA, ESBs y BPM. Es una pena, porque los conceptos de SOA y BPM son realmente valiosos, el fallo ha sido basarlos en una tecnología que no es la adecuada: SOAP.

Consciente de todos estos problemas, algunos arquitectos con sentido común, y algunas empresas que necesitan interoperabilidad global empezaron a impulsar un nuevo (en realidad viejo) enfoque para la construcción de servicios web. Este enfoque es REST. En el próximo post voy a explicar de que va esto de REST y qué es lo que tiene de bueno. Como veremos en el siguiente post la principal ventaja de REST es que… «it just works», ah no, que eso eran los apple.

Los que piensen que esto del REST es una patraña, debeis tened en cuenta que:

• Está en uso por las empresas más grandes del mundo a nivel global, y a ellos les funciona.
• Algunas grandes empresas, que venden SOAP, ahora están empezando a vender REST
• La última versión de WSDL, WSDL2.0, ahora soporta no sólo SOAP sino también REST. Además WSDL2.0 ha sido simplificado, eliminando por ejemplo, el concepto de mensajes, y ha sido modificado para que sea más REST friendly.

Curioso este movimiento hacia WSDL2.0 ¿Debemos usar WSDL2.0 para nuestros servicios REST? No gracias, no necesitamos WSDL. Como veremos los servicios REST son autodescubribles y basado en estándares, y no necesitamos ningún WSDL, ni similar, para poder trabajar con REST. Desde mi punto de vista WSDL2.0 es una acción desesperada para intentar salvar SOAP/WSDL y la pila WS-*.  Bueno, hasta el próximo post, donde nos meteremos en faena con esto del REST.

ACTUALIZACION: Hoy en el trabajo un compañero me ha contado una historia de terror. Un WSDL de un proyecto al pasarse por la herramienta de generación de código JAVA, ha generado más de treinta mil lineas de código. En fin, para los que penseis que soy exagerado.

Read Full Post »