Aborting Atomic Scopes
Original Publication Date: 2005-May-09
Included in the Prior Art Database: 2005-May-09
It is suggested to introduce a rollback activity. When carried out, the atomic scope is rolled back. After completion of the rollback, several actions are conceivable how processing continues. One option would be to restart processing the atomic scope: another option to terminate the process. One would express those options, staying in the spirit of the BPEL specifications, via an appropriate attribute associated with the rollback.
Aborting Atomic Scopes Aborting Atomic ScopesAborting Atomic Scopes Aborting Atomic Scopes
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, control is given to the attached fault handler . The activities being carried out within the fault handler are part of the transaction established by the atomic scope. If the fault handler can not complete for some reason, the atomic scope including the activities carried out by the fault handler must be undone . Unfortunately, there is no way of achieving this without terminating the process . The notion of an abort activity is suggested that provides the controlled abort of an atomic scope within a fault handler attached to the atomic scope .
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. IBM and BEA have proposed BPELJ as an extension to BPEL . BPELJ features the support of the Java 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.
Fault handlers implement the logic for handling faults that occur within a scope. When such an error occurs, appropriate fault handlers associated with the scope are invoked. The fault handler associated with an atomic scope is part of the atomic scope; if a fault is being thrown within an atomic scope, the processing carried out by the fault handler is still under the transaction that has been started for the atomic scope.
The fragment of a process helps illustrate the current processing of fault handlers associated with an atomic scope. It is a part of a larger order process; the shown activities are carried out one after the other as indicated via the sequence activity which starts in line 10 and ends in line 13. The scope is defined with the attribute acid=true which indicates that the invoke activity in line 11 which receives a request from a customer and the invoke activity in line 12 which updates a database are to be carried out as an ACID transaction. The scope has a fault handler associated with it. When the invoke activity in line 12 does not find the item that has been requested, a RecordNotFound fault is generated .
1 <scope name="processProposal" acid="true">
3 <catch faultName="RecordNotFound">