Los servicios web y SOA, enemigos íntimos

por

Reconozco que el título de esta entrada es un tanto exagerado, lo sé. Pretendo ilustrar la buena y frecuente relación que tiene SOA con los servicios web, y lo peligroso que es confundir esa buena relación con una relación de composición o pertenencia, como si fueran conceptos ligados.

En esta entrada vamos a intentar marcar la frontera entre los servicios web y SOA, a pesar de que en muchos sitios, y para muchos profesionales, ambos van de la mano. Ciertamente es frecuente el uso de servicios web para implementar los servicios SOA, pero es importante ser plenamente consciente de que no es necesario. Y por tanto usar los servicios web para definir SOA, o para definir los servicios SOA, tan solo crea confusión.

¿Qué son los servicios web? A estas alturas es fácil encontrar por internet la definición, por ejemplo ésta. Como podéis ver, los servicios web suponen la última etapa en la búsqueda de una forma de interconectar sistemas de información a través de internet para compartir datos, sin importar sus tecnologías, plataformas, ubicación, etc. Para este objetivo los servicios web están muy indicados al poder usar el protocolo http sobre tcp en el puerto 80, que es por así decirlo la forma estándar que usa internet para conectarnos a todos.

Otra novedad que introdujeron los servicios web fue el concepto de «contrato» entre los sistemas implicados, un contrato a nivel tecnológico, especificado mediante el WSDL (Web Service Description Language). Esta novedad permitía garantizar que ambas partes conocían perfectamente la interfaz, operaciones, y parámetros, publicados por el proveedor del servicio web, y aportaba un cierto nivel de encapsulamiento.

Por tanto, los servicios web parecen la mejor opción tecnológica para interconectar sistemas remotos a través de internet y así poder intercambiar datos.

Recordemos de nuevo la idea central que hay en los servicios web: hacer disponible cierta información al exterior de un sistema. Pero cuando hablamos de la estrategia SOA, no estamos hablando del mismo problema, no estamos en el mismo escenario.

Una estrategia SOA no necesita usar servicios web, pero encajan perfectamente, y usar servicios web no es suficiente para tener SOA

 

El problema de la interoperabilidad para una organización no consiste solo en querer comunicar sistemas remotos de distintas plataformas conectados a internet, ni de publicar determinada información al exterior.

El problema de la interoperabilidad consiste sobre todo en compartir procesos dentro de una organización, no solo fuera. De hecho, es precipitado preocuparse por la interoperabilidad externa a una organización si internamente, en su mapa de sistemas, no está resuelto el problema. Y dentro de una organización, los servicios web tienen menos sentido que en internet. En principio, si los datos que se quieren publicar no van a estar disponibles al mundo (en internet), no tiene tanto sentido publicarlos mediante un servicio web.

Ocurre a menudo, sin embargo, que incluso en el seno de una organización es muy complejo gestionar la accesibilidad a los distintos sistemas de información. Si la organización es grande, compleja y de gran amplitud geográfica (y especialmente en el sector público), es muy probable que sus sistemas de información utilicen las ventajas de los servicios web para interconectar sus sistemas sin demasiadas complicaciones, y aprovechando además las ventajas del WSDL.

Incide también en esta dinámica una especie de mala praxis en las empresas proveedoras de TIC y en las propias organizaciones, mezclada con una falta de visión global. Al diseñar un sistema de información hay que tener siempre presente que se trata de una pieza de un sistema mayor, la propia organización, y que lo fundamental es que ese macro sistema funcione de forma óptima.

Con el nuevo siglo se ha producido una proliferación de servicios web como medio para resolver las necesidades de integración entre los sistemas de información dentro de una organización. Una proliferación casi siempre descoordinada y sin unas directrices globales, mezclada con otras muchas soluciones tecnológicas (aplicaciones embebidas, accesos a bases de datos, réplicas de tablas, ficheros por ftp, etc), que conduce inexorablemente a nuestro plato de pasta favorito.

Recordemos ahora dos inconvenientes que tienen los servicios web como solución tecnológica de integración en una organización:

  1. si un servicio web no está disponible en un momento determinado, los sistemas que lo invoquen recibirán un error. Esta obviedad no puede permitirse en una organización que pretende resolver el problema de la interoperabilidad.
  2. los servicios web son publicados por un sistema (proveedor del servicio web), que responde de forma reactiva a la invocación desde otro sistema (consumidor del servicio web). Esta invocación se produce cuando éste necesite la información que aquél publica. Este patrón, conocido como «petición-respuesta», introduce sincronía en la comunicación, y por tanto un acoplamiento transaccional entre el sistema consumidor del servicio web y el sistema proveedor del servicio web. Si el proveedor no está a la escucha en el instante en que el consumidor lo invoca, el proceso falla, con el consiguiente riesgo de inconsistencia en la información. Y si el proveedor modifica el servicio web, los consumidores deberán modificar sus invocaciones.

Usar servicios web sin una estrategia SOA conlleva problemas de calidad y disponibilidad de la informacion

 

Para el primer problema, SOA usa el ESB. Los ESB incluyen de serie facilidades para configurar políticas de reintentos que mitigan el riesgo de indisponibilidad del sistema destino de la mensajería, y cumplir así uno de sus compromisos base: la garantía de entrega.

Para el segundo problema, la estrategia SOA cuenta con el enfoque de EDA. Con este enfoque los roles de proveedor y consumidor de servicios SOA se intercambian respecto del rol de proveedor y consumidor de servicio web. Primero porque son cosas distintas, y segundo porque la orientación a eventos de negocio introduce el máximo desacoplamiento mediante una mensajería asíncrona a nivel transaccional, de manera que los sistemas de información no tienen que esperar a ver qué hace el otro sistema.

En una estrategia SOA (con EDA) que use servicios web para implementar los servicios de negocio y de infraestructura, los sistemas que publican servicios web para recibir los mensajes asociados a un evento de negocio son los consumidores del servicio, y el sistema de información que comunica el evento mediante el mensaje correspondiente es el proveedor del servicio, y para ello invoca a un servicio web publicado por el ESB. Tanto la invocación al ESB por parte del proveedor del servicio como la invocación por parte del ESB a los consumidores del servicio, se realizan en hilos diferentes, desacoplados, dejando en el ESB la responsabilidad de validar el mensaje, transformarlo, mapearlo y garantizar su entrega mediante las políticas de reintentos que se determinen. En una próxima entrada detallaremos mejor algunos patrones típicos de comunicación que caben en este escenario, es un asunto interesante.

 

Es importante tener claro el intercambio de roles cuando hablamos de servicios web y servicios SOA:

 

  • En un servicio web, el sistema que lo publica es el proveedor, y los sistemas que lo invocan son los consumidores. Un sistema provee una solución tecnológica a una serie de consumidores.
  • En un servicio SOA, el proveedor invoca a un servicio web publicado por el ESB, y éste invoca a los servicios web publicados por los consumidores del servicio SOA. Un sistema provee un evento de negocio a una serie de consumidores, usando para ello como medio tecnológico los servicios web o cualquier otra solución tecnológica válida.

 

 

Usar servicios web bajo una estrategia SOA garantiza la calidad y la disponibilidad de la informacion

 

Lo más interesante que queremos destacar es que en el seno de una organización la implementación de los servicios SOA no tiene porqué ser mediante servicios web. Pueden usarse otras tecnologías como colas MQ, ficheros, etc. De hecho a veces es lo más acertado (o lo único que resulta viable).

SOA tiene que permanecer independiente de cualquier cuestión tecnológica, para tener la mayor capacidad de implantación, dinamización y transformación del mapa de sistemas de una organización, y para trascender cualquier cambio tecnológico que pueda condicionar decisiones estratégicas en el futuro.

 

Por lo tanto, cuando encontréis artículos, blogs, publicaciones en general sobre SOA, que lo relacionan directamente con los servicios web, recordar añadir mentalmente: «o cualquier otra solución tecnológica válida». Este empeño tan generalizado de asociar los servicios web con SOA crea confusión sobre lo que SOA es realmente, sobre el papel protagonista de la gobernanza, muy por delante de la tecnología. Por esto elegí este título para esta entrada: los servicios web funcionan bien en una estrategia SOA, pero la idea de que son lo mismo está demasiado extendida y eso no ayuda.

 

Son algo así como… enemigos íntimos.

 

Te puede interesar

0 comentarios

Trackbacks/Pingbacks

  1. SOA aplicado a la Robótica: o cómo simular el sistema nervioso central - […] establecen una identidad entre SOA y Web Services… ahí se equivocan, pero como hemos comentado muchas veces no hay…

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Sigueme en las redes

Share This