[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
Hi Prasad and Ron, Adding two more attributes would only resolve the issue, if the faultName attribute references a NCName, and no longer a QName (IMHO exactly this rises the current uniqueness constraint): <catch faultName="cannotCompleteOrder" portType="pos:purchaseOrderPT" operation="sendPurchaseOrder"> ... </catch> IMHO a solution for this issue must consider that <catch> should still be able to catch the BPEL internal faults. They are all declared as QNames, i.e. bpel:joinFailure, for which no portType and operation context information is available. Additionally, <throw> can introduce new process internal faults without any additional context information, too. Ron, I think your proposed solution would not be able to address this requirement (assuming faultName references a NCName) and I'm not 100% sure in case of your solution, Prasad. Is the faultName attribute still a QName in your case? Best regards/Mit freundlichen Grüßen, Thomas Schulze Prasad Yendluri <pyendluri@webmet hods.com> To Ron Ten-Hove 22.07.2006 01:32 <Ronald.Ten-Hove@Sun.COM> cc Thomas Schulze/Germany/IBM@IBMDE, Please respond to alex.yiu@oracle.com, pyendluri@webmeth wsbpel@lists.oasis-open.org ods.com Subject Re: [wsbpel] new issue - clarification on whether the QName of a fault needs to be unique across all portTypes and operations 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. 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> 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. Regards, Prasad Ron Ten-Hove wrote: Prasad, Exploring your first option (getting rid of the uniqueness restriction) will lead, in some cases, to ambiguous <catch> activities, where the fault name can be mapped to more than one fault declaration in the portType definitions used by the process. In some cases, the existing <catch> messageType attribute would serve to disambiguate the faults. In other cases, including the example in front of use, it is not sufficient, for both faults have the same type (pos:orderFaultType). We could declare that under such circumstances, the <catch> with receive faults from both operations, explicitly allowing this type of ambiguity. I can't see too many issues arising out of two allowing two different fault sources, where the fault has the same name and type. If there were two separate faults with the same name but different types (massaging our example slightly): <catch faultName="pos:cannotCompleteOrder" faultMessageType="pos:secondOrderFaultType"> ... </catch> Alternatively, we could add some extra attributes to the <catch> to disambiguate the source of the fault: portType and operation. Going back to our example (without massaging): <catch faultName="pos:cannotCompleteOrder" portType="pos:purchaseOrderPT" operation="sendPurchaseOrder"> ... </catch> This approach seem less intrusive than inventing a way of mapping the <portType, operation name, fault name> tuple to a QName. Regardless of solution, I think this is a real issue. -Ron Prasad Yendluri wrote: I think we need to derive the QNames without violating the WSDL fault definition model. If we force major WSDL level restrictions like this, it becomes impossible to integrate existing Web services into business process, without fist revamping the interface definitions to use unique fault names (for the same fault) at each operation in a portType as well as at all portTypes in a WSDL. Then the revamped Web services (with new interface definitions) need to be redeployed, impacting all existing clients. Only solutions I see are: (1) to get rid of this uniqueness restriction totally at WS-BPEL level and figure out a way to deal with it. (2) to integrate, all of the portType namespace, portType name, operation name and fault name into the QName so that we will still have unique fault name at WS-BPEL level without degrading WSDL model. E.g. <PortType-Namespace>:<portType name>.<operation name>.<fault name> (if we don't line . we can use any separator a NCName syntax allows) So, in the case of Initial Example in section 5.1, for these two portTypes where targetNamespace= "http://manufacturing.org/wsdl/purchase" <wsdl:portType name="purchaseOrderPT">