Manejo de transacciones en SOA

Un desarrollo de software basado en una solución arquitectónica SOA se destaca generalmente por un sistema distribuido basado en la comunicación e interacción de servicios. Una arquitectura SOA puede incluir entonces distintas plataformas y tecnologías, por lo que el monitoreo de la comunicación entre los distintos servicios que proveen la funcionalidad del sistema es crucial para el éxito del sistema.

Un aspecto que sobresale en este contexto es el transaccional. Típicamente, el concepto de una transacción involucra una serie de pasos que tiene que cumplir la siguiente propiedad: o se hacen todos los pasos, o no se hace ninguno. Es decir, que si alguno de los pasos fallara, se debe volver atrás y deshacer las acciones realizadas hasta el momento. Todo debe quedar como si nunca nada hubiera pasado, para luego reintentar llevar a cabo la transacción.  Un ejemplo canónico para ilustrar el concepto de transacciones es un sistema bancario, donde cada una de las operaciones debe cumplir esa característica transaccional: no puede ocurrir que un error deje en estado inconsistente el saldo de una cuenta. Formalmente, se dice que una transacción debe cumplir las propiedades ACID [1]: Atómica, Consistente, Aislada  y Durable.

Claramente el concepto de transacciones en un entorno con un alto perfil distribuido como una solución SOA juega un rol preponderante, y debe prestarse especial atención a aquellos servicios que necesiten ejecutarse de manera transaccional.

Transacciones en SOA

Para implementar un servicio dentro de un esquema SOA con un perfil transaccional es clave monitorear todo el tiempo la comunicación entre los componentes. Es decir, el atributo de calidad conocido como disponibilidad, que se concentra en el manejo de fallas, tendrá un papel determinante.

Para llevar a cabo este monitoreo, empresas como SOA SOFTWARE (www.soa.com) ofrecen servicios y productos dedicados. Los mismos están basados en tres pilares: monitoreo, para poder tener conocimiento exacto del lugar de una falla, transaction tracking, para poder deshacer acciones previas una vez detectada una falla, y SLA (Service Level Agreement), para tener un contrato que establezca la calidad del servicio.

Patrones para la implementación de transacciones

Otra opción más artesanal surge de aplicar un patrón arquitectónico de SOA, como lo es el patrón Servicio Atómico Transaccional [2]. Este patrón ilustra una solución general para implementar servicios de manera transaccional. La descripción del patrón tiene 4 partes:

–          Problema: cuando  un servicio utiliza otros para su solución, y uno de ellos falla, el servicio debe deshacer todas las acciones realizadas para mantener la consistencia del sistema.

–          Solución: encapsular los servicios invocados dentro de un servicio “wrapper” con capacidad de efectuar rollback: es decir, ir hasta el último estado consistente.

–          Aplicación: Un sistema transaccional se incluye en la solución arquitectónica y es utilizado por aquellos servicios que lo requieran.

–          Impacto: existe una sobrecarga en el consumo de memoria, ya que se requieren recursos para mantener el estado de cada uno de los servicios que será utilizado en caso de efectuar un rollback.

La figura 1 (obtenida desde [2]) muestra un ejemplo de este patrón. Los servicios A y B completan sus tareas de manera exitosa. Sin embargo, cada vez que lo hacen inician una transacción local, guardando en una base de datos su estado actual antes de realizar cualquier cambio (puntos 1 y 2 en sus figuras). Luego, una vez que el servicio C falla (punto 3 en la figura), los servicios A y B efectúan un rollback, para volver al último estado actual consistente (puntos 4 y 5).

Conclusiones

El manejo de transacciones nunca es trivial, y menos aún dentro de una arquitectura SOA, donde existe una alta frecuencia de interacción entre servicios conectados a través de distintas plataformas y tecnologías. Se debe proceder con cuidado en la detección de los servicios que requieran características transaccionales, y proceder a cumplir con la misma dentro de la solución. La correcta detección de estos servicios es clave para evitar una sobrecarga en los recursos y la calidad del sistema.

Referencias:

[1] http://es.wikipedia.org/wiki/ACID

[2] http://soapatterns.org/design_patterns/atomic_service_transaction