Running Atomic Scopes as Stratified Transaction for Scope Retry
Original Publication Date: 2005-Feb-08
Included in the Prior Art Database: 2005-Feb-08
Languages for describing business processes such as Business Process Execution Language for Web Services (BPEL4WS) provide for the definition of scopes as a means for assigning a property to the set of enclosed activities. Atomic scopes, as defined in BPEL4J, an extension proposed to BPEL, have the property that the enclosed activities are carried out an ACID transaction. If one of the enclosed activities fails, the effects of all enclosed activities are undone and the atomic scope is restarted. If the atomic scope fails a pre-defined number of times, the business process is stopped and the process administrator needs to take appropriate corrective actions. This can be extremely hard, if not impossible, if the atomic scope consists of a large number of activities as the actual point of failure is not known. A method is suggested that provides for controlling the execution of the individual activities so that the failing activity can be identified.
Running Atomic Scopes as Stratified Transaction for Scope Retry Running Atomic Scopes as Stratified Transaction for Scope RetryRunning Atomic Scopes as Stratified Transaction for Scope Retry Running Atomic Scopes as Stratified Transaction for Scope Retry
Business Process Execution Language for Web Services (BPEL4WS) is an emerging standard for defining business processes using Web Services . A fundamental construct is the notion of scopes as means for defining a property that the enclosed activities share, for example a variable that is shared between the different activities. IBM1 and BEA2 have proposed BPELJ as an extension to BPEL. BPELJ features the support of the Java3 programming language. As part of these extensions, atomic scopes have been proposed (the BPELJ folks call them Acid scopes). Atomic scopes are scopes where the enclosed activities are carried out as an ACID transaction.
If an atomic scope fails, the transaction is rolled back; that means the effects of all enclosed activities are undone. After the rollback has been carried out, the atomic scope is restarted. If the retry of the atomic scope fails a specified number of times, a fault is thrown.
BPELJ does not specify any special actions that one can take if such a fault is thrown. Additional out-of-BPELJ-scope actions have typically been implemented by workflow management system to allow for the analysis and repair of the situation . One of the biggest problems in handling the situation is to find the activity that had failed, as all traces of the execution of the transaction ha...