Selection Criteria and EMOA framework

WS-Coordination es un marco de trabajo extensible para definir tipos de coordinaciones. La especificación WS-AtomicTransaction provee una definición de un tipo de coordinación que se centra en el concepto de transacción atómica (atomic transaction). Si una actividad adopta este tipo de coordinación, asimila la propiedad de“todo-o-nada” [341]. Es decir, los pro- tocolos de la especificación WS-AtomicTransaction definen las funcionalidades que posibilitan las transacciones a través de servicios web, compatibles con las propiedades ACID encontradas en las mayorías de plataformas de middleware tradicionales como los Monitores TP. ACID es un acrónimo que representan las características esenciales que deben preservar las transacciones “tradicionales” [150]:

Atomicidad(Atomicity): todos los cambios propuestos por la transacción son producidos o ninguno se produce. Esta característica introduce la necesidad de la operación derollback

que es la responsable de dehacer cualquier cambio realizado como parte de una transacción fallida, y restaurar el estado previo inicial.

Consistencia (Consistancy): ninguno de los cambios a los datos hechos como resultado de una transacción pueden violar la validez de cualquier modelo de datos relacionado. Cualquier violación genera un rollback automático en la transacción.

Aislamiento(Isolation): si varias transacciones ocurren en forma concurrente, no se deben interferir entre si. A cada transacción se le debe garantizar un ambiente de ejecución aislado. Perdurabilidad (Durablility): luego de la terminación exitosa de una transacción, los re- sultados hechos por la transacción serán perdurables y no se podrán deshacer, aún si el sistema eventualmente falla.

La transacciónes atómicas al cumplir con las características ACID, significa que las acciones de la transacción, que son llevadas a cabo por distintos participantes, se consideran tentativas antes de realizar elcommit. Es decir que los efectos de tales acciones no son persistentes ni son visibles por fuera de la transacción; sólo lo serán cuando se logre elcommit. Cuando una aplica- ción termina el trabajo de una transacción, requiere que el Coordinador determine el resultado final de la transacción. El Coordinador determina si existieron fallas en la transacción solicitan- do a los participantes confirmaciones. Si todos los participantes confirman el éxito de la parte de la transacción que les tocaba, entonces el Coordinador confirma la persistencia de las accio- nes (commit) realizadas por los participantes. Si alguno de los participantes solicita abortar la transacción o no responde, el Coordinador solicita abortar (abort) todas las acciones (tentativas) llevadas a cabo por el resto de los participantes. Solicitar elcommitde una transacción, involucra que las acciones tentativas de los participantes sean finales, de forma tal que sus efectos sean

persistentes y visibles. Por otro lado, la primitivaabort, obliga a los participantes que todas sus acciones tentativas fuesen desechadas, y consideren como si nunca ocurrieron.

Las transacciones atómicas comúnmente requieren un alto grado de confianza entre los par- ticipantes de la actividad, y son generalmente de corta duración. WS-AtomicTransaction defi- ne protocolos que permite crear “envolturas” para los protocolos utilizados en los sistemas de procesamiento de transacciones preexistentes en una organización, y posibilita también poder interoperar a través de diferentes plataformas de software y hardware [341].

Las transacciones atómicas han probado ser extremadamente útiles para varias aplicaciones. Estas proveen consistencia ante fallas y semántica de recuperación para las mismas; de forma tal que las aplicaciones no necesitan lidiar más con los mecanismos para determinar la completitud de una serie de acciones o para eliminar los efectos colaterales de acciones no consistentes.

La especificación define protocolos que gobiernan el resultado final de transacciones atómicas. WS-AtomicTransaction tiene como objetivo, también, es un medio para desarrollar envolturas a mecanismos propietarios de transacciones y para interoperar a través de implementaciones de gestores de transacciones de diferentes empresas de software.

Contexto de WS-AtomicTransaction

WS-AtomicTransaction se construye sobre WS-Coordination, aprovechando sus Servicios de Activación y de Registro. En si, las coordinación de transacciones atómicas son un tipo de protocolo específico de coordinación y, como tal, manejan un determinado tipo de contexto; es decir, tiene un tipo especial de elemento CoordinationContext.

La especificación WS-AtomicTransaction agrega la siguiente semántica específica a la opera- ciónCreateCoordinationContextatendida por el endpointActivationCoordinatorPortType

del Servicio de Activación del Coordinador (véase Fíg. 6.6):

si el participante que solicita la activación incluye el elementoCurrentContext, el Coordi- nador receptor del mensaje es interpuesto como subordinado al Coordinador estipulado en el elemento CurrentContext. Es decir, el Coordinador receptor funcionará como interme- diario oproxy hacia el Coordinador del contexto existente; de esta forma, se asegura que sólo un Servicio de Coordinación gestiona la transacción;

si la solicitud de activación no incluye el elementoCurrentContext, el Coordinador receptor del mensaje crea una nueva transacción, y se establece como gestor de la misma.

El contexto de coordinación puede contener el elementoExpires. Este elemento especifica el período de tiempo, medido desde el momento en el cual el contexto de coordinación fue creado (o recibido), después del cual una transacción puede ser terminada debido únicamente a su lapso de operación. Después de cumplido este período, el Coordinador puede elegir realizar unrollback

u omitir la remisión decommit.

El tipo de protocolo Transacción Atómica está definido mediante el tipo de coordinación indicado por http://docs.oasis-open.org/ws-tx/wsat/2006/06.

Protocolos de WS-AtomicTransaction

En si, WS-AtomicTransaction define un tipo de protocolo para WS-Coordination; y como se explicó en la Sec. 6.2.1, todo tipo de protocolo está compuesto por un conjunto de protocolos de coordinación. Un participante puede registrarse para uno o más de estos protocolos. En este caso, los protocolos de Transacción Atómica son:

Completion: el protocolocompletion inicia el proceso de commit, en base al protocolo elegido por los participantes. El Coordinador que gestiona el protocolocompletioncomienza el proceso commit (o abort) con los participantes registrados para el protocolo Volatile 2PC y sigue con aquellos registrados paraDurable 2PC. El resultado final es informado al participante o servicio web inicializador de la transacción.

Two-Phase Commit(2PC): El protocolo2PC coordina a los participantes registrados a alcanzar una decisióncommit oabort, y asegura que todos los participantes sean informados del resultado de la decisión. En el contexto de WS-AtomicTransaction, el protocolo 2PC tiene dos variantes:

• Volatile 2PC: en este caso, los participantes manejas recursos “volátiles” como por ejemplo registros de cache o similares.

• Durable 2PC: en este caso, por el contrario, los participantes involucran recurso “durables” como registros de bases de datos.

Protocolo Completion Este protocolo es usado por un servicio web participante para infor- mar al Coordinador que se desea acometer o abortar una transacción atómica. Luego que una transacción fue concluida, el resultado es retornado a la aplicación.

Si uno de los participantes de una transacción inicia este protocolo, debe registrarse usando el identificador de protocolohttp://docs.oasis-open.org/ws-tx/wsat/2006/06/Completion. Este identificador debe ser expresado en el elementoProtocolIdentifierdel mensajeRegister

enviado al endpointRegistrationCoordinationPortType del Coordinador (véase Fig. 6.7). WS-AtomicTrasaction especifica que el Coordinador de una instancia del protocoloComple- tion debe ser el coordinador principal de la transacción atómica correspondiente; la tarea no puede ser llevada a cabo por ningún Coordinadorproxy o subordinado.

En la ejecución del protocolo Completion, el Servicio Coordinador y el servicio iniciador del protocolo intercambian mensajes (véase Fig. 6.9). Por un lado, el Coordinador acepta los mensajes:

Commit: al recibir este mensaje desde un participante, iniciador del protocoloCompletion, el Coordinador reconoce que el iniciador ha completado el procesamiento en su aplicación; por consiguiente, el Coordinador debe iniciar el commit de la transacción.

Rollback: al recibir este mensaje, el Coordinador reconoce que el iniciador ha terminado el proceso y debe abortar la transacción.

Como se explicará luego, el Coordinador, al recibir el mensajeCommit oRollback, inicia las fases del protocolo 2PC, interactuando primero con los participantes registrados para el protocolo

Volatile 2PC y luego con los registrados paraDurable 2PC.

Por su parte, el iniciador acepta los siguientes mensajes, en base al resultado del protocolo

2PC:

Committed: al recibir este mensaje el iniciador de la instancia del protocolo, reconoce que el Coordinador ha logrado el commit.

Aborted: al recibir este mensaje el iniciador de la instancia del protocolo, reconoce que el Coordinador ha abortado la transacción.

WS-AtomicTransaction especifica que todo Servicio de Coordinacion que soporta un Servicio de Activación debe soportar el protocoloCompletion.

Protocolo Two-Phase Commit (2PC) El protocoloTwo-Phase Commit (2PC) es un pro- tocolo de coordinación que define la forma en la cual múltiples participantes alcanzan un acuerdo para lograr el resultado global de una transacción atómica. Como se explicó, el protocolo tiene dos variantes:Volatile 2PC yDurable 2PC.

El protocolo 2PC lo comienza el Coordinador al recibir la peticiónCommitoRollbackdel ser- vicio web iniciador del protocoloCompletion. El Coordinador principal comienza la faseprepare

para todos los participantes registrados para el protocoloVolatile 2PC. Todos los participantes de

Figura 6.9:Intercambio de mensajes y estados del protocoloCompletion.

Figura 6.10:Intercambio de mensajes y estados del protocolo2PC.

el resto de los participantes (de Durable 2PC). Cuando los participantes (volátiles y durables) hayan recibido el mensaje, pueden contestar con un mensaje Prepared, ReadOnly o Aborted

hacia el Coordinador.

Si todos los participantes han enviado el mensajePrepared, el Coordinador envía el mensaje

Committed al participante del protocolo Completion y el mensaje Commit a cada uno de los participantes de Volatile 2PC y de Durable 2PC. En la Fig 6.10 se detalla el diagrama del protocolo 2PC y de las interacciones.

Mientras que el protocolo tradicional 2PC, bastante conocido y entendido, no ha cambiado durante décadas; sí lo han hecho los ambientes para el procesamiento de actividades transacciones. En la actualidad es muy común que la infraestructura informática de una organización cuente con sistemas que son de múltiples capas o servicios. Por ejemplo, en aplicaciones web típicas, los servidores que instauran el front-end o nivel de presentación están separados de los servidores que implementan la capa intermedia de lógica de aplicación. A su vez, los servidores middleware

cachean en forma adecuada el estado de las aplicaciones que soportan y acceden a los servidores

back-end o de gestión de bases de datos, que soportan el nivel de gestión de recursos en el cual realmente se mantiene el verdadero estado de datos manejado por las aplicaciones. Para que un protocolo de transacciones soporte estas configuraciones de sistemas distribuidos, se requieren que los protocolos de coordinación cuenten con características adicionales.

Por ejemplo, para permitir “fijar” el estado actualizado de sus caches en lo servidores de base de datos en forma permanente, los servidores de capas intermedias, que soportan la lógica de aplicación, deben se notificados antes de que el protocolo 2PC comience. En la especificación WS-AtomicTrasaction esto se logra mediante el protocoloVolatile 2PC.

Una segunda extensión propuesta por WS-AtomicTransaction a la versión tradicional 2PC surge de la necesidad de iniciar el protocolo por fuera de los Coordinadores originales. Hecho muy común cuando varios participantes, que no comparten el mismo Coordinador y la misma base de datos, deban saber el momento en el cual el protocolo 2PC comienza. Por tal razón, se propuso el protocolo Completion.

Figura 6.11:La integridad de la actividad de negocios se preserva con operaciones decompensación.