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?
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?
