RE: Compensation

Dear Steve and others,

I am working on a contribution which I hope to get out soon that (if I
do complete and get approved for submission) will show how a 'proper'
transactions capability could be incorporated into our CDL

Whilst I think that generally the Oracle submission forms a good working
basis for a draft of our language specification, I have expressed
reservations about its inclusion of compensation capability alone.

My reasoning, briefly put, is as follows:

Compensation is used in two different senses, but often without
distinction.

The first sense is a means of achieving the confirmation / cancellation
behaviour of a transaction. (I understand that this is actually in the
intent in the BPEL4WS language, though that specification does nor
currently make that entirely obvious.)  As such it is a valid technique,
but it is only one of three (some would argue actually a whole spectrum
of techniques).  When using the compensation technique incoming actions
are performed and an undo (or compensation) journal taken.  If the
transaction confirms then the compensation journal is 'burned' and the
results stand.  If the transaction confirms then the compensation
journal is run in an attempt to undo the actions and return the state to
that at the start of the transaction (or some such as agreed to be
acceptable in the background agreement between the parties.  The other
common techniques are validate - do which is kind of the reverse.
Incoming actions are checked and put in a 'to do' journal.  If the
transaction cancels the main line data is not changed, and the 'to do'
log is 'burned.  If the transaction confirms that the 'to do' log is
run.  The final one of the three I call the before and after image
method (which I do not claim to have invented but picked up somewhere
along the line). As incoming actions affect data fields the original
values are recorded (to form the before image) and the changed values
are recorded (the after image).  If the transaction cancels then the
before image is made 'live' and if it confirms then the after image is
made 'live'.

As Steve points out below people also use the term compensation to
describe a technique for process designers to use to attempt to undo the
effects of a transaction that has already completed.  This will work
sometimes but it seems to me to have some obvious problems.  The
compensation can only restore the information affected by the
transaction to its state at the beginning of the transaction - this may
or may not be a good move depending on what else has occurred.  That is
the point - compensation takes a limited view and does not account for
other changes over time.  It seems to me that it is much better to have
a process that is doing a series of transactions to use business logic
(business rules) to and its knowledge of its entire environment to
decide which transaction to do next (if any) at any particular point in
reaction to any particular set of results. 

I hope to be on the next teleconference to explain further if required.

Best Regards     Tony
A M Fletcher
 
Cohesions  (TM)
 
Business transaction management software for application coordination
www.choreology.com
 
Choreology Ltd., 68 Lombard Street, London EC3V 9LJ     UK
Tel: +44 (0) 870 7390076   Fax: +44 (0) 870 7390077  Mobile: +44 (0)
7801 948219
tony.fletcher@choreology.com     (Home: amfletcher@iee.org)


-----Original Message-----
From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org] On Behalf Of Steve Ross-Talbot
Sent: 11 November 2003 21:33
To: public-ws-chor@w3.org
Subject: Compensation



Tony,

Compensation: A transaction may declare a set of compensating 
Activities that are to be executed when a successfully completed 
transaction needs to be undone. Compensation describes only the 
externally observable Activities required to undo the transaction; it 
does not describe how the transaction is undone by the implementation. 
It also may specify a strategy for a failed invoked web service.

Tony F, if you were using your words how would you describe this? Why 
would it be different (if indeed it is).

Cheers

Steve T

This email is confidential and may be protected by legal privilege. If
you are not the intended recipient,  please do not copy or disclose its
content but  delete the email and contact the sender immediately. Whilst
we run antivirus software on all internet emails we are not liable for
any loss or damage. The recipient is advised to run their own antivirus
software.

Received on Wednesday, 19 November 2003 16:18:41 UTC