[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] new issue - clarification on whether the QName of a faultneeds to be unique across all portTypes and operations
Prasad Yendluri wrote:
Hi Ron,Agreed, <catch> is already complex, both syntactically and semantically. I was just exploring an alternative.
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>?
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.<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>
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.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.