Transacciones distribuidas en arquitecturas SOA y MSA. Modelo ACID frente a modelo base

Abstract

En el mundo actual las transacciones que afectan a bases de datos son muy importantes en muchas áreas, como en la banca, ya que las operaciones bancarias requieren de una consistencia estricta en temas relacionados con transferencias, pagos, depósitos, retiros, etc. Sin esta consistencia, se podría dar el caso en el cual una transferencia de dinero reste de una cuenta y no sume en otra, dando lugar a una pérdida de dinero o a la corrupción de datos financieros.

Son importantes también en el mundo del comercio electrónico, donde se involucra el manejo de cantidades de inventario, realización de cobros, generación de facturas y actualización de los estados del pedido. Si ocurre un error durante el flujo de un proceso, éste debe deshacerse. El buen o mal funcionamiento de dicho proceso es clave para brindar una buena experiencia para el usuario y generar la confianza con el usuario para que vuelva a visitar la tienda electrónica.

Además, también son relevantes en procesos que involucran múltiples sistemas interconectados que necesitan coordinar acciones (activación de servicios, actualización de historiales clínicos o cadenas de suministros) como en el mundo de las telecomunicaciones, la salud o el Internet de las Cosas, asegurando la integridad de los datos incluso ante fallos parciales o intermitentes. Las transacciones pueden ser de dos tipos, locales o globales. Las locales involucran un único recurso (una base de datos, un servicio o un componente). En ellas se puede aplicar fácilmente un modelo transaccional ACID con soporte directo al sistema de gestión de base de datos. En contraposición, las globales abarcan varios recursos distribuidos (bases de datos, servicios, colas de mensajes) y requieren una coordinación entre los diferentes sistemas para asegurar una consistencia de datos entre los distintos recursos involucrados.

Las transacciones globales tienen varios modelos de implementación, y en este proyecto hemos aplicado dos modelos distintos: el modelo transaccional ACID basado en el commit de dos fases (2PC) y el modelo transaccional BASE implementado mediante el patrón saga.

En el modelo ACID (Atomicity, Consistency, Isolation, Durability) puede aplicarse tanto a transacciones locales como a globales. 2PC (Two-Phase Commit) es un protocolo clásico para las transacciones distribuidas en el cual el coordinador envía una fase de precommit y después una de commit. Es el núcleo de X/Open XA (eXtended Architecture) [5], un estándar para conseguir atomicidad en transacciones globales con recursos distribuidos. Es muy fiable, aunque lento y poco tolerante a fallos (pudiendo haber bloqueos si el coordinador falla permanentemente durante la transacción).

Por otro lado, en el modelo BASE (Basically Available, Soft state and Eventual consistency) se prioriza la disponibilidad y el rendimiento frente a la consistencia inmediata, aceptando cierta inconsistencia temporal, la cual es corregida eventualmente. El patrón saga permite implementar transacciones BASE donde cada servicio ejecuta su parte de la transacción distribuida de forma local y si hay algún fallo, se ejecutan transacciones de compensación. Este patrón tiene dos implementaciones posibles, mediante coreografía (cada servicio desencadena el siguiente) o mediante orquestación (un servicio central dirige la transacción). Las transacciones BASE tienen varias desventajas, como la lógica de compensación (que puede ser complicada), que no garantizan un rollback total perfecto o la inconsistencia (a pesar de ser eventual) en los recursos transaccionales involucrados.

El objetivo de este TFG se centra en la implementación de una aplicación web similar a Booking.com para comparar la arquitectura orientada a servicios web con transacciones distribuidas ACID frente a una arquitectura orientada a microservicios con transacciones distribuidas BASE. Ambos proyectos han sido implementados en Java y utilizando el marco de trabajo Spring Boot para exponer los servicios web al usuario final.

La aplicación, tanto en su versión ACID, como en la BASE, permite gestionar reservas de vuelo y hotel, tanto independientemente unas de otras como en conjunto, en formato de paquete de viaje todo en uno.Distributed transactions in SOA and MSA architectures. ACID model VS. BASE model In today’s world, transactions that affect databases are crucial in many areas, such as banking, where financial operations require strict consistency in matters related to transfers, payments, deposits, withdrawals, etc. Without such consistency, situations could arise in which a money transfer deducts from one account without being added to another, resulting in financial loss or data corruption.

They are also important in the world of e-commerce, where inventory management, payment processing, invoice generation, and order status updates are involved. If an error occurs during the flow of a process, it must be undone. The proper or improper functioning of such a process is key to providing a good user experience and building trust so that the customer returns to the online store.

Additionally, transactions are relevant in processes involving multiple interconnected systems that need to coordinate actions (such as service activation, updating medical records, or supply chain logistics), in fields like telecommunications, healthcare, or the Internet of Things. They help ensure data integrity even in the face of partial or intermittent failures.

Transactions can be of two types: local or global. Local transactions involve a single resource (a database, service, or component). In those transactions the ACID transaction model can be easily applied to them with direct support from the database management system. In contrast, global transactions span multiple distributed resources (databases, services, message queues) and require coordination among different systems to ensure data consistency across all involved resources.

Global transactions have several implementation models, and in this project, we applied two different ones: the ACID transaction model based on the Two-Phase Commit (2PC) and the BASE transaction model implemented by the saga pattern.

The ACID model (Atomicity, Consistency, Isolation, Durability) can be applied to both local and global transactions. 2PC (Two-Phase Commit) is a classical protocol for distributed transactions in which the coordinator sends a pre-commit phase followed by a commit phase. It is at the core of X/Open XA (eXtended Architecture) , a standard for achieving atomicity in global transactions with distributed resources. It is very reliable, although slow and not very fault-tolerant (there may be blocking if the coordinator permanently fails during the transaction).

On the other hand, the BASE model (Basically Available, Soft state, and Eventual consistency) prioritizes availability and performance over immediate consistency, accepting a certain degree of temporary inconsistency, which is eventually resolved.

The saga pattern allows for implementing BASE transactions, where each service executes its part of the distributed transaction locally, and in case of a failure, compensating transactions are executed. This pattern has two possible implementations: choreography (each service triggers the next) or orchestration (a central service manages the transaction). BASE transactions have several disadvantages, such as the complexity of compensation logic, the lack of guaranteed perfect rollback, and inconsistency (even if eventual) in the transactional resources involved.

The goal of this Final Degree Project is to implement a web application similar to Booking.com in order to compare a service-oriented architecture with distributed ACID transactions versus a microservices-oriented architecture with distributed BASE transactions. Both projects have been implemented in Java using the Spring Boot framework to expose web services to the end user.

The application, in both ACID and BASE version, allows the management of flight and hotel bookings, both independently and as part of an all-in-one travel package.