Control-Z

Uno de los fundamentos de SOA es la composición de servicios. Es decir, crear servicios de más alto nivel a partir de otros servicios más sencillos. Hasta aquí todo bien, pero… ¿que pasa con el servicio compuesto si uno de esos servicios más sencillo falla?.

Si hacemos un servicio compuesto que llama a un primer servicio que modifica el estado de los datos y luego llamamos al segundo, y este falla… ¿que ocurre?. Si consideramos este servicio compuesto como un “todo”, tendríamos que deshacer también lo que ha hecho el primer servicio ¿no?.

Tradicionalmente, este deshacer o rollback de varias lógicas de negocio se ha delegado al protocolo de transaccionalidad distribuida (Two Phase Commit) que implementan la mayoría de las bases de datos y servidores de aplicaciones empresariales. De esta manera, los dos servicios e “incluyen” dentro de una transacción (aunque se ejecute en dos máquinas diferentes) y cuando se produce un error, al hacer rollback, automáticamente se deshacen los cambios que hayan hecho estos dos servicios.

¿Pero que pasa en SOA? decimos que los servicios deben tener bajo o ningún acoplamiento entre sí. ¿Como se lleva eso con el hecho de que los dos sistemas implicados en este caso deben entender un protocolo común de transaccionalidad distribuida?. No parece que haya mucho desacoplamiento.

El stack WS-* define un estándar para realizar esto a nivel del web services. Por desgracia, no hay uno si no dos (al menos de estos estándares). Y si no tenemos mucha suerte, cada fabricante usará uno distinto. Esto es lo que pasa por ejemplo con el servidor de IBM y el de Software AG.

¿Qué solución tenemos a esto? pues según los patrones de SOA, la compensación. El concepto es muy simple, por cada servicio de negocio que haga algo, tendremos otro servicio para deshacerlo (una especie de Control-Z o undo a nivel de servicio).

Por desgracia, esto no es un deshacer directo a nivel de tabla de base de datos como lo es un rollback, implica ejecutar lógicas de negocio y por lo tanto, los servicios para deshacer o para “compensar” necesitan diseñarse e implementarse de la misma manera que sus contrapartes.

Así pues, y como conclusión, cuando diseñemos un sistema SOA, habría que tener en cuenta estos dos puntos:

  • No podemos confiar en que todos los sistemas (servidores de aplicaciones, bases de datos) soporten el protocolo de transaccionalidad distribuida e incluso, si lo hacen, que implementen el mismo
  • La transaccionalidad distribuida va en contra del desacoplamiento que deben tener los serviiocs
  • Tenemos que pensar desde el mismo diseño que muchos de los servicios de negocio que hagamos deben tener su servicio de deshacer. Quizás esto implique duplicar el número de servicios a implementar.

Aquí puedes ver un artículo (en inglés) muy extenso sobre este tema.

Anuncios