Issue - 3 - current state in compensation handlers (resent message)

["Furniss, Peter" <Peter.Furniss@choreology.com>]

I sent this before the discussion yesterday, but the oasis archiver had
a glitch, so it never got archived. So ignore it if you read it last
time.  Peter.

-----Original Message-----
From: Furniss, Peter 
Sent: 04 August 2003 11:29
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Issue - 3 - current state in compensation handlers



The explanation at the end of 13.3.1 gives some motivation for the spec
as it is.

I think this issue may be dependent on Issue 2 - subfunctions.

Having parameters of a compensation handler may well be a good idea, but
using it as the way to inform the handler of the current state of a
global variable seems odd. 

Compensations are notoriously tricky to write in general because the
world may have moved since the completion of the original scope. The
simplification of forcing a snap-shot of the global variables at scope
completion is nice of the simple case, but once things get a bit more
complex, and the compensation is to be designed to handle multiple cases
(order accepted, goods fetched but not dispatched, goods dispatched,
payment accepted but not checked ...) the snapshotting will surely make
things harder to follow. And it's breaking a useful encapsulation -
compensation handlers details should be the concern of the inner scope,
not of the caller. The sophisticated compensation writer will want to
find out the current state for themselves (i.e. would want to
interrogate any global variable), rather than having to declare which
bits of the state it must be told of and requiring the caller of the
compensation to supply the information. Said caller will have the
information, but would have to have detailed knowledge of what the
compensation wanted, rather than just call "compensate" and let the
c-handler sort out what it should do in the current case.

Would it work to make the rule that a compensation handler sees a
snapshot of the scope's own variables as they were when the scope ended
(which would seem natural anyway) but anything declared higher it can
see the reality. Thus in the example shown in 13.3.1, the "getResponse"
variable is declared in the scope itself and the content either copied
from a global variable or - assuming issue 2 - is the value of a
parameter of the original scope.

If we have scope parameters in some way, would the existing
justification in 13.3.1 be sound ?

Peter

------------------------------------------
Peter Furniss
Chief Scientist, Choreology Ltd

   Cohesions 1.0 (TM)
   Business transaction management software for application coordination

web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 870 739 0066  <-- new, from 4 August 2003
mobile: +44 7951 536168

---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org