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

Coordinated Choreographies Proposal 3 - Multiple Finalizers

From: Haugen Robert <Robert.Haugen@choreology.com>
Date: Sat, 30 Oct 2004 12:56:20 +0100
Message-ID: <221369570DEDF346AE42821041345E8951BC5F@imap.choreology.com>
To: <public-ws-chor@w3.org>
Coordinated Choreographies Spec Changes 
Plain text inline, pdf to come Monday, word.doc sent on request.

Choreology Proposal 3: multiple Finalizers

In section 2.1 Model Overview:

Change from:

*	Choreography Recovery consists of:
o	Choreography Exception Block - describes how to specify what
additional interactions should occur when a Choreography behaves in an
abnormal way
o	Choreography Finalizer Block - describes how to specify what
additional interactions should occur to reverse the effect of an earlier
successfully completed Choreography

Change to:

*	Choreography Exception Block  describes how to specify what
additional interactions should occur when a Choreography behaves in an
abnormal way
*	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

In section 2.4.4 Choreographies:

Change from:

<choreography  name="ncname"
      complete="xsd:boolean XPath-expression"?
      isolation="dirty-write"|"dirty-read"|"serializable"?
      root="true"|"false"? >
   <relationship  type="qname" />+
   variableDefinitions?
   Choreography-Notation*
      Activity-Notation
   <exception  name="ncname">
        WorkUnit-Notation+
   </exception>?
   <finalizer  name="ncname">
        WorkUnit-Notation
   </finalizer>
</choreography>

Change to:

<choreography  name="ncname"
      complete="xsd:boolean XPath-expression"?
      isolation="dirty-write"|"dirty-read"|"serializable"?
      root="true"|"false"? 
      coordination="true"|"false"?>
   <relationship  type="qname" />+
   variableDefinitions?
   Choreography-Notation*
      Activity-Notation
   <exception  name="ncname">
        WorkUnit-Notation+
   </exception>?
   <finalizer  name="ncname">
        WorkUnit-Notation
   </finalizer>*
</choreography>

Change from:

A Choreography can recover from exceptional conditions and provide
finalization actions by defining:
*	One Exception block, which MAY be defined as part of the
Choreography to recover from exceptional conditions that can occur in
that enclosing Choreography
*	One Finalizer block, which MAY be defined as part of the
Choreography to provide the finalization actions for that enclosing
Choreography

Change to:

A Choreography can recover from exceptional conditions and provide
finalization actions by defining:
*	One Exception block, which MAY be defined as part of the
Choreography to recover from exceptional conditions that can occur in
that enclosing Choreography
*	One or more Finalizer blocks, differentiated by name if more
than one, which MAY be defined as part of the Choreography to provide
the finalization actions for that enclosing Choreography

[Editor's note:  does the phrase "enclosing Choreography" in the above
text mean "the Choreography in which the Exception or Finalizer block is
defined"?  If so, it is an obscure way to say it. If not, we do not
understand the phrase in this context.]

Change from:

The optional finalizer element defines the Finalizer block of a
Choreography by specifying one Finalizer Work Unit.

Change to:

The optional finalizer element defines a Finalizer block of a
Choreography. A Choreography may have more than one Finalizer Block.
Each Finalizer block specifies one Finalizer Work Unit.  If a
Choreography defines more than one Finalizer block, each must be
differentiated by name.

In section 2.4.5 WorkUnits:

Change from:

A Work Unit MAY prescribe the constraints that preserve the consistency
of the collaborations commonly performed between the parties. Using a
Work Unit an application MAY recover from faults that are the result of
abnormal actions and also MAY finalize completed actions that need to be
logically rolled back.

Change to:

A Work Unit MAY prescribe the constraints that preserve the consistency
of the collaborations commonly performed between the parties. Using a
Work Unit an application MAY recover from faults that are the result of
abnormal actions and also MAY finalize completed choreographies that
need further action, for example to confirm or logically roll back
effects, or to close the choreography so that any defined rollback Work
Unit will not fire.

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.

In section 2.4.8:

Change from:

2.4.8 Choreography Recovery

One or more Exception WorkUnit(s) MAY be defined as part of a
Choreography to recover from exceptional conditions that can occur in
that Choreography. 

A Finalizer WorkUnit MAY be defined as part of a Choreography to provide
the finalization actions that semantically "undo" that completed
Choreography.

Change to:

2.4.8 Choreography Exception Handling

One or more Exception WorkUnit(s) MAY be defined as part of a
Choreography to recover from exceptional conditions that can occur in
that Choreography. 

2.4.9 Finalizers and Coordination

One or more Finalizer WorkUnits MAY be defined as part of a Choreography
to provide the finalization actions that close a completed Choreography.

Change from:

2.4.8.2 Finalizer Block

When a Choreography encounters an exceptional condition it MAY need to
revert the actions it had already completed, by providing finalization
actions that semantically rollback the effects of the completed actions.
To handle these a separate Finalizer Work Unit is defined in the
Finalizer Block of a Choreography.

A Choreography MAY define one Finalizer Work Unit.

A Finalizer WorkUnit is enabled only after the Choreography it belongs
to completes successfully. The Finalizer Work Unit may be enabled only
once. 

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.

The actions of the Finalizer Work Unit MAY fault. The semantics for
matching the fault and acting on it are the same as described in the
previous section.

Change to:

2.4.9.2 Finalizer Block

After a Choreography instance has successfully completed its Work Units,
it MAY need to provide finalization actions that confirm, cancel or
otherwise modify the effects of the completed actions. To handle these
modifications, one or more separate Finalizer Blocks may be defined for
a Choreography.

If more than one Finalizer is defined for the same Choreography, each of
them must be differentiated by their name attributes. However, only one
Finalizer may be fired for any given Choreography instance, and when the
Finalizer has completed, the Choreography instance will be closed.

Finalizers are particularly useful for coordinated Choreographies, where
the coordination attribute is set to "true".  In this case, the roles
involved in the Choreography can be assured that they are all aligned on
the outcome of the Choreography: that is, all roles will experience the
same Finalizer.

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.

The Finalizer WorkUnits are enabled only after the Choreography they
belong to completes successfully. The Finalizer Work Units may be
enabled only once: that is, the Work Unit must not contain a repeat
attribute. 

The actions within a 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.

The actions of a Finalizer Work Unit MAY fault. The semantics for
matching the fault and acting on it are the same as described in the
previous section.


Choreology Anti virus scan completed
Received on Saturday, 30 October 2004 11:56:53 GMT

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