- From: Haugen Robert <Robert.Haugen@choreology.com>
- Date: Sat, 30 Oct 2004 12:51:41 +0100
- To: <public-ws-chor@w3.org>
Coordinated Choreographies WS-CDL Spec Changes
Plain text inline, pdf to come Monday, word.doc sent on request.
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 how it ended: that is, if
the Choreography ended successfully or suffered an exception, and if the
Choreography specified more than one Finalizer, 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. An Interaction can be defined as being aligned (align="true").
The alignment attribute is effectively a requirement on the binding that
it must, by some means, ensure that the alignment is achieved.
Interaction alignment necessarily proceeds step by step. In other
words, Interaction alignment can assure that parties agree that a
particular message with particular content has been sent and received,
but cannot assure agreement on propositions that require more than one
step.
1.2. Choreography coordination (coordination="true") provides a
larger unit of coordination - a set of Interactions that end with shared
knowledge among the parties that their business relationship is in a
defined state: for example, contract agreement. Again, 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.2.1. All roles agree whether the choreography completed
successfully or suffered an exception;
1.2.2. If the choreography specifies Finalizer blocks, all
roles experience the same Finalizer block.
1.3. The implications of coordination differ for single-level
Choreographies versus composed Choreographies:
1.3.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
experience the same Finalizer. A Composed Choreography may also have an
Exception block that determines what alignment is achieved if the
Choreography fails.
1.3.2. A single-level Choreography (i.e. a root, with no
enclosed choreography or performed choreography, and as a root,
incapable of being composed in CDL) can also be coordinated, but cannot
have Finalizers. The only coordination alignment mechanism available is
the Exception block, which determines the alignment achieved if the
Choreography fails.
1.3.3. In both cases, if an exception occurs, all roles must
experience an exception rather than successful completion of the
Choreography.
1.4. A CDL Choreography is a global model of a process where all the
real action is happening at end points. Therefore the end points can get
out of alignment.
1.4.1. For example, an exception can occur at a role or roles
that are still interacting when other roles in the choreography think it
is complete, and will not experience the exception. Even other roles
that are still interacting may not experience the exception, since
exceptions are raised in interactions between two roles, thus throwing
at most two roles into exception state, and exception blocks may be
guarded and so not experienced by all roles.
1.4.2. However, according to the CDL exception rules, "If a
fault occurs within a Choreography, then the faulted Choreography
completes unsuccessfully and this causes its Finalizer WorkUnit[s] to be
disabled".
1.4.3. Therefore, coordination="true" means that when a fault
occurs within a Choreography, the coordination mechanism will throw a
silent fault to all roles, and disable any enabled finalizers. This
silent fault may be caught by an unguarded Exception Block. If no
unguarded Exception Block has been defined for the Choreography, the
result will be the same as an abnormal termination (see section 2.4.7
Choreography Life-line).
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.
1.5. 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:
Three features in WS-CDL may require support from a
Transaction/Coordination protocol:
1. Alignment Interactions:
1.1. 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. globalizedTrigger():
2.1. This WS-CDL supplied function combines expressions that include
Variables that are defined at different Roles.
3. Coordinated Choreographies:
3.1. 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, consistent globalizedTriggers, 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, 30 October 2004 11:52:12 UTC