RE: Questions on Choreology's Coordinated Choreographies Proposals 1, 3, 4

Dear Nick and others,
 
This reply is made on behalf of myself, Bob and Peter and is a compilation
of our individual thoughts.  We hope it is helpful, increases understanding
of our proposals and generally moves us forward.  For convenience I have
embedded the answers below your questions below.
 
Best Regards     Tony
A M Fletcher
 
Cohesions  (TM)
 
Business transaction management software for application coordination
www.choreology.com <http://www.choreology.com/> 
 
Choreology Ltd., 68 Lombard Street, London EC3V 9LJ     UK
Tel: +44 (0) 1473 729537   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 Nickolas Kavantzas
Sent: 03 November 2004 22:20
To: Haugen Robert; public-ws-chor@w3.org
Subject: Questions on Choreology's Coordinated Choreographies Proposals 1,
3, 4


***Oracle's Questions on Choreology's Proposals 1, 3, 4***
 
 
Our questions below are based on the assumption that this is an all or
nothing grand proposal
even though we understand that the three proposals could be discussed
independently: 
>>That is one view although actaully some of the proposals, or parts
thereof, could make sense on their own.
 
 
[Q1] What is the difference between this proposal and the previous
Choreology proposal 
regarding coordination of transaction cancel and confirm? 
 >> With regard to Tony's original proposal the syntax is quite different
although the end effect is intended to be the same.  With regard to the
proposals made at the New York F2F, just a filling out of the detailed spec
changes as Peter said on the teleconference held 2 Nov 04.
However, these questions are really for historians, we would urge getting to
grips with the current proposal and the proposed detailed changes to the
specification. 
 
[Q2] What are the detailed requirements on the underlying coordination
protocol? For example, 
where are the coordination points of the Choreography, i.e. end of main
block, beginning 
and/or end of Exception block and/or Finalizer block?  
>>The coordination promise (which we assume is what is meant) applies at the
very end - after finalization if there are finalizers, at the end of the
choreography, including exceptions if there are no finalizers. It's not
generally required that the end of the main block is a coordination point
when there are finalizers - or rather, there is no promised signal at that
point. In practice, when the whole transaction goes prepared, it will be
coordinated (in the provisional state) but the parties don't all know when
that is, and they may get to that state at different times, before getting
hit by a finalizer. 
 
[Q3] What impact does the Choreography coordination attribute have on the
isolation 
semantics? Does the isolation semantics end at the end of the main
Choreography block 
and the end of the Exception block or at the end of the Finalizer block? 
>>As detailed below on Q4, it's the same as happens now with existing
exceptions and finalizers. I suspect the answer is end of main. Possibly the
finalizer re-asserts it. It would normally continue to apply during the
exception handling. 
 
[Q4] In proposal 1 we don't understand the following section.
 
      1.4.3.1. Note: coordination does not guarantee that all roles
will experience the same exception or exception block.  In fact, if an
interaction throws two roles into an exception state, which is caught by
a guarded exception block, any other roles will experience a different,
unguarded exception block catching the silent fault thrown by the
coordination mechanism. 
 
Isn't a Choreography incorrect if there are situations where different
exceptions may 
be thrown and propagated? 
>>That section and other similar ones were based on our interpretation of
Nick's exception proposal, which appears to throw at-most two roles into an
exception state at once.  If other roles are involved in the choreography,
how would they experience the same exception?  That's not a rhetorical
question, we are trying to figure it out.  Could the same
exceptionType-variable be assigned to the other roles?  But if so, wouldn't
the choreography need to do that explicitly, and couldn't it be omitted, or
fault?  In general, we smell something fishy about the assertions of an
exception aborting the choreography, but the exception only being
experienced by at most two roles. 
 
If we misunderstood, and Nick intends that all roles experience the same
exception (somehow), then our specification task may be easier, but you
still need a coordination mechanism to make it so.
 
In n > 3 party, the initial detector of the problem might see one exception,
his immediate neighbour see the resulting fault message, and the other
party(s) see a general "something has gone wrong" exception - which would in
fact be transaction cancel.
 
 
[Q5] Proposal 3 states:
 
* Choreography Finalizer Block  describes how to specify
additional interactions that should occur to modify the effect of an
earlier successfully completed Choreography, for example to confirm or
undo the effect 
 
Should there be rules for from where "confirm" and "undo" Finalizer Blocks
may be 
triggered, i.e. "undo" only from enclosed Choreography's Exception Block? 
>>We don't distinguish an "undo" block.  And even if we did, there are
business reasons for cancelling a transaction that have nothing to do with
exceptions.  For example, in the TWIST case, the Buyer decides which
Seller's priceResponse to accept, and all transactions for other Sellers are
cancelled. 
 
[Q6] Proposal 3 states:
 
In section 2.4.7 Choreography Life-line:
 
Insert after the paragraph starting with "A Choreography completes
successfully...":
 
After a Choreography completes successfully, any Finalizer blocks
specified in the Choreography are enabled.  In other words, as long as
Finalizer blocks are enabled, the Choreography is still alive until one
of the enabled Finalizers is fired and completes its own Work Unit, at
which time the Choreography is closed. 
 
What does 'AFTER the Choreography COMPLETES successfully 
it is still ALIVE' means? Does it imply that the isolation semantics are 
still in effect?
 
Could we get a definition for COMPLETES SUCCESSFULLY and ALIVE? 
>>We didn't define COMPLETES SUCCESSFULLY, and wish it had a different name
and clearer semantics.  ALIVE is true in the current CDL finalizer scheme as
well as our multiple finalizer proposal. When the choreography completes
successfully, whatever that means, the finalizer or finalizers are enabled.
The current Finalizer spec says "The actions within the Finalizer Work Unit
MAY use Variable information visible in the Visibility Horizon of the
Choreography it belongs to as they were at the time the Choreography
completed or as they stand at the current time."  Don't know how the
finalizer will distinguish between "as-they-were" and "as-they-stand", but
clearly the variables in the scope of the choreography must be kept alive
until the finalizer(s) finish. 
 
>From a business viewpoint, the situation is even trickier:  outside
observers cannot tell when the values they saw at the choreography's
"successful completion" can be trusted, until a finalizer finishes, because
the finalizer may undo anything and everything. So, as in the examples Peter
gave, if a seller has an order, it is not safe to commit resources until a
finalizer finishes. 
 
What happens if the Finalizers are never fired? 
>>That's the same issue, now as well as with our proposal.  Under the
current spec, the single Finalizer will only be fired if an exception occurs
in the enclosing choreography.   In other words, it may never fire.  The
same would be true of a single "undo" choreography under our proposal. If
you had "undo" and "close", if "close" fired, all roles could be sure that
"undo" would not fire. 
If only one "undo" Finalizer, and it never fires, then an implicit "close"
will happen at the completion of the root choreography. And only then can
the seller in the previous example be sure it is safe to commit resources,
that is, the order will not be undone. 
 
[Q7] Proposal 3 states:
 
Finalizers may implement whatever actions are appropriate for the
particular Choreography.  Common patterns might include:
* A single Finalizer to semantically "undo" the Choreography,
typically called "compensation". 
* Two Finalizers, e.g. name="confirm" and name="cancel", to
implement a two-phase outcome protocol.
* One "undo" Finalizer along with a "close" Finalizer to signal
that the "undo" Finalizer is no longer able to fire, that is, the
Choreography is now closed.
 
In the first case, does this mean that it is optional to fire the Finalizer
Block or 
does it mean that the Choreography has to be "compensated"? 
>>Not sure we fully understand the question but first case is the present
one isn't it ?  There's an empty, implicit "close" finalizer, which fires at
the end of time (or, perhaps, the completion of the root choreography).
Maybe it would be clearer if we removed the clause   ",typically called
"compensation".
 
[Q8] Proposal 4 states:
 
A Choreography SHOULD have at least one finalize element for each
finalizer in an immediate inner choreography that it encompasses.
 
Why is this not a MUST? 
>>Because it seemed right to make a strong recommendation, but it is not a
necessity.  Therefore it is not a 'must', in fact one could argue that the
language should be weakened rather than made stronger.  If a finalizer
element does not a have a finalize that references it then it can never by
followed (activated) in the choreography, but this is no worse than have a
method / procedure in a programming language which is never called.  It is
not actually a compile error though a compiler may issue a warning.  I would
expect CDL tools / compilers to do the same - maybe issue a warning that
there is no corresponding finalize, but not to indicate a hard error.  In
terms of use cases, I can envisage people developing extra finalizer
routines and trying them out and not want to delete an 'old' one until
testing completed successfully.  More cogently perhaps the inner
choreography is designed and intended to be composable and different
enclosing (or using) choreographies could make use of alternate finalizers.
Many people minimizes how difficult it will be for normal people to develop
bulletproof choreographies, and in B2B cases, for trading partners to
negotiate, test and implement them.  One way or another,  better methods
than one-off bespoke development-from-scratch will be required.  Patterns
will be part of those better methods, and so will adaptive evolution, and so
will the usual cut-and-paste.
 
We hope this is clear and makes sense now. 
 
[Q9] Proposal 4 states:
 
A Choreography MAY have more than one finalize element for a named
finalizer in an immediate inner choreography that it encompasses, as
long as those finalize elements are contained in different Work Units
with different guards. 
 
Is this not to strong a restriction? Shouldn't the semantics be that ONE and
ONLY ONE 
finalizer block MUST be triggered ONCE and ONLY ONCE? 
>>Yes, that is the semantics that we wanted to achieve and intended this
text and other text in proposal 4 to achieve that.  Internally (Tony)
suggested having conditional statements (guards) on the finalize element so
you could think of what it was going to do and when it should do it
together, but  that idea was vetoed in favour of using the existing guards
on the Work Unit element, hence this restriction, plus that on mutual
exclusivity of all the guards that apply to a particular inner choreography.

 
 To summarise this : we wanted to specify the dynamic restrictions (which is
indeed only one finalizer fires, once), and were trying to state it via
static constraints. We are not sure one can, and it may be better to just
state the dynamic rule.
 
[Q10] Could you please describe, with examples, where the Finalize element
must 
be defined in different situations, i.e in the enclosing Choreography's main
block, 
Exception Block when present and Finalizer Blocks when present.  
>> Our  understanding is that the finalize element is an 'activity' and can
be used in an enclosing choreography wherever it would be valid to have
other activity elements.  There is an example of the use of finalize in
proposal 4 (the examples in the other proposals are snippets of choreography
descriptions that concentrate on the enclosed choreography and the finalizer
elements and do not show the enclosing choreography and its finalize
elements).  Yes to all three: main block, 
Exception Block when present and Finalizer Blocks when present.
 
[Q11] What are the consequences with respect to the Finalize element when
the enclosing 
Choreography lacks an Exception Block and/or Finalizer Blocks? 
>>None, the finalize element(s) will just be part of the activities of that
choreography. 
 
[Q12] What impact does the enclosing Choreography's Complete condition, if
present, have on 
the rules for defining the Finalize element? 
>>We think we need to discuss and understand how the complete condition
works first.  One of the worrying things about the complete condition is
that it seems to be able to cut into the operation of a choreography at any
arbitrary point, so the first question is what effect does the complete
condition have on an interaction that is part way through.  Current feeling
is that the complete condition becoming true should still allow the finalize
element(s) to operate before the choreography is fully completed and left
behind. 
 
[Q13] It seems to us that there is an inconsistency between the way an
Exception Block is
defined today in CDL and how its Exception WorkUnits are considered for
matching a fault
and the way you propose the Finalizer block should be defined. As I said in
the NY F2F
wouldn't be better if the two mechanisms were made more similar? 
>>The two situations are different.  Exceptions are thrown and caught by
Exception Blocks, where an unguarded Exception Block can catch any loose
cannons.  Finalize explicitly fires a particulare Finalizer block by name.
There is no default and there are no loose cannons. 
 
Nick  are you suggesting a single finalizer with a set of catchers in it,
and finalize passes in a value that is caught. That would seem to be a
distinction only in syntax.
 
 

Thanks in advance.