- From: Nickolas Kavantzas <nickolas.kavantzas@oracle.com>
- Date: Tue, 12 Oct 2004 11:08:39 -0700
- To: public-ws-chor@w3.org
In the last F2F I mentioned that I was working in an exception related proposal.
Here is the exception proposal for resolving the issue 565 (location http://www.w3.org/Bugs/Public/show_bug.cgi?id=565):
***Exception Proposal for resolving Issue 565***
Oracle, October 10 2004
*Summary*
An Exception is propagated to all parties in the Choreography using,
explicitly modelled, exception causing interactions. Then the Choreography enters
the Exception state and the control in the current Choreography jumps to the Exception
Block
*Exception Types*
Exception Type definition will be supported by extending the informationType construct.
The new syntax of the informationType construct will be changed to:
<informationType name="ncname"
type="qname"? | element="qname"? exceptionType= "true|false"? />
The description would be:
The attributes type, and element describe the document to be a
WSDL 1.1 Message type, XML Schema type, an XML Schema element or a
WSDL 2.0 schema element. Only one of these attributes MUST be used in a single
informationType element.
If WSDL 1.1 is used, type attribute MUST be used to refer to WSDL message
type. When type attribute is defined, it can also refer to a simple or complex XSD type.
For WSDL2.0 message types, only the element attribute MUST be used.
When exceptionType attribute is "true", this type is an Exception Type and could map
to WSDL fault type. Since WSDL 2.0 supports unique faultnames, the element attribute
in the informationType refers to a WSDL 2.0 faultname when exceptionType is "true".
By default, this attribute is "false".
*Variable Definition*
This following change is proposed for this section:
· A Variable defined with informationType having the attribute exceptionType
set to "true" is an Exception Variable and causes an Exception to occur at a party when
populated
*Changes in the Interaction Section*
An Exception Causing Interaction MAY be used to put one or more parties into Exception state.
This Exception Causing Interaction is an interaction having one or more exchange elements
or record elements with the causeException attribute set to "true" to populate Exception
Variable(s).
Below is the new interaction syntax:
<interaction name="ncname"
channelVariable="qname"
operation="ncname"
time-to-complete="xsd:duration"?
align="true"|"false"?
initiate="true"|"false"? >
<participate relationship="qname"
fromRole="qname" toRole="qname" />
<exchange name="ncname"
informationType="qname"? channelType="qname"?
action="request"|"respond" >
<send variable="XPath-expression"? recordReference="list of ncname"?
causeException="true|false"? />
<receive variable="XPath-expression"? recordReference="list of ncname"?
causeException="true|false"? />
</exchange>*
<record name="ncname"
when="before"|"after"
causeException="true|false"? >
<source variable="XPath-expression" />
<target variable="XPath-expression" />
</record>*
</interaction>
Below are the rules for the exchange part of the interaction section:
· The send and receive elements of respond messages MAY have attribute
causeException set to "true". The referenced Variables MUST be Exception Variables.
This puts the respective parties into Exception state
· The send and receive elements in a request exchange MUST NOT have the
attribute causeException set to "true"
· When multiple respond message exchanges are specified, one respond
message MUST be of normal informationType and all the others MUST be of exception
informationType. There is an implicit choice between the respond exchanges
Below are the rules for the record part of the interaction section:
· The attribute causeException MAY be set to "true" in a record element if
the target Variable is an Exception Variable
· When the attribute causeException is set to "true" in a record element, the
corresponding party gets into Exception state
· When multiple record elements are specified in the interaction with target
Variables of type Exception Types, one of the Exception records MAY occur. An
exception record element has an non-observable predicate condition associated with it
implicitly that decides if the Excepion of that type occurs
*New WS-CDL function*
cdl:hasExceptionOccurred(xsd:string informationTypeName)
This function returns "true" if the exception identified by the parameter
informationTypeName has occured. Otherwise it returns "false". The informationType with
name informationTypeName MUST have exceptionType set to "true".
*Changes in the Exception Block section*
The following rules have to be specified in the Exception Block section:
. An Exception is propagated to all parties in the Choreography using,
explicitly modelled, Exception Causing Interactions. Then the Choreography enters
the Exception state and the control jumps to the Exception Block
· There MAY be one or more Work Units (always defined with block="false") within the
Exception block in a choreography that can guard Exception Names or Exception Variables.
· The Work Units MAY have guards using the WS-CDL function hasExceptionOccurred or
globalizedTrigger on Exception Variables of the same Exception Type involving all roles in
the Choreography. No other guards are allowed to be specified in the top-level Work Units
of an Exception Block
· When a Work Unit is defined using the WS-CDL function
hasExceptionOccurred(informationTypeName), then this Work Unit is matched when any
Exception Variable(s) of type informationTypeName is populated using an Exception Causing
Interaction activities
· When a Work Unit has guards using the WS-CDL function getGlobalizedTrigger then this
Work Unit is matched when the specified Exception Variables are populated
using Exception Causing Interaction activities. All the Exception Variables
specified in the guards using the WS-CDL function getGlobalizedTrigger MUST be of the same
Exception Type
***Examples***
*Example#1*
Example of causing an exception using send/receive in a two party Choreography and handling
of exceptions using hasExceptionOccurred():
<choreography relationship="BuyerSellerRelationship">
<informationType name=" purchaseOrderBadAckType"
element="wsd:BadAckFault" exceptionType=true/>
<variableDefinitions>
<variable name="purchaseOrderBadAck" informationType="tns:purchaseOrderBadAckType"/>
</variableDefinitions>
. . . . . .
. . . . . .
<interaction channelVariable="tns:retailer-channel "
operation="handlePurchaseOrder" align="true"
initiate="true">
<participate relationship="tns:ConsumerRetailerRelationship"
fromRole="tns:Consumer" toRole="tns:Retailer"/>
<exchange informationType="tns:purchaseOrderType" action="request">
<send variable="cdl:getVariable("tns:purchaseOrder")" />
<receive variable="cdl:getVariable("tns:purchaseOrder")"
recordReference="populateChannel" />
</exchange>
<exchange informationType="purchaseOrderAckType" action="respond">
<send variable="cdl:getVariable("tns:purchaseOrderAck")" />
<receive variable="cdl:getVariable("tns:purchaseOrderAck")" />
</exchange>
<exchange informationType="purchaseOrderBadAckType" action="respond">
<send variable="cdl:getVariable("tns:purchaseOrderBadAck")" causeException="true" />
<receive variable="cdl:getVariable("tns:purchaseOrderBadAck")" causeException="true" />
</exchange>
<record name="populateChannel" when="after">
<source variable="cdl:getVariable("tns:purchaseOrder, "PO/CustomerRef")" />
<target variable="cdl:getVariable("tns:consumer-channel")" />
</record>
</interaction>
. . .
. . .
<!-- Exception workunit that handles the exception raised above -->
<exception name="HandleBadPOExceptions"
<workunit name="handleBadResponse"
guard="cdl:hasExceptionOccurred("tns:purchaseOrderBadAckType")>
<!-- do the activity -->
</workunit>
</exception>
</choreography>
---------------------------------------------
*Example #2*
Example of causing an exception during request only interaction in a two party
Choreography and Handling of Exceptions using globalizedTrigger:
<choreography relationship="BuyerSellerRelationship">
<variableDefinitions>
<variable name="purchaseOrderResponse" informationType="tns:purchaseOrderResponseType"/>
<variable name="purchaseOrderBadResponse" informationType="tns:purchaseOrderBadResponseType"
exceptionState="true"/>
</variableDefinitions>
. . . . . .
. . . . . .
<interaction channelVariable="tns:retailer-channel "
operation="handlePurchaseOrder" align="true"
initiate="true">
<participate relationship="tns:ConsumerRetailerRelationship"
fromRole="tns:Consumer" toRole="tns:Retailer"/>
<exchange informationType="tns:purchaseOrderBadResponseType" action="request">
<send variable="cdl:getVariable("tns:purchaseOrderResponse")"
recordReference="populateExceptionVarOnSend" />/>
<receive variable="cdl:getVariable("tns:purchaseOrderBadResponse")"
recordReference="populateExceptionVarOnReceive" />
</exchange>
<record name=" populateExceptionVarOnSend" when="after" causeException="true" >
<source variable="cdl:getVariable("tns:purchaseOrderResponse")"/>
<target variable="cdl:getVariable("tns:purchaseOrderBadResponse")"/>
</record> this time it is the record that causes the exception
<record name=" populateExceptionVarOnReceive" when="after" causeException="true" >
<source variable="cdl:getVariable("tns:purchaseOrderResponse")"/>
<target variable="cdl:getVariable("tns:purchaseOrderBadResponse")"/>
</record>
</interaction>
. . .
. . .
<!-- Exception workunit that handles the exception raised above -->
<exception name="HandleBadPOExceptions"
<workunit name="handleBadResponse"
guard="cdl:globalizedTrigger(
"cdl:isVariableAvailable("purchaseOrderBadResponse", "buyer") , "buyer",
"cdl:isVariableAvailable("purchaseOrderBadResponse", "seller"), "seller")">
</workunit>
</exception>
</choreography>
Regards,
--
Nick
Received on Tuesday, 12 October 2004 18:09:18 UTC