Executable Semantics for Compensating CSP

Abstract

Abstract. Compensation is an error recovery mechanism for long-running transactions. Compensating CSP is a variant of the CSP process algebra with constructs for orchestration of compensations. We present a simple operational semantics for Compensating CSP and outline an encoding of this semantics in Prolog. This provides a basis for implementation and model checking of the language.

Recovery within long-running transactions

“…The aspects are organised according to the compensation life cycle stage (see Section 2.4.1) under which they fall, with each subsection corresponding to a different life cycle stage. The overview presented in this section extends the observations made in the following works: Chessell et al 2002;Li et al 2007a;Li et al 2007b;Arkin et al 2007;Butler and Ripon 2005;Bocchi et al 2003;Guidi et al 2006;Guidi et al 2008;Lanese and Zavattaro 2009;Laneve and Zavattaro 2005;Mazzara and Govoni 2005;Vaz et al 2009;Lapadula et al 2007b;2008a;Bruni et al 2004;Lanotte et al 2006;2008] 5 .…”

“…The only exception is the scope operator which cannot be implicit. However, compensation installation can be implicitly associated with the start of a transaction scope [Laneve and Zavattaro 2005;Bruni et al 2004;Lanotte et al 2008], the discard operator can be implicitly associated to the termination of a transaction scope Butler and Ripon 2005;Laneve and Zavattaro 2005;Bruni et al 2004] and compensation activation can take place automatically upon the occurrence of a fault Li et al 2007b;Butler and Ripon 2005;Bocchi et al 2003;Lanese and Zavattaro 2009;Laneve and Zavattaro 2005;Vaz et al 2009;Lapadula et al 2008a;Bruni et al 2004;Lanotte et al 2008]. The main options associated with this issue is which of the compensation operators are used explicitly in the syntax or handled implicitly by the semantics.…”

“…Note that none of the formalisms under review allow ACID transactions to be explicitly part of long running transactions. However, a number of flow composition languages Li et al 2007b;Butler and Ripon 2005] assume atomic actions as the building blocks (of long running transactions) which transaction and can also be composed of other processes and activities.…”

“…The argument in favour of having only transactions as compensations Arkin et al 2007;Bocchi et al 2003;Lanese and Zavattaro 2009;Laneve and Zavattaro 2005;Vaz et al 2009;Lapadula et al 2008a;Bruni et al 2004] is that this provides a uniform approach such that the compensation may itself fail and have its own compensations. On the other hand, a number of formalisms Butler and Ripon 2005;Li et al 2007b] choose to allow basic actions to have actions as compensations while transactions have transactions as compensations, thus providing a clear correspondence between actions and their corresponding compensating actions. The problem with this might be that in reality a compensation for an action is not itself an action.…”

Exploring the Connection of Choreography and Orchestration with Exception Handling and Finalization/Compensation

“…In orchestration level, if a long-running transaction fails, appropriate compensations are executed for the completed parts of the transaction, which is supported by WS-BPEL with its scope-based compensation. Butler et al integrated the compensation feature into CSP, and provided both operational semantics and denotational (trace) semantics [9,10]. Bruni et al presented a hierarchy of transactional calculi with increasing expressiveness in [6].…”