long running transactions text

Long running transactions

 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

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.