Eric's text 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. Web services transactions are 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 depend upon the completion 
of an external event.  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, but on which the Web service 
completion depends.

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.

Web services typically join a transaction by including information in the 
header that registers them into the shared unit of work.  If only two Web 
services are included, they can manage the shard 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.

The result of the transactional unit (i.e. the disposition of the state 
changes) depends upon the results of the participating Web services. 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 also 
typically fails (although there are exceptions) and the state changes undone.

Two major cases need to be addressed:

1.      Where communication sessions or conversations are available
2.      Where communication sessions or conversations are not available

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.

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.

Without sessions, automatic recovery cannot be implemented, and 
compensation mechanisms must be used to resolve failures.

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.

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


-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273

Received on Thursday, 14 November 2002 11:34:48 UTC