- From: Haugen Robert <Robert.Haugen@choreology.com>
- Date: Fri, 19 Nov 2004 15:25:26 -0000
- To: <public-ws-chor@w3.org>
Coordinated Choreographies WS-CDL Spec Changes
Revised according to comments from ws-chor F2F meeting
on Thursday 18 November 2004
This version also incorporates previous suggestions from Monica Martin
and Gary Brown.
[See Note to Editors below for one minor change from what we agreed on
during the meeting. The Note also explains the reason for the change.
The Note also comments on some ambiguity in the IRC log about the
disposition of the section in which the Note appears.]
Choreology Proposal 1: Choreography coordination="true|false"
In section 2.4.4 Choreographies:
Insert after "...the finalization actions for that enclosing
Choreography":
Exception and Finalizer blocks may also be used in conjunction with a
Choreography's coordination attribute to provide abort and outcome
mechanisms for coordinated choreographies (where coordination="true").
Change from:
<choreography name="ncname"
complete="xsd:boolean XPath-expression"?
isolation="dirty-write"|"dirty-read"|"serializable"?
root="true"|"false"? >
Change to:
<choreography name="ncname"
complete="xsd:boolean XPath-expression"?
isolation="dirty-write"|"dirty-read"|"serializable"?
root="true"|"false"?
coordination="true"|"false"?>
Insert before "The relationship element within the choreography
element...":
The optional coordination attribute specifies whether a Choreography
guarantees that all involved roles agree on the state in which the
Choreography ended: that is, if the Choreography completed successfully
or suffered an exception, and if the Choreography completed successfully
and Finalizers were installed, all roles agree on which Finalizer
happened.
1. When coordination is set to "true", some mechanism (not
specified by CDL) must ensure that all the roles agree on how the
Choreography ended. Such agreement differs from Interaction alignment
in that the Choreography as a whole is aligned at its closure,
regardless of whether each Interaction in the coordinated Choreography
is aligned.
1.1. In contrast to aligned Interactions, Choreography coordination
(coordination="true") provides a larger unit of coordination - a set of
Interactions that end with shared knowledge among the parties that their
relationship is in a defined state. As with aligned Interactions, this
is a requirement stated in the CDL that the binding will have to ensure.
Such a unit need not be aligned at each step (though it could be) - it
is only required that a clear alignment point is made at the end of the
Choreography. Alignment via coordination means that:
1.1.1. All roles agree whether the Choreography completed
successfully or suffered an exception;
1.1.2. If Finalizers were installed for the Choreography, all
roles experience the same Finalizer.
1.2. The implications of coordination differ for single-level
Choreographies versus composed Choreographies:
1.2.1. A Composed Choreography (performed or enclosed in a
higher-level Choreography) may have multiple Finalizers, differentiated
by name, that determine the aligned outcome of a coordinated
Choreography. In this case, coordination means that, if the
Choreography completes successfully, all roles experience the same
Finalizer. A Composed Choreography may also have an Exception block that
determines what alignment is achieved if the Choreography does not end
successfully.
1.2.2. A single-level Choreography (i.e. a root, not enclosed
or performed by another Choreography, and as a root, incapable of being
composed in CDL) can also be coordinated, but cannot have Finalizers.
Such a Choreography may still use an Exception Block as a coordination
alignment mechanism, determining the alignment achieved if the
Choreography fails.
1.2.3. In both cases, if an exception occurs, all roles must
experience an exception rather than successful completion of the
Choreography.
1.2.3.1. Therefore, coordination="true" means that when a fault
occurs within a Choreography, the coordination mechanism will throw an
exception to roles which have not otherwise detected an exception, and
this exception must cause any installed finalizers to be uninstalled.
This exception may be specified in WS-CDL as a special Exception
Information Type, exactly as:
<informationType name="coordinationException" exceptionType=true/>
[Note to Editors: Changed name of Exception Info Type from
"coordinationFailure", because it does not mean that coordination
failed: in fact, coordination succeeded in aligning all roles in an
exception state. Did not know what to specify for type or element, but
apparently one of them should be there. Also, it was not clear from the
IRC log whether this special Exception Info Type should have been added
or not, nor was it clear whether or not this numbered section should
have been moved to the introduction to this numbered list.]
If so specified, the exception may be caught by a guarded Exception Work
Unit. If not so specified, the exception may be caught by an unguarded
Exception Work Unit. If no applicable guared or unguarded Exception
Work Unit has been defined for the Choreography, the rules are the same
as for any other unmatched exception (see Exception Block).
1.3. When coordination is set to "false", the Choreography is not
bound to a coordination protocol, and none of the above guarantees of
agreement on the outcome applies.
Examples:
Coordinated credit authorization without finalizers:
<informationType name="creditDeniedType" exceptionType="true"/>
<!-- Coordinated CreditAuthorization choreography without finalizers-->
<choreography name="CreditAuthorization" root="false"
coordinated="true">
<relationship type="tns:CreditReqCreditResp"/>
<variableDefinition>
<variable name="CreditExtended" informationType="xsd:int"
silentAction="true" roleType="tns:CreditResponder"/>
<variable name="creditRequest"/>
<variable name="creditAuthorized"/>
<variable name="creditDenied" informationType =
"creditDeniedType"/>
</variableDefinition>
<!-- the normal work - receive the request and decide whether to
approve -->
<interaction name="creditAuthorization"
channelVariable="tns:CreditRequestor">
<participate relationship="SuperiorInferior"
fromRole="tns:Superior" toRole="Inferior"/>
<exchange name="creditRequest" informationType="creditRequest"
action="request">
<send variable="tns:creditRequest"/>
<receive variable="tns:creditRequest"/>
</exchange>
<exchange name="creditAuthorized" informationType="creditDenied"
action="respond">
<send variable="tns:creditAuthorized"/>
<receive variable="tns:creditAuthorized"/>
</exchange>
<exchange name="creditDenied" informationType="refusal"
action="respond">
<send variable="tns:creditDenied" causeException="true"/>
<receive variable="tns:creditDenied" causeException="true"/>
</exchange>
</interaction>
<!-- catch the (application) exception - as an exception it will
abort the choreography -->
<exception name="handleBadCreditException">
<interaction channelVariable="tns:CreditResponder"
operation="creditDenied">
<participate relationship="CreditReqCreditResp"
fromRole="tns:Responder" toRole="CreditRequestor"/>
</interaction>
</exception>
</choreography>
Coordinated credit authorization with finalizers:
<informationType name="creditDeniedType" exceptionType="true"/>
<!-- Coordinated CreditAuthorization choreography with finalizers -->
<choreography name="CreditAuthorization" root="false"
coordinated="true">
<relationship type="tns:CreditReqCreditResp"/>
<variableDefinition>
<variable name="CreditExtended" informationType="xsd:int"
silentAction="true" roleType="tns:CreditResponder"/>
<variable name="creditRequest"/>
<variable name="creditAuthorized"/>
<variable name="creditDenied" informationType =
"creditDeniedType"/>
</variableDefinition>
<!-- the normal work - receive the request and decide whether to
approve -->
<interaction name="creditAuthorization"
channelVariable="tns:CreditRequestor">
<participate relationship="SuperiorInferior"
fromRole="tns:Superior" toRole="Inferior"/>
<exchange name="creditRequest" informationType="creditRequest"
action="request">
<send variable="tns:creditRequest"/>
<receive variable="tns:creditRequest"/>
</exchange>
<exchange name="creditAuthorized" informationType="creditDenied"
action="respond">
<send variable="tns:creditAuthorized"/>
<receive variable="tns:creditAuthorized"/>
</exchange>
<exchange name="creditDenied" informationType="refusal"
action="respond">
<send variable="tns:creditDenied" causeException="true"/>
<receive variable="tns:creditDenied" causeException="true"/>
</exchange>
</interaction>
<!-- catch the (application) exception - as an exception it will
abort the choreography and the finalizers are not accessible -->
<exception name="handleBadCreditException">
<interaction channelVariable="tns:CreditResponder"
operation="creditDenied">
<participate relationship="CreditReqCreditResp"
fromRole="tns:Responder" toRole="CreditRequestor"/>
</interaction>
</exception>
<!-- Finalizers -->
<!-- what to do if the credit is drawn down -->
<finalizer name="drawDown">
<!-- if there is no application content to send, this could just
be an assignment to the statecapturevariable creditExtended -->
<interaction channelVariable="tns:CreditRequestor"
operation="drawDown">
<participate relationship="CreditReqCreditResp"
fromRole="tns:CreditRequestor" toRole="CreditResponder"/>
<record when="before">
<source value="drawnDown"/>
<target variable="CreditExtended"/>
</record>
</interaction>
</finalizer>
<!-- what to do if the credit is not used -->
<finalizer name="replenish" case="cancel" default="true">
<!-- if there is no application content to send, this could just
be an assignment to the statecapturevariable creditExtended -->
<interaction channelVariable="tns:CreditRequestor"
operation="replenish">
<participate relationship="CreditReqCreditResp"
fromRole="tns:CreditRequestor" toRole="CreditResponder"/>
<record when="before">
<source value="released"/>
<target variable="CreditExtended"/>
</record>
</interaction>
</finalizer>
</choreography>
In section 6 Relationship with the Transaction/Coordination framework:
Change from:
In WS-CDL, two parties make progress by interacting. In the cases where
two interacting parties require the alignment of their Variables
capturing observable information changes or their exchanged information
between them, an alignment Interaction is modeled in a Choreography.
After the alignment Interaction completes, both parties progress at the
same time, in a lock-step fashion. The Variable information alignment
comes from the fact that the requesting party has to know that the
accepting party has received the message and the other way around, the
accepting party has to know that the requesting party has sent the
message before both of them progress. There is no intermediate state,
where one party sends a message and then it proceeds independently or
the other party receives a message and then it proceeds independently.
Implementing this type of handshaking in a distributed system requires
support from a Transaction/Coordination protocol, where agreement of the
outcome among parties can be reached even in the case of failures and
loss of messages.
Change to:
Two features in WS-CDL may require support from a
Transaction/Coordination protocol:
1. Alignment Interactions:
In WS-CDL, two parties make progress by interacting. In the cases
where two interacting parties require the alignment of their Variables
capturing observable information changes or their exchanged information
between them, an alignment Interaction is modeled in a Choreography.
After the alignment Interaction completes, both parties progress at the
same time, in a lock-step fashion. The Variable information alignment
comes from the fact that the requesting party has to know that the
accepting party has received the message and the other way around, the
accepting party has to know that the requesting party has sent the
message before both of them progress. There is no intermediate state,
where one party sends a message and then it proceeds independently or
the other party receives a message and then it proceeds independently.
2. Coordinated Choreographies:
WS-CDL Choreographies may specify coordination="true", which means the
Choreography guarantees that all involved roles will agree on how it
ends. If an exception occurs, all roles will experience an exception.
If a Choreography specifies more than one Finalizer, all roles will
experience the same Finalizer.
Implementing Alignment Interactions or Coordinated Choreographies in a
distributed system requires support from a Transaction/Coordination
protocol, where agreement on the outcome among parties can be reached
even in the case of failures and loss of messages.
Choreology Anti virus scan completed
Received on Friday, 19 November 2004 15:26:00 UTC