RE: Coordinated Choreographies Proposal 4 - Finalize Activity

Gary (and this may partly respond to some aspects of Nick's comments),

Bob is recovering in hospital, so I'll attempt to move some of this
along (I started this message on Thursday,
but got called to a meeting and the machine half-lost it)

There is a fundamental point that we perhaps haven't got clear to
everyone.


At the most general level, as soon as you allow a process entity  
to have some kind of processing that can be triggered after the process
has "completed", you have changed the meaning of "completed" to
"provisionally completed".  Thus the existence of <finalizer>, as in the
existing spec, means that the "completed" state of the choreography
isn't really completed.

Now the common perception of such things is that post-"completion"
processing can only be triggered in cases where the work is to be
undone, reversed, nulled or countered in some way. It is often further
assumed that this post-completion processing can only be triggered if
some kind of error has occurred. This is the "compensation" model.

We believe this confining assumption doesn't fit business and user
requirements well. One cannot, in general, treat a piece of work that is
liable to compensation or reversal as if it were truly final. Orders
that are subject to cancellation within some cooling-off period probably
don't trigger the salesman's payment until they are past that time; if
metal must be cut, you may offer provisional order capability and wait
until it is confirmed before doing anything irrevocable; artillery fire
plans are checked and acknowledged first but only executed if the action
order is given. It is foolish to always treat that which can be
cancelled as identical to that which cannot be cancelled.

Further, to assume that error must have occurred for reversal or
non-confirmation is again to treat a common case as invariably
appropriate. From the perspective of the service or supplier, it was
asked to be do something, subject to later confirmation or cancellation.
Whether cancellation occurs because something else went wrong, or
because the requestor changed his mind, or because the original request
was (from the requestor's perspective) only ever an option need not
affect the supplier. (If it is known an offer is provisional, it may
even be requested with the "hope" that it will be cancelled). We can
build more robust and flexible systems if we do not contaminate the
behaviour description relevant to some of the parties with the
motivations of concern only to others.

The key assumption of the compensation approach is that the "completed"
state is identical, in every way, to the final state, (i.e. after it is
certain the compensation will not be triggered). This assumption does
not apply generally, though equally it does apply in some cases. It may
be possible to force other caes to fit - shoehorning the application to
fit the 
preconceived model - but this will inevitably be bad design and produce
an inferior overall result.

The general case is that the process does some first stage, leaving
things in a provisional state, and is then finalized at some later
stage. There will be at least two alternative finalizations in concept -
othewise there was no need for any finalizers, and everything could have
been done in the main activity.


With that starting point, further specific comments below:


> -----Original Message-----
> From: Gary Brown [mailto:gary@enigmatec.net]
> Sent: 03 November 2004 12:03
> To: Haugen Robert; public-ws-chor@w3.org
> Subject: Re: Coordinated Choreographies Proposal 4 - Finalize Activity
> 
> 
> 
> 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 have been unable to find any statement in the current spec about when
finalizer's are 
invoked. This was partly a starting point to our proposals.

(c.f. BPEL, where it does explicitly state that compensation handlers
are
triggered by default exception handlers and default (higher)
compensation
handlers)

> 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.

Given the nature of CDL, I'm not sure implicit, "default" invokations
are
are a good idea. The purpose of the language is state explicitly what
can
happen.

We concluded it was better to require all finalization to be triggered
explicitly.
The alternative would be to identify one finalizer as the "default", to
be
triggered implicitly, as in BPEL. But then you get into all sorts of
lexical quirks, by
which the presence of an explicit <finalize /> (of just one enclosed
choreography) inhibits
the implicit finalizing of the others (again, as in BPEL, where it has
caused plenty of
trouble in getting the text right)


> 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?

The parent would invoke them (i.e. it would have <finalize ... />), and
the 
coordination mechanisms would ensure that all parties to the enclosed
choreography
then experience the same finalizer. Without the <finalize />, how else
does the
coordination know which one to apply ? 

> 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.

This touches on a issue we discussed internally quite a lot in working
out the detail of proposal 1 -
how to deal with the case where an exception-causing failure occurs
during
the (first-stage) "completion" of a choreography. From the perspective
of some
parties, the choreography is completed; from the perspective of others
it is 
still in flight. The coordination mechanisms guarantee that the failure
will be
signalled to all parties, but how is the required behaviour to be
described ?

We considered having an identified finalizer - which meant the guarantee
of 
coordinated="true" was that all parties experienced EITHER an exception
OR
the identified finalizer, but this got rather confusing, and meant the
root
choreography (or indeed any choreo without finalizers) would have to be
special cased.

So we concluded that coordinated="true" should mean that all will
experience
an exception (though not, as Nick says, necessarily the same exception),
and the
requirement on the binding is thus that an end caused by failure to
complete
will trigger exceptions at all parties.

If, as is likely for some cases, similar behaviour is required for some
parties as a result of such a failure, or as a result of some
finalization
instructions (from the outer choreography after the general completion
of the
inner), it may be necessary to duplicate the contents of the exception
block and
one of the finalizer blocks.

> 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'?

VERY, VERY DEFINITELY NOT.  

Oops, sorry for shouting.

Actually, it might be better to call it "completion", with some other
name - perhaps "ready",
or "readyToComplete" [Alastair's suggestion] describing where it is when
it reaches the end of the
main activity.   But it might be better to leave "completion" out of it,
as void through
ambiguity.

Peter




Choreology Anti virus scan completed

Received on Friday, 5 November 2004 11:08:44 UTC