Servicios autónomos

Hace un par de semanas escribía sobre un curso al que asistí impartido por Udi Dahan y recibí varios comentarios que me pedían los ejemplos que usó Udi para explicar su enfoque SOA basado en el diseño de servicios autónomos en vez de en la reutilización de servicios. Hoy he estado tomando café con mi paisano Jose Carlos del Arco, miembro del comité organizador de JSWEB (Jornadas Científico Técnicas en Servicios Web y SOA) y hemos hablado (¡por supuesto!) de todo esto (y sobre más cosas, claro). Así que no me queda otra que rebuscar entre el desorden de mi mesa dónde demonios dejé esas notas y tratar de explicarlas. Por suerte, este fin de semana pasado he recuperado mi antiguo escáner y creo que podré escribir un poco menos. 🙂

Recordemos que Udi plantea que nuestros servicios deben ser diseñados para ser autónomos. Esto es, para que colaboren con otros servicios, pero que no estén acoplados a ellos (o que el acoplamiento sea el mínimo posible). Para ello trata de que la mayoría de las colaboraciones se hagan asíncronamente (“fire and forget”) y que los datos no sean compartidos sino que haya siempre una única autoridad certificadora de los datos (sólo un servicio escribe y el resto sólo lee). Para lograr que los cambios en los datos estén disponibles en el resto de servicios propone suscripciones a los eventos de cambio en los datos que cada cuál necesita.

Vamos al ejemplo y lo veremos más claro. Cuidado, es un ejemplo para ilustrar la idea de fondo. No lo toméis al pié de la letra.

Supongamos tres departamentos en una empresa (ventas, almacén y marketing).
Supongamos que trabajamos para el departamento de ventas para implementar una aplicación web que permita comprar nuestros productos desde internet. ¡Qué original! ¿Verdad?

La solución que propondríamos sería implementar la aplicación web como más bonita y usable resulte, pero que componerla teniendo en cuenta nuestra orientación a servicios. Así, el catálogo de productos es “propiedad” del Departamento de Ventas, pero el precio y disponibilidad no. Por tanto, para mostrar esta información que nos es ajena tendremos que realizar peticiones a otros Departamentos, es decir, llamadas a los servicios de marketing (para el precio) y de almacén (para la disponibilidad).

Udi, durante el curso, nos habló de cómo se componían las UIs de sitios como eBay o Amazon. Todas tenían en común que se componían a partir de llamadas a diferentes fuentes. Fijaos que hay partes de la UI que son muy estáticas (o casi), como las categorías de productos. Esa parte de la UI puede ser perfectamente el resultado de una llamada a un servicio. A nuestra aplicación web le viene a dar bastante igual si esta semana hemos empezado a vender “palos de fregona”, simplemente debería ser una nueva categoría y poco más, porque nuestra aplicación sabe vender productos que tenemos en nuestro catálogo.

Pero vayamos un poco más “adentro” de la capa de presentación (o incluso podríamos hablar de las aplicaciones, sin más). Los servicios se diseñarán e implementarán buscando que sean autónomos, es decir, que no requieran de otros para completar sus responsabilidades.

En nuestro ejemplo, el proceso de compra de un producto requerirá de la colaboración con otros servicios. Será necesario conocer el precio de un producto o las promociones o el precio de envío por correo urgente… Pero esto no quiere decir que nos tengamos que quedar esperando a que cada uno de los servicios nos responda.

En la figura 1 vemos cómo se suscribe el servicio de Ventas a los otros dos servicios. Así, obtiene los datos que necesita para operar de manera autónoma.

Paso 1) Ventas se suscribe al valor de los precios que posee el servicio de Marketing
Paso 2) Marketing informa de los precios a Ventas (porque éste no tiene ningún precio anterior)
Paso 3) Ventas se suscribe al valor de disponibilidad (“stock”) de los productos que posee el servicio de Almacén
Paso 4) Almacén informa de las cantidades disponibles en almacén de los productos en el catálogo

Por tanto, nuestra aplicación de Ventas puede mostrar toda la información necesaria para que un usuario inicie la compra de productos. Y dado que estamos suscritos a los cambios que se puedan producir tanto en los precios como en las cantidades disponibles, siempre (con un cierto margen) tendremos la información más actual: que es la única que necesitamos. Ahora veremos qué ocurre durante el proceso de compra.

Paso 1) El usuario (la aplicación) ya tiene toda la información necesaria para realizar el pedido e inicia el proceso de compra llamando al servicio de Ventas.
Paso 2) El servicio de Ventas hace sus comprobaciones, entre las que está el comprobar si hay “stock”, y calcula el total de la factura. Todo esto lo puede hacer porque es autónomo.
Paso 3) El servicio de Ventas informa al servicio de Almacén de que hay un pedido que debe ser servido. Lo hace asíncronamente, es decir, no espera a que el servicio de Almacén haga lo que tenga que hacer. Simplemente se asegura de proporcionarle toda la información necesaria para que se pueda realizar el proceso de empaquetamiento y envío del pedido al cliente.
Paso 4) El servicio de Almacén reduce (en su base de datos) el valor del stock de los productos involucrados en el pedido.
Paso 5) Dado que el servicio de Ventas está suscrito a los cambios de disponibilidad de los productos, recibe un mensaje con estos datos actualizados.

Como véis, el proceso de venta de un producto se puede realizar sin necesidad de esperar la respuesta de ningún otro servicio. Es más, el servicio de Almacén podría estar “apagado” y eso no nos afectaría para nada. El paso 3 se “encola” y el servicio de Almacén ya lo consumirá cuando sea. Por otro lado, si los valores de “stock” se mantienen sin cambios durante mucho tiempo, se planteará la decisión de negocio de qué hacer en esos casos: asumir que hay disponibilidad, que no hay disponibilidad, quedarnos con el último valor conocido…

Lógicamente, hay consideraciones a hacer en el caso de que “no todo vaya como la seda”. Hay que definir operaciones de compensación, por ejemplo. Pero si os fijáis, estaremos hablando realmente de automatizar operaciones que ya (probablemente) se están realizando de manera manual en el negocio actual. Por tanto, estaremos alineando la técnica con el negocio. Y demonios, ¿no es de eso de lo que tendríamos que estar hablando?

Tagged:
  • jcesarperez

    Qué detallazo! Muchas gracias. Está muy bien, ahora todo ha quedado mucho más claro.

    Supongo que cuando hablabas de la integridad de datos y de las FKs te referias a que un producto puede desaparecer del servicio ventas pero no aún del de almacen, ya que se hace de forma asíncrona.

  • Jose Manuel Beas

    Correcto. Pero es más, Udi (y otros muchos) defienden la desnormalización de los datos con el objetivo de separar las consultas de las operaciones (buscad en Google por CQS o Command-Query Separation). No se trata sólo de una separación buscando un mejor rendimiento (que también) sino una separación funcional.

  • Jose Carlos

    Gracias por el post, muy ilustrativo y en línea con lo que me comentaste el otro día.

  • Jose Manuel Beas

    Gracias Jose Carlos,

    Lo que creo que no he comentado mucho es esa diferencia de enfoque entre Udi y Tom Erl. Recuerdo que le pregunté explícitamente a Udi por el enfoque que hace Erl de los servicios y me contestó:

    I’m afraid there isn’t very much reconciliation possible between the two views. Tom’s is based on the central principle of reuse. Mine is based on the single responsibility principle. Tom views services more as software constructs. I view services primarily as business constructs (implemented by multiple software constructs – UI, BL, DAL, etc).Vamos, que casi que me voy tirando los libros de Erl que tengo inmaculados. 🙂

  • Emilio Bravo

    Hola Jose Manuel,

    Creo que es una de las explicaciones mas sencillas y claras de una arquitectura SOA que he leído.

    Gracias.

  • Jose Manuel Beas

    Muchas gracias Emilio. El mérito es realmente de Udi Dahan, que es quien me lo explicó en el curso que ya comenté.

    De todos modos, creo que el gran problema que existe en España respecto a SOA es que muchos escribimos (me incluyo) sin suficiente experiencia práctica y luego pasa lo que pasa. Charlando el otro día con Jose Carlos del Arco, comentabamos justamente que muchas de las consultorías que se hacen en España hablan de SOA como una tecnología de integración y, claro, luego pasa lo que pasa…