long run txns (reformat again)

Long running transactions

The fundamental characteristic of a transaction is the ability to join multiple actions into the same unit of work, such that the actions either succeed or fail as a unit. A transaction is an infrastructure element that can support the coordination of results or operations on state in a multi-step interaction.

A Web services transaction is generally defined as the ability to join two or more Web services into a transactional unit of work.  The transactional unit of work is responsible for ensuring that any state changes performed by participating Web services are either made permanent or undone. 

A long running transaction is defined as a special case of a transaction, in which one or more of the joined Web services either depend upon the completion of an external event, or upon the completion of a lengthy interaction.  A "normal" transaction can run to completion without external dependencies; a long running transaction may depend upon the completion of an asynchronous event, human intervention, or other time-based activity that must first run to completion on a schedule unrelated to the Web service execution.  A motivating factor for this type of transaction might be the multiple calls, long lead times, and cumbersome manual processes typically involved in interacting with numerous parties across the Web.

Long running transactions are implemented using a shared context that tracks the state of the execution.  The context remains active until all web services within the transactional unit run to completion.  Completion can be successful or unsuccessful, and the result of the overall transactional unit is determined by the success or failure of the individual web services. 

The overall result of the transactional unit (i.e. the ultimate disposition of the related state changes) depends upon the results of the participating Web services, interpreted according to a set of predetermined rules.  For example, if all participating Web services complete successfully, the transactional unit completes successfully and the state changes are made permanent. If one or more of the participating Web services fails, the transactional unit may also fail and the state changes are undone. Other rules may allow the state changes to be made permanent of undone for a subset of participants. 

The state changes can be undone using logging associated with persistent stores or by using compensation actions.  Logging mechanisms typically either implement undo or redo algorithms for replacing unmodified data, restoring the state to what it was before the execution of the transaction.  Compensation actions typically execute programs that back out the changes by restoring the original values.

Web services can join a transaction by including information that registers them into the same, shared unit of work.  If only two Web services are included, they can manage the shared context themselves.  If more than two Web services register, an independent coordinator may be needed to track the context and maintain a list of registered Web services (and propagate context).

Two major cases of context management need to be addressed: 

1.	Where communication sessions (or conversations) are available to maintain shared state
2.	Where communication sessions (or conversations) are not available to maintain shared state

In the first case, context can be shared using the session or conversation, and multiple Web services can be joined using the shared session of conversation.  Automatic recovery may be possible for some actions because it can be triggered on a failure condition for the session (or conversation).

In the second case, context must be maintained in a central place, and information about the completion of the participants must be coordinated. The coordinator responsible for maintaining the context is at the same place where the web service is offered, and to which requests are sent for executing the initial Web service. 

A context needs a unique identifier to identify it on the network, and could be a Web resource for example.

A coordinator can be used to track participating web services that register to join a transaction, and coordinators themselves can become participants that represent other web services.  

Candidate technologies in this area include BTP, WS-Transactions, WS-Coord, and the OMG Activity Spec. 

Issues:

Improve definition of long-running transaction
Link the concepts to specific architecture elements, such as SOAP and WSDL
Incorporate the section better into the overall context of transactionality

Received on Thursday, 14 November 2002 15:55:32 UTC