Results on Test Problems

Las denominadasactividades de negocios(business activities)son aquellas coordinaciones complejas entre servicios web, de largo tiempo de duración. Pueden pasar horas, días, y hasta incluso semanas antes que una actividad de negocio pueda completarse. Durante este período, la actividad puede realizar diferentes tareas que involucran a varios servicios web participantes [150, 496].

Lo que distingue a las actividades de negocios de cualquier otra actividad no-transaccional es el hecho de que sus participantes siguen reglas especificas definidas en protocolos. La principal diferencia entre los protocolos de actividades de negocios y los protocolos basados en transacciones atómicas está en la forma en que tratan las excepciones y en la naturaleza de las restricciones introducidas por las reglas de protocolos. Por ejemplo, los protocolos de Actividades de Negocios no tiene la capacidad de rollback; debido a la naturaleza de larga duración de las actividades de negocios, no resulta adecuado el enfoque sugerido por las transacciones de tipo ACID. En su lugar, las actividades de negocios proveen un proceso opcional decompensación que, puede entenderse como un “Plan B”, el cual puede invocarse cuando condiciones de excepción son generadas, buscando anular ocompensar los efectos del “Plan A” (véase Fig. 6.11).

Es importante destacar que el uso de actividades de negocios no excluye la utilización de transacciones atómicas. De hecho, puede darse que una actividad de negocios de larga duración, contenga varias transacciones atómicas durante su ciclo de vida.

Las actividades de negocios tiene las siguientes características [342]:

Una actividad de negocios puede consumir varios recursos en un intervalo largo de tiempo. Pueden contener un número significativo de transacciones atómicas involucradas.

Las tareas individuales dentro de una actividad de negocios pueden ser visibles previo a la finalización de la actividad de negocios; el resultado de dicha tarea puede impactar por fuera de los participantes de la actividad.

El hecho de contestar a una solicitud puede tomar un tiempo prolongado. Esta situaciones se dan, por ejemplo cuando se requiere la aprobación de una persona responsable, cuando se debe completar la manufactura o la entrega de bienes; todas estas actividades deben ser completadas antes de que se logre remitir un mensaje de respuesta a la primera petición. En el caso que se produzca una excepción y se requiera que una actividad sea lógicamente deshecha, no es suficiente abortar la tarea o tareas que han generado la excepción. Los mecanismos de manejo de excepción pueden requerir cierta lógica de negocios. En el ejemplo explicado en la Sec. 6.1 y representado por la Fig. 6.11, cada servicio de reserva, ante la excepción de cancelación del itinerario, compensa los efectos de una reserva.

Los participantes en una actividad de negocios pueden ser de diferentes dominios de con- fianza, para lo cual se necesita que todas las relaciones sean establecidas explícitamente.

La especificación WS-BussinesActivity provee la definición para dos tipos de coordina- ciones relacionadas con actividades de negocios, que aplican lógica de negocios para manejar excepciones que ocurren durante la ejecución de actividades de un proceso de negocio. Las ac- ciones en una actividad de negocios son aplicadas inmediatamente y son permanentes. Acciones de compensación pueden ser invocadas en eventos de error. WS-BusinessActivity define proto- colos que permiten a los proceso de negocios existentes y a los sistemas de flujo “enmascarar” sus mecanismos propietarios e interoperar a través de los límites de confianza y de diferentes implementaciones [342].

Los protocolos de actividades de negocios definidos en la especificación WS-BusinessActivity se han centrado en los siguientes puntos de diseño:

Todas las transiciones de estados son fielmente registradas, incluyendo el estado relacionado a la aplicación distribuida y a los metadatos del coordinador.

Todas la notificaciones no-terminales son reconocidas por el protocolo para asegurarse una vista consistente de estado entre coordinador y participantes. Un coordinador o participante puede solicitar el estado de un participante o reenviar notificaciones para obtenerlo. Cada notificación está definida como un mensaje individual. El nivel de transporte petició- n/respuesta con sus mecanismos de reintento y tiempo agotado (timeout) no son suficientes para lograr el acuerdo de coordinación a nivel de aplicación (end-to-end) para actividades de larga latencia.

Contexto de WS-BussinesActivity

Al igual que WS-AtomicTransaction, la coordinación especificada por WS-BusinessActivity define un tipo de contexto de coordinación a través de un elemento CoordinationContext de WS-Coordination. Los mensajes de aplicación relacionados a la actividad de negocios deben propagarse usando este contexto de coordinación, insertado dentro de los encabezados SOAP.

El espacio de nombres XML que se debe usar para implementar interacciones basadas en WS-BusinessActivity es http://docs.oasis-open.org/ws-tx/wsba/2006/06

Protocolos de WS-BussinesActivity

Cuando algunos de los protocolos de WS-BussinessActivity es usado, el controlador de WS- Coordination asume el rol específico de Coordinador de la actividad de negocios. De igual forma que en las transacciones atómicas, el Coordinador tiene distintos tipos de control sobre la acti- vidad, basándose en el protocolo específico usado por los participantes.

Las actividades de negocios soportan dos tipos de coordinaciones y dos tipos de protocolo. Cada uno de los tipos de coordinación pueden ser usado con cualquiera de los tipos de protocolos [342].

En el elemento CoordinationContext de una actividad de negocios se debe especificar si el tipo de coordinación es:

AtomicOutcome(http://docs.oasis-open.org/ws-tx/wsba/2006/06/AtomicOutcome), o

MixedOutcome (http://docs.oasis-open.org/ws-tx/wsba/2006/06/MixedOutcome). Un Servicio de Coordinación para un tipo de coordinación AtomicOutcome debe dirigir a todos los participantes hacia el cierre o compensación de una actividad de negocios. En tanto, cuando un Servicio de Coordinación implementa el tipo de protocoloMixedOutcome, el Coordi- nador dirige a todos los participantes hacia el resultado, pero puede delegar a cada participante la posibilidad de cerrar o compensar la actividad.

BusinessAgreementWithParticipantCompletion: un participante se registra para este protocolo ante su Coordinador, de forma tal que este último pueda gerenciar al primero. Este protocolo permite a cada participante determinar si se ha completado su parte de la actividad de negocio.

BusinessAgreementWithCoordinatorCompletion: al igual que el anterior, un participante se registra para este protocolo ante su Servicio Coordinador; con la salvedad que el parti- cipante delega en su Coordinador la responsabilidad de decidir cuándo se han completado el trabajo exigido para la actividad de negocios.

Los participantes interactúa con el Servicio de Coordinación definido por WS-Coordination para registrarse en los protocolos determinados, de la misma forma en que se explicó en la Sec. 6.3.2.

Protocolo BusinessAgreementWithParticipantCompletion Durante el ciclo de vida de una actividad de negocios, el Coordinador y los servicios web participantes transitan por una serie de estados. El punto real de una transición (de un estado a otro) ocurre cuando un mensaje especial de notificación es propagado entre los servicios [150].

Por ejemplo, un participante puede indicar que ha completado un determinado procesamiento que le fue encomendado como parte de la actividad mediante la generación de una notificación de completitud. Esto cambia a los participantes de un estado“activo” a un estado“completado”. El Coordinador puede responder con un mensaje “cierre” para indicarle al participante que la actividad ha sido exitosamente completada.

Sin embargo, si la actividad de negocio no siguió el curso deseado, porque una de sus ope- raciones o tareas fracasó o no se logró llevar a cabo, los participantes entran en el estado de

“compensación” durante el cual pueden tomar alguna medida para manejar la excepción. Para esto generalmente se invoca a un proceso separado de compensación que puede involucrar una serie de pasos adicionales. Una compensación difiere de una transacción atómica en el sentido de no pretender que los cambios realizados por los servicios participantes se vuelvan atrás (ro- llback) como que si nunca se produjeron; el propósito de una compensación es ejecutar un plan alternativo o contingente cuándo un plan original falló.

Alternativamente, se puede entrar a un estado de “cancelación”. Este genera la terminación de cualquier proceso futuro por fuera de las notificaciones de cancelación.

Existe otra distinción entre actividades de negocios y transacciones atómicas, es el hecho de que no se requiere que los servicios permanezcan ligados como participantes durante la eje- cución de toda la actividad de negocios. Debido a que no existe un control estricto sobre los cambios realizados por los servicios participantes, estos pueden dejar la actividad de negocios inmediatamente después de haber realizado su contribución a la actividad. Cuando esto ocurre, los participantes entran en un estado de “salida” enviando un mensaje de notificación “exit” al Coordinador.

Estos y otros estados son definidos en la especificación WS-BusinessActivity en una serie de tablas. Estas tablas documentan las reglas fundamentales de los protocolos de las actividades de negocios para determinar las secuencias y condiciones permitidas de estados.

El diagrama de estado presentado en la Fig. 6.12 ilustra, en forma abstracta, el comporta- miento del protocolo en las interacciones entre Coordinador y participantes. La figura demues- tra los distintos estados por los cuales pueden pasar los participantes y el Coordinador de la actividad. Los participantes que se registran en el protocolo deben especificar el identificador

http://docs.oasis-open.org/ws-tx/wsba/2006/06/ParticipantCompletion en el elemento

ProtocolIdentifieren el momento de Registro [343].

El Servicio Coordinador puede aceptar los siguientes mensajes:

Completed: al recibir este mensaje, el Coordinador conoce que el participante ha comple- tado todos los procesamientos relacionados con la instancia del protocolo. Como siguiente

Figura 6.12:Intercambio de mensajes y estados del protocoloBusinessAgreementWithParticipantCompletion.

paso, el Coordinador debe enviar el mensajeCloseoCompensatepara indicar el resultado final de la instancia del protocolo. Luego de enviar la notificaciónCompleted, el participante no puede participar en ninguna otra tarea de la misma actividad.

Fail: al contrario del anterior, al recibir este mensaje el Coordinador conoce que el parti- cipante ha fallado; quedando indeterminado el estado del mismo. Como paso siguiente, el Coordinador debe generar la notificación Failed.

Compensated: este mensaje, al ser generado por el participante, indica que éste se ha “olvidado” de la actividad de negocios realizada, anulado sus efectos con una compensa- ción. Al recibir este mensaje, el Coordinador reconoce que el participante ha realizado exitosamente el procedimiento compensatorio.

Closed: al igual que el anterior, el mensaje se genera por el participante, indicándole al Coordinador que se ha finalizado el proceso de coordinación exitosamente.

Canceled: el participante genera esta notificación en respuesta a la solicitud de cancelación del Coordinador. De esta forma, se le indica al Coordinador que se ha cancelado todo lo relacionado con la instancia del protocolo.

Exit: luego de la recepción de esta notificación, el Coordinador reconoce que el participante que la generó no participará más de la actividad; por consiguiente, toda tarea pendiente del participante fue descartada y todo trabajo realizado por éste fue debidamente cancelado.

CannotComplete: luego de recibir esta notificación, el Coordinador conoce que el parti- cipante ha determinado que no puede terminar exitosamente todo el procesamiento relacio- nado con la instancia del protocolo. Todo trabajo pendiente a realizar por el participante fue descartado y todo trabajo realizado por el participante, cancelado. Luego del envío de este mensaje, un participante no puede intervenir en cualquier actividad relacionada con la actividad.

Por su parte, el participante puede recibir los siguientes mensajes:

Close: luego de recibir esta notificación, el participante reconoce que la instancia de un protocolo está lista para ser finalizada exitosamente. Como siguiente paso, el participante debe enviar el mensajeClosed para finalizar definitivamente la interacción.

Cancel: cuando se recibe este mensaje, un participante reconoce que el trabajo a realizarse ha sido cancelado. Como siguiente paso en el protocolo, el participante debe remitir el

Figura 6.13:Intercambio de mensajes y estados del protocoloBusinessAgreementWithCoordinationCompletion.

mensaje Canceled o Fail, para indicar si le fue posible cancelar la operación o falló en el intento.

Compensate: en este caso, el participante reconoce que el trabajo a realizarse debe com- pensarse. Como siguiente paso en el protocolo, el participante debe responder con el mensaje

Compensated oFail, indicando el éxito o no de la operación de compensación.

Failed: al recibir esta notificación el participante conoce que el Coordinador es consciente de una falla en la actividad y, por ende, no se requiere más acciones por parte del par- ticipante. A partir de este momento, el participante entre en estado Finalizado y debe “olvidar” el contexto de la actividad.

Exited: esta notificación significa que el Coordinador ha desvinculado al participante de la actividad y, por ende, no se requiere más la participación en la actividad.

NotCompleted: esta notificación significa que el Coordinador ha reconocido que el par- ticipante no puede completar el procesamiento de las tareas solicitadas para la actividad y, por ende, no se requiere más la participación en la actividad.

También existen una serie de mensajes que conforman el protocolo

BusinessAgreementWithParticipantCompletion que pueden ser aceptados por el Coordina- dor y los participantes, indistintamente. Por un lado el mensaje GetStatus requiere el estado actual del Servicio de Coordinación o de un participante. En respuesta, se genera el mensaje

Status en el cual se indica el estado actual del servicio web que interviene en la actividad de negocios (Coordinador o participante).

ProtocoloBusinessAgreementWithCoordinatorCompletion Este protocolo es similar al protocolo anterior, con la salvedad que los participantes confían que el Coordinador les informe cuándo recibe todas las peticiones para realizar el trabajo de las actividades de negocios [343].

Los participantes que desean registrarse utilizando el identificador de protocolo

http://docs.oasis-open.org/ws-tx/wsba/2006/06/CoordinatorCompletion. Los posibles es- tados y mensajes partes del protocolo son descriptos en la Fig. 6.13.