OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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,

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"? 

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">
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>?
        <messageExchange name="order"/>
        <messageExchange name="ship"/>
        <catch faultName="pos:orderFaultType messageExchange="order" .../>
        <catch faultName="pos:orderFaultType messageExchange="ship" .../>

        <invoke operation="sendPurchaseOrder" messageExchange="order" .../>
        <invoke operation="requestShipping" messageExchange="ship" .../>
Just a thought... this exploits and existing disambiguation mechanism, and is much less complicating for describing the behaviour of <catch>.
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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]