Síncrono o asíncrono, he ahí la cuestión

por

A lo largo de este blog hemos comentado varias veces que la Orientación a Servicios supone un cambio importante de enfoque en la manera de diseñar los sistemas de información en un Ecosistema de Información. El impacto es mayor aún cuando nos basamos en una arquitectura conducida por eventos (EDA), porque introduce uno de los cambios más llamativos respecto de la forma tradicional de integrar sistemas: la asincronía; y con ella, el desacoplamiento. Así que en nuestra labor como consultores y arquitectos SOA, nos veremos a menudo en situaciones donde surge la duda: ¿patrón de integración síncrono o asíncrono?.

 

En esta entrada vamos a ocuparnos en profundidad de esta cuestión. En primer lugar analizaremos el patrón de integración síncrono, y después analizaremos el correspondiente patrón asíncrono.

Patrón de integración síncrono tradicional.

 

Esquema general del patron de integracion sincrono

 

 

Este gráfico muestra un esquema muy simplificado del escenario habitual en una organización, en lo que se refiere a la integración de sus sistemas. Vamos a suponer en todo el ejemplo que se utilizan servicios web como implementación tecnológica de los servicios.

 

El proveedor del servicio síncrono.

En la parte baja, un determinado sistema publica un servicio web para poner a disposición del resto una determinada información, mediante el patrón petición-respuesta.

 

En el ámbito funcional que afecta a este sistema de información, se producen eventos de distinto tipo (acciones humanas, procesos automáticos, o tareas programadas, entre otros). Algunos de estos eventos alteran la información contenida en su base de datos, de manera que la información correspondiente a la entidad que mantiene este sistema, evoluciona de acuerdo a dichos eventos. Supongamos, por ejemplo, que este sistema es el encargado de mantener la información de los clientes de la compañía.

 

En un determinado momento del tiempo puede darse de alta un cliente, modificarse o eliminarse. Estas operaciones básicas se suceden a lo largo del tiempo. En el gráfico hemos representado un determinado momento en el tiempo (Tiempo 1), en el que sucede uno de estos eventos (Evento 1). No olvidemos que antes de ese instante han sucedido otros eventos sobre la entidad «Clientes», y tras él continuarán sucediendo otros eventos.

 

En el patron de integracion sincrono, el proveedor del servicio publica un servicio web para ser invocado por el resto de sistemas

 

Pero nuestro sistema simplemente los procesa localmente. De cara al resto de la organización, simplemente tiene un servicio web publicado para que sea invocado por el resto de sistemas que puedan necesitar su información.

 

Los sistemas consumidores del servicio síncrono.

Ahora fijémonos en el sistema de la izquierda. Este sistema tiene su propio ámbito funcional, y sus usuarios lo utilizan para, por ejemplo, mantener el estado de la facturación y cobros de la organización.

 

En un determinado momento, en alguno de sus casos de uso, se integra con el sistema de mantenimiento de clientes mediante una llamada al servicio web que aquel sistema tiene publicado. En este otro momento (Tiempo 2) este sistema invoca al servicio web para solicitar la información de un cliente.

 

En el patron de integracion sincrono, el consumidor del servicio maneja informacion desactualizada mientras no invoque al proveedor del servicio

 

Dependiendo de la calidad de las comunicaciones y su estado en el momento de la invocación, nuestro usuario podría encontrar un tiempo de espera poco razonable. Es más, podría ocurrir que en el momento de esa invocación, el servicio web no estuviera disponible (por diversos motivos, desde un problema puntual de comunicaciones, o un problema temporal del sistema operativo, o un problema de la propia aplicación en un momento de bloqueo de tablas en su base de datos, etc, etc).

 

En este caso nuestro usuario recibiría un mensaje de error y tendría que volver a consultar la información.

 

Supongamos que el servicio web responde, y devuelve la información del cliente. Ahora nuestro usuario puede continuar su trabajo con una información que no volverá a actualizarse hasta que vuelva a darse un caso de uso que incluya la invocación al servicio web de consulta de clientes. Hasta ese momento nuestro usuario estuvo trabajando con información obsoleta, que solo se actualizó cuando el servicio web remoto fue invocado y éste respondió.

 

Mientras tanto, en nuestro primer sistema, los eventos que están sucediendo pueden estar afectando a ese mismo cliente: un cambio de domicilio, un cambio de datos bancarios, un cambio de teléfono de contacto, o simplemente, una baja del cliente. De todos estos acontecimientos nuestro sistema 2, de facturación y cobros, no se enterará hasta que vuelva a invocar al servicio síncrono.

 

Pasemos ahora al sistema de la derecha. Este sistema podría ser por ejemplo el encargado de las reclamaciones de los clientes.

 

Cuando este sistema necesita consultar los datos de un cliente, utiliza el mismo servicio web de consulta de clientes que publica nuestro primer sistema. Pero esto ocurre normalmente en otro momento (Tiempo 3), posiblemente cuando un cliente presenta una reclamación, o cuando dicha reclamación va a ser resuelta.

 

En el patron de integracion sincrono, los consumidores del servicio dependen del proveedor del servicio para poder ofrecer informacion actualizada a sus usuarios

 

Es bastante probable que la información que consulta este sistema en este momento del tiempo sea distinta de la que consultó el sistema de facturación y cobros. Y además, podría pasar perfectamente que tras consultarla, ocurra un evento sobre la entidad «Clientes» de cierta relevancia para todo el negocio, como por ejemplo que el cliente se diera de baja de la compañía.

 

Habitualmente, los sistemas que tienen este tipo de integraciones cuentan con otros procesos diferidos que tratan de conciliar de forma masiva toda la información de clientes en los distintos sistemas interesados. Pero durante una porción de tiempo considerable, la información de los clientes a lo largo de todo este reducido mapa de sistemas ha carecido por completo de integridad referencial, un requisito básico y crucial para la calidad de la información, y por tanto del funcionamiento de una organización.

 

En un patrón de integración síncrono, el proveedor del servicio publica un servicio web para ser invocado. Los consumidores del servicio invocan dicho servicio web para obtener la información que necesitan.

 

El Cuadro de Mando ante un patrón de integración síncrono.

Antes de terminar con este modelo síncrono, observemos ahora el sistema que aparece en la parte superior del gráfico. Se trata de un perfil directivo, que utiliza cuadros de mando y sistemas de explotación de la información, para obtener vistas agregadas y estadísticas, que le ayuden en la toma de decisiones corporativas que afectan al funcionamiento de la compañía y a sus decisiones estratégicas.

 

Con todo este panorama de informaciones desactualizadas y eventos que no se conocen, ¿qué está viendo este usuario?.

 

En el patron de integracion sincrono, los Cuadros de Mando muestran informacion desactualizada y de baja calidad, afectando a la toma de decisiones

 

En un determinado momento, aleatorio, ¿está seguro de tener una visión real, completa, precisa y homogénea de lo que sucede en su mapa de sistemas? Quizá justo después de que se concilien los datos en todo el mapa de sistemas, puede tener una visión homogénea.

 

Pero ¿es real?, ¿es completa?, ¿es precisa? ¿cuánto tiempo mantiene la calidad necesaria?.

 

Llegados a este punto parece claro que la duda entre usar un patrón de integración síncrono o asíncrono está más clara. Pero sigamos.

 

Patrón de integración asíncrono (arquitectura conducida por eventos).

 

Esquema general del patron de integracion asincrono

 

 

En este otro gráfico vemos el mismo mapa de sistemas, pero esta vez bajo una estrategia SOA que usa la arquitectura conducida por eventos (EDA) como principio de diseño. Analicemos la situación que hemos descrito anteriormente sobre este nuevo enfoque.

 

Para empezar tenemos un nuevo actor: la infraestructura SOA. Para el propósito de esta entrada, supongamos solamente un ESB muy ligero con algunas de las capacidades usuales en el mercado: políticas de reintento configurables, garantía de entrega, persistencia, auditoría, adaptadores para distintas tecnologías (servicios web y otros), etc.

 

El proveedor del servicio asíncrono.

Fijémonos en el sistema de mantenimiento de clientes, abajo del todo.

 

En el patron de integracion asincrono, el proveedor del servicio entrega al Ecosistema de Informacion cada evento de negocio en tiempo real

 

Ahora este sistema no publica un servicio web. Ahora, cada evento que ocurre sobre la entidad «Clientes» es comunicado a la infraestructura SOA mediante un servicio web publicado en ella. Esta comunicación es síncrona entre estos dos actores: nuestro sistema recibe una respuesta desde el ESB en el mismo hilo, validando la entrega y corrección del mensaje que hemos enviado con el alta, modificación o eliminación del cliente (o el evento que sea).

 

¿A quién envía esa información? Ni tiene por qué saberlo, ni le interesa. Digamos que la envía al Ecosistema de Información. Y para nuestro sistema de mantenimiento de clientes, con la confirmación de entrega al Ecosistema, es suficiente para dar por finalizada su transacción con éxito.

 

Hasta aquí lo que tenemos es la seguridad de que todos los eventos que ocurren a la entidad «Cliente» llegan a la infraestructura SOA de nuestra organización en tiempo real.

 

Los sistemas consumidores del servicio asíncrono.

Ahora fijémonos un momento en los sistemas de facturación y de reclamaciones.

 

Ambos sistemas ahora publican un servicio web, que es invocado por la infraestructura SOA. ¿Cuándo? Tan pronto como ésta recibe un evento al que estos sistemas están suscritos. La infraestructura SOA mantiene listas de suscripción que le permiten conocer, ante la llegada de cada evento, qué sistemas necesitan conocer esa información.

 

De esta manera, la información fluye en tiempo real a todos los sistemas que necesitan conocerla.

 

En nuestro ejemplo, tanto el sistema de facturación como el sistema de reclamaciones reciben mediante sus respectivos servicios web el evento que ha enviado el sistema de mantenimiento de clientes, y lo reciben en el mismo instante (o como mucho segundos después).

 

En el patron de integracion asincrono, el consumidor del servicio recibe los eventos de negocio a traves del ESB, que garantiza la calidad y disponibilidad de la informacion en todo el Ecosistema de Informacion

 

Cada una de estas invocaciones que hace la infraestructura SOA es síncrona entre ambos interlocutores, y tan pronto recibe la confirmación de entrega en cada destino, el envío se da por correcto.

 

¿Qué ocurre si no llega tal confirmación? En ese caso las políticas de reintento definidas en el ESB se ejecutan automáticamente hasta obtener respuesta del destino. Si la respuesta es correcta, termina el proceso. Si la respuesta no es correcta, se registra el error y se interrumpen los intentos de entrega.

 

En una abrumadora mayoría de las ocasiones, los eventos llegan a todos sus destinos prácticamente en tiempo real (o tras pocos reintentos) y con resultado correcto. Hasta tal punto es abrumadora la mayoría de entregas con éxito que los ESB presumen de la garantía de entrega como una característica de fábrica.

 

Gracias a esto, la información en todo el mapa de sistemas es correcta, homogénea y está actualizada.

 

Cada una de las comunicaciones entre cada extremo es síncrona (lógicamente), pero la integración entre los tres sistemas es asíncrona. Ninguno de los sistemas depende de ninguno de los demás para el éxito de sus casos de uso. Esto se llama desacoplamiento.

 

Por último pensemos en el perfil directivo que quiere ver acceder a la información agregada y estadística de la compañía. En este segundo escenario, siempre va a contar con información real, actualizada y completa.

 

En un patrón de integración asíncrono, el proveedor del servicio invoca un servicio web publicado por la infraestructura SOA. Los consumidores del servicio publican un servicio web para que sea invocado por la infraestructura SOA, cuando reciba un evento desde el proveedor del servicio.

 

Conclusión: ¿patrón de integración síncrono o asíncrono?

En algunas determinadas circunstancias el patrón de integración síncrono puede estar indicado. Pero la asincronía y el desacoplamiento traen importantes ventajas adicionales al mapa de sistemas de una organización. Tan importantes que debemos contemplar el patrón asíncrono como primera opción en todos los casos.

 

En un mapa síncrono, cuando se necesita evolucionar de alguna manera el sistema de información de clientes (o cualquier otro), pueden identificarse efectos colaterales (impactos) en el resto de sistemas. Los proyectos se encarecen innecesariamente, y podría darse el caso incluso de no ser viables hasta pasado un tiempo, por limitaciones del presupuesto disponible, o de equipo suficientemente cualificado.

 

En un mapa asíncrono, en cambio, cuando la organización necesita modificar uno de los sistemas de información, los impactos colaterales no se presentan. Cada sistema de información puede evolucionarse de forma independiente, y si el cambio alcanza a más de un sistema, pueden acometerse ambos proyectos de forma independiente en el tiempo, resolviendo cualquier eventualidad temporal en la infraestructura SOA (transformaciones, mapeos, etc).

 

De esta forma, la capacidad de toda la organización para adaptar sus sistemas a las necesidades del negocio es mucho mayor.

 

Así que por mi parte, duda resuelta: ¿es mejor usar un patrón de integración síncrono o asíncrono?. Sin duda, elijo el patrón asíncrono.

 

Te puede interesar

0 comentarios

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