Some comments on definition of operation/group and action

[Sazi Temel <sazi.temel@bea.com>]

Included some of my comments for the BTP submissions. 

From the requirements #1, #2 and #3, one may derive the definitions of key terms. An action(A), also called Business Transaction is a collection of group of operations where a group has a single reverse operation(<-R) that can back out the effect of all the operations(o) executed in the group(G). The group operations has the atomic effect; group of operations always complete, either success or failure -failure requires back out, no forward recovery. 

It looks like the group is the unit of work that takes a business (trans)action from one stable state to the other, on success or business (trans)action stays in the previous (or initial) stable state, on failure. It only concerns with backward recovery, there is no forward recovery in the group -like an ACID transaction. Although, it is implicit that the operations in the group might be ACID transactions and/or other business calculations, it is not clear whether 
(1) the operations share data and the structure of the group is visible to operations in and out of group, 
(2) the operations are long-running or short duration, 
(3) the reversibility with one operation the criteria for grouping or there are other criterias

Action including a reverse operation and group of operations where operations may also be ACID transactions(t) and/or other business computations creates a two level nested structure shown in example below:


A {G1[(o1,t1,o2)<-R1], G2[(t1,t2,o1,o2)<-R2], G3[(t1)<-R3]}

In which, in case there are multiple ACID transactions in the group the structure of group will be exposed(at least partially) to the other transactions (once they are committed) unless the group represents a nested transaction or a similar transaction model where the transactions in the group are siblings in the transaction tree and locks are hold by the parent. Thus exposing the structure of the group, on one hand, may create a situation where backward recovery might not be possible (as suggested per group definition) and on the other hand, introducing forward recovery into the group makes it more like (trans)action which might allowed forward recovery thru compensation and contingency (as I understood from the submission). 

What are the differences between action and group and, group and operation? When the definition of the terms are not clear creating group of operation or action become users and developers choice. From the examples given, I can design a business transaction as a single group of operations in an action; A {G1(o1,o2,t1)}<-R1} or I can design it as 2 or 3 groups of operations in an action; A {G1[(o1)<-R1], G2[(o2)<-R2], G3[(t1)<-R3}. Both solutions (and possible more others) are valid, but which one is less error prone?  We need clear criteries for qualifying what an operation is, what a group is and what an action is. Need to come with a more precise definitions that will exclude many of the random combinations of composing actions and group of operations. Designing a better business transaction is very vital since a bad transaction design will definitely yield cascading backward recovery, this is so with ACID transactions too (a bad transaction design may yield rollback, but no consistency problems occur normally) but it is more critical with business transactions since we have to deal with restoring the consistency thru compensations and perhaps compensations of compensations etc., it is more problematic. 

One may define an operation as any kind of business computation with the following characteristics:
1) It is registered with group, i.e the group is aware of it. Note that a group may have many other operations but not visible to the group.
2) Its results (only success or failure - like a vote, yes or no) will be accessible so that a group decision can be made.
3) It has a reverse operation, i.e a compensation that it registered with group so that in case of backward recovery it may be applied. (The compensation/reverse-op may be no-op.)

One may also try to eliminate some of the inconsistencies that might be created during group operations. This may require semantic analysis of the group operations. For example we may define the operations so that 
1) they will not perform operations that may create inconsistencies
2) only allow reversible operations

Also, a single operation to reverse the group of operations (as suggested in the Choreology submission) may be complicated especially if there are several operations in the group since the reverse operations should have enough information on the failure case to execute a correct version of the recovery. Each operation having its own compensation might be an alternative (and a master compensation that will execute the others).

Regards,
--Sazi