Prasad Yendluri wrote:
Hi Ron,
I think your first option really boils down to not unique case. Thomas
had concerns with <catch> not having enough information on the
fault if the Fault Names (QNames) are not unique in a given namespace
(of the portType).
Your second option is more attractive to me. However <catch>
already has too many options and confusing permutations and
combinations of those options (current syntax below):
<catch faultName="QName"?
faultVariable="BPELVariableName"?
faultMessageType="QName"?
faultElement="QName"?>*
activity
</catch>
Adding two more
attributes seems would make it worse.
Agreed, <catch> is already complex, both syntactically and
semantically. I was just exploring an alternative.
Also showing a
portType and
Operation on <catch> like below, could draw parallels with
<receive> syntax where the message is received from the portType
and operation by the activity directly?
<catch faultName="pos:cannotCompleteOrder" portType="pos:purchaseOrderPT" operation="sendPurchaseOrder">
...
</catch>
This brings up another possible solution: using the existing
messageExchange naming scheme. Perhaps the ambiguous <catch> can
be resolved in the same fashion as the ambiguous <reply>?
<scope>
<messageExchanges>
<messageExchange name="order"/>
<messageExchange name="ship"/>
</messageExchanges>
<faultHandlers>
<catch faultName="pos:orderFaultType messageExchange="order" .../>
<catch faultName="pos:orderFaultType messageExchange="ship" .../>
</faultHandlers>
<sequence>
<invoke operation="sendPurchaseOrder" messageExchange="order" .../>
...
<invoke operation="requestShipping" messageExchange="ship" .../>
</sequence>
</scope>
Just a thought... this exploits an existing disambiguation mechanism,
and is much less complicating for describing the behaviour of
<catch>. We could preserve the existing wording of how
<catch> works, and just append some language identifying the
ambiguous <catch> case, and requiring that it be resolved by the
process author by means of identifying the applicable message exchange.
In either case, either the approach above or the QName derivation
scheme I proposed below that make fault names unique in a namespace
without constraining the WSDL model, would make a viable solution to
this issue IMO.
Yes, I think we solve the issue one way or another. The QName synthesis
approach may need work, since it requires a delimiter character that
cannot appear in an NCName, and isn't a colon, and is valid for a URI.
I suspect '.' isn't the best choice.
-Ron
|