W3C home > Mailing lists > Public > public-ws-chor@w3.org > November 2004

Re: Coordinated Choreographies Proposal 4 - Finalize Activity

From: Gary Brown <gary@enigmatec.net>
Date: Wed, 3 Nov 2004 12:02:49 -0000
Message-ID: <009501c4c19d$0dde8690$4b00a8c0@LATTITUDEGary>
To: "Haugen Robert" <Robert.Haugen@choreology.com>, <public-ws-chor@w3.org>

General comments, based on my current understanding which may be wrong - so 
please correct me if I have misunderstood the approach:

1) In the current CDL spec, the finalizer is automatically invoked when an 
exception occurs within the parent choreography. Minor note: I don't believe 
that the order in which the exception handler and finalizer are invoked is 
defined, but this apparently will be resolved in the rewrite of the choreo 
lifeline section.

I am assuming that this automatic invocation of finalizer would no longer be 
supported under your proposal - a finalizer will only be invoked if an 
explicit 'finalize' activity is placed in the parent choreography? If this 
is not the case, then I don't believe the proposal discusses in which 
situations the finalizer would be called automatically, and this would be 
ambiguious in cases where multiple finalizers had been defined.

2) If a coordinated choreography is specified, does this mean that it takes 
responsibility for invoking the 'confirm' or 'cancel' finalizers? and 
therefore it would be invalid for the parent choreography to attempt to 
invoke these finalizers?

3) Not sure that the 'confirm' and 'cancel' finalizers have the same 
semantics as any other finalizer. The 'cancel' finalizer does rollback work, 
but it would be triggered prior to the completion of the child choreography 
(due to the coordination protocol), not as a result of an exception in the 
parent choreo. The 'confirm' finalizer has completely different semantics - 
it represents a commit essentially, and therefore does not undo/rollback 
work - plus in the same way as the cancel, it is not triggered by an 
exception in the parent choreo.

Possibly this is a case of trying to reuse existing concepts to simplify the 
language, but it may be overloading the finalize concept too much.

Related note: After studying the Choreology proposals and looking into the 
exception handling and finalizer mechanisms in more detail recently, I think 
the naming of the 'finalizer' leads to confusion in relationship to the 
commonly understood semantics of a Java 'finally' block in relation to java 
exception handling (i.e. the closeness of the terms tends to implies that 
the work inside the finalizer block will be performed regardless of whether 
the choreo completes normally or with an exception). Possibly it should be 
renamed 'compensation'?

Received on Wednesday, 3 November 2004 12:03:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:06 UTC