- From: Haugen Robert <Robert.Haugen@choreology.com>
- Date: Sat, 20 Nov 2004 20:22:08 -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.
Revised again according to further comments
from Nickolas Kavantzas.
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 all roles agree on
whether 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.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.
In this case, coordination means that all roles agree on whether the
Choreography completed successfully or suffered an exception.
1.2.3. In both cases, all roles must agree on whether the
Choreography completed successfully, or if an exception occurs, all
roles must experience an exception rather than successful completion.
1.2.3.1. Therefore, coordination="true" means that when an
exception occurs within a Choreography, the coordination mechanism will
throw an exception to roles which have not otherwise detected the
exception, and this exception must cause any installed finalizers to be
uninstalled. This exception may be caught by an unguarded Exception Work
Unit. If no 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. That is, all roles will agree on whether the Choreography
completed successfully or suffered an exception, and if the Choreography
completed successfully and Finalizers were installed, all roles will
agree on which Finalizer happened.
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 Saturday, 20 November 2004 20:22:41 UTC