[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - 3 - current state in compensation handlers (resent message)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]