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

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

From: Nickolas Kavantzas <nickolas.kavantzas@oracle.com>
Date: Wed, 3 Nov 2004 14:19:59 -0800
Message-ID: <27e501c4c1f3$41dc5930$48af2382@us.oracle.com>
To: "Haugen Robert" <Robert.Haugen@choreology.com>, <public-ws-chor@w3.org>
***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:


[Q1] What is the difference between this proposal and the previous Choreology proposal 
regarding coordination of transaction cancel and confirm?

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

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

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

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

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

What happens if the Finalizers are never fired?

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

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

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

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

[Q11] What are the consequences with respect to the Finalize element when the enclosing 
Choreography lacks an Exception Block and/or Finalizer Blocks?

[Q12] What impact does the enclosing Choreography's Complete condition, if present, have on 
the rules for defining the Finalize element?

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


Thanks in advance.
Received on Wednesday, 3 November 2004 23:14:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:01:10 GMT