XA (del inglés extended architecture [1] , X/Open XA ) es una especificación de transacciones distribuidas que define los principios para la participación conjunta de recursos transaccionales en una transacción en un entorno informático distribuido . Descrito por primera vez en 1992, es el estándar de implementación de facto en administradores de transacciones distribuidas y bases de datos relacionales .
Una transacción XA es una transacción distribuida ejecutada bajo el control de un sistema que se ajusta a la especificación XA.
A principios de la década de 1990, había varios estándares diferentes para transacciones distribuidas, por ejemplo, TPF, utilizado en la aviación civil de EE. UU. y en la década de 2010 [2] , CISC, VMS y otros. Uno de ellos, el SNA de IBM, se había convertido para entonces en el estándar de facto. Influenciada por este estándar y el estándar LU6.2, ISO ha creado varios estándares nuevos [3] :
La principal desventaja de estos estándares era la falta de una API , por lo que especificaban cómo debían interactuar los administradores de transacciones, pero no proporcionaban reglas para escribir aplicaciones portátiles.
X/Open resolvió este problema proporcionando un modelo de transacción distribuida y, al mismo tiempo, especificando una interfaz de procedimiento para la interacción de los participantes en una transacción (CLI), la especificación XA.
XA utiliza un modelo de transacciones distribuidas que consta de tres componentes:
Aunque hay tres componentes en el modelo, la especificación XA solo define la interacción entre los administradores de recursos y transacciones.
La especificación XA divide las transacciones en locales y globales. Las transacciones locales son el tipo más simple de transacciones, en las que el programa de aplicación accede solo a un DBMS y determina cuándo confirmar o revertir la transacción. Es decir, en ellos el rol de TM se le asigna a AP. Las transacciones globales (distribuidas) son un caso más complejo, en el que la decisión de realizar cambios o revertir recae sobre los hombros del coordinador, el programa de aplicación determina solo los límites de las transacciones. El administrador de transacciones divide una transacción global en varias sucursales que se ejecutan localmente ( eng. branch ), y luego de una confirmación exitosa en cada una de las sucursales, confirma la transacción global completa y, de lo contrario, retrocede.
Además, la especificación admite transacciones anidadas , que son útiles, por ejemplo, para el registro .
La especificación XA+ , lanzada en 1994, también define transacciones distribuidas entre aplicaciones. En XA +, aparece otro participante en la transacción: el Administrador de recursos de comunicación (CRM), que es responsable de la coordinación entre varios administradores de transacciones distribuidas, en este modelo es responsable de las nuevas ramas de la transacción que, a su vez, contienen varias sucursales más, así como para generar ID de transacciones.
Aunque XA solo especifica una API para el lenguaje C, existen implementaciones en otros lenguajes de programación.
La API de transacciones de Java es una implementación de XA para la plataforma J2EE , lanzada por primera vez en 1999. En .Net Framework , el soporte para transacciones distribuidas apareció solo en la versión 2.0, excepto para XA, la implementación .NET de transacciones distribuidas admite OLE [4] .
La especificación del Grupo de gestión de objetos de 1991 para el Servicio de transacción de objetos introduce la transaccionalidad en CORBA . Debido al hecho de que la especificación no separa a los participantes de la transacción en RM y TM, solo en cliente y servidor, es posible usar XA y OTS en una aplicación cliente-servidor. Además, si uno de los RM no admite XA, pero admite OTS, este paquete es la única solución posible al problema de las transacciones distribuidas en dicho entorno.
La combinación de XA y OTS se usa en Java EE, donde el envoltorio sobre OTS es Java Transaction Service , y Java Transaction API, a su vez, separa el JTS del AP.