[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 afault needs to be unique across all portTypes and operations
Hi Thomas, Yes, in the proposal I made, the BPEL faultName is always a QName. Instead of the current scheme to derive BPEL faultName QName for WSDL faults that does not result in unique QNames, the proposal uses all components of portType as below: BPEL faultName QName = <PortType-Namespace>:<portType name>.<operationname>.<fault name> The namespace prefix in the QName is WSDL fault's portType Namespace (same as now). The localPart (string after ':') uses all components of the portType of the WSDL fault. 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"> <wsdl:operation name="sendPurchaseOrder"> <wsdl:input message="pos:POMessage"/> <wsdl:output message="pos:InvMessage"/> <wsdl:fault name="cannotCompleteOrder" message="pos:orderFaultType"/> </wsdl:operation> </wsdl:portType> The BPEL level faultName QName is: targetNamespace:purchaseOrderPT.sendPurchaseOrder.cannotCompleteOrder and for <wsdl:portType name="shippingPT"> <wsdl:operation name="requestShipping"> <wsdl:input message="pos:shippingRequestMessage"/> <wsdl:output message="pos:shippingInfoMessage"/> <wsdl:fault name="cannotCompleteOrder" message="pos:orderFaultType"/> </wsdl:operation> </wsdl:portType> The BPEL level faultName QName is: targetNamespace:shippingPT.requestShipping.cannotCompleteOrder This eliminates the need for the current restriction we have. Per WSDL 1.1 component model, fault names need be unique within the scope of an "operation" of a portType only. This proposal does not constrain that further. Regards, Prasad Thomas Schulze wrote: 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"> <wsdl:operation name="sendPurchaseOrder"> <wsdl:input message="pos:POMessage"/> <wsdl:output message="pos:InvMessage"/> <wsdl:fault name="cannotCompleteOrder" message="pos:orderFaultType"/> </wsdl:operation> </wsdl:portType> The BPEL level fault Qname is: targetNamespace:purchaseOrderPT.sendPurchaseOrder.cannotCompleteOrder and for <wsdl:portType name="shippingPT"> <wsdl:operation name="requestShipping"> <wsdl:input message="pos:shippingRequestMessage"/> <wsdl:output message="pos:shippingInfoMessage"/> <wsdl:fault name="cannotCompleteOrder" message="pos:orderFaultType"/> </wsdl:operation> </wsdl:portType> The BPEL level fault Qname is: targetNamespace:shippingPT.requestShipping.cannotCompleteOrder This eliminates the need for the restriction as, per WSDL 1.1 component model, fault names must be unique within the scope of an operation. Regards, Prasad Thomas Schulze wrote: -1 to this issue. In <catch> and <reply> BPEL refers to a fault name by a QName. It might be possible to change <reply> so it references the faultName by NCName, because the portType and operation information is available here. But on <catch> this context information is not available and a QName is really required. Therefore BPEL currently introduces the restriction that a faultName must be unique within a targetNamespace to fulfill the QName uniqueness constrain and this should not be changed with respect to XML Namespaces. Best regards/Mit freundlichen Grüßen, Thomas Schulze Prasad Yendluri <pyendluri@webmet hods.com> To Alex Yiu <alex.yiu@oracle.com> 21.07.2006 02:05 cc wsbpel@lists.oasis-open.org, Thomas Schulze/Germany/IBM@IBMDE, Diane Please respond to Jordan <drj@us.ibm.com>, Peter pyendluri@webmeth Furniss ods.com <peter.furniss@erebor.co.uk> Subject Re: [wsbpel] new issue - clarification on whether the QName of a fault needs to be unique across all portTypes and operations I just replied to the other related thread on this and just noticed Alex submitted a new issue. +1 to this issue. We should not force fault-names to be unique across portTypes or across different operations in a portType. Please see: http://www.oasis-open.org/apps/org/workgroup/wsbpel/email/archives/200607/msg00054.html Regards, Prasad -------- Original Message -------- Subje [wsbpel] new issue - clarification on whether the QName of a fault ct: needs to be unique across all portTypes and operations Date: Thu, 20 Jul 2006 15:51:09 -0700 From: Alex Yiu <alex.yiu@oracle.com> To: wsbpel@lists.oasis-open.org CC: Alex Yiu <alex.yiu@oracle.com>, Thomas Schulze <ThomasSchulze@de.ibm.com>, Diane Jordan <drj@us.ibm.com>, Peter Furniss <peter.furniss@erebor.co.uk> Refer <OFB99DE239.58A80A52-ONC12571B1.00763042-C12571B1.007723B0@de.ibm.c ences om> 44C0020D.5010105@oracle.com"><44C0020D.5010105@oracle.com> : New issue: --------------------------------------------- Subject: clarification on whether the QName of a fault needs to be unique across all portTypes and operations Description: The spec text related to SA00049: "This results in a fault identified in WS-BPEL by a QName formed by the target namespace of the corresponding portType and the fault name. To ensure uniqueness, this uniform naming mechanism MUST be followed even though it does not match the WSDL’s fault-naming model ..." Does that text require the QName of a fault needs to be unique across all portTypes and operations? That is: two different operations within the same portType or two different portTypes of the same TNS define the same fault name (potentially with two different message types). Are these cases of WSDL design legal and usable by WS-BPEL? It seems to me that the intention of phase "to ensure uniqueness" is unclear. Does it just mean a uniform behavior? Or, it tries to enforce universally unique across all WSDL definitions? Questions to consider: - Does WS-I have a similar universally-unique restriction? If not, we may have problems in taking WS-I complaint WSDL pattern? - With <throw>, one can associate one faultName with more than one faultMessageTypes already. Then, what does this universal-uniqueness restriction buy us in terms of <catch> construct usage? --------------------------------------------- Thanks! Regards, Alex Yiu Alex Yiu wrote: Thomas, Thanks for the reply. I would double check with WS-I people as well. Most likely, I would open a clarificaiton issue. Two more data points to consider: - Does WS-I have a similar restriction? If not, we may have problems in taking WS-I complaint WSDL pattern? - With <throw>, one can associate one faultName with more than one faultMessageType already. Then, what does this restriction buy us? Most likely, I would open issue to request a clarification on that front. Thanks! Regards, Alex Yiu Thomas Schulze wrote: Hi Alex, I think SA00049 (that's the current SA code; I changed the subject, too) and the current wording in the spec in paragraph 10.3 is very clear. It requires uniqueness of the QName "{ns of the portType}faultName" and NOT only uniqueness of the faultName inside a portType. We don't like to change this. In the initial example the two mentioned portTypes are declared in the same targetNamespace "http://manufacturing.org/wsdl/purchase" and both declare the faultName "cannotCompleteOrder". This means the faultName QName { http://manufacturing.org/wsdl/purchase }cannotCompleteOrder is NOT unique and thus, the initial example is not valid according to the current spec. That's why I propose to just fix the initial example. In case you'd like to change this rule in the spec, you should open a new issue. Best regards/Mit freundlichen Grüßen, Thomas Schulze Alex Yiu <alex.yiu@oracle. com> To Thomas Schulze/Germany/IBM@IBMDE 19.07.2006 19:25 cc wsbpel@lists.oasis-open.org, Alex Yiu <alex.yiu@oracle.com> Subject Re: [wsbpel] Initial example violates SA00050? Hi Thomas and others, Quick gut feeling response. I don't think the example violates the fault naming requirement imposed by the spec. "This results in a fault identified in WS-BPEL by a QName formed by the target namespace of the corresponding portType and the fault name. To ensure uniqueness, this uniform naming mechanism MUST be followed even though it does not match the WSDL’s fault-naming model ..." IMHO, it does NOT imply or enforce that the faultName QName must be unique by across all portTypes. However, I agree that the underlined sentence sounds a bit ambiguous to me. That is what is the uniqueness it is referring to??? "This results in a fault identified in WS-BPEL by a QName formed by the target namespace of the corresponding portType and the fault name. To ensure consistent fault identification, this uniform naming mechanism MUST be followed even though it does not match the WSDL’s fault-naming model ..." **IF** the sentence did enforce that the faultName QName must be unique by across all portTypes, the semantic would be very strange. When mapped to OOP world, interfaces of the same package cannot throw the same Exception? Thomas ... if you disagree with my interpretation, we may need to open our last BPEL issue on that. (sorry to john and diane in advance) Thanks! Regards, Alex Yiu Thomas Schulze wrote: The initial example in 5.1 introduces the WSDL fault 'cannotCompleteOrder' two times, one for portType 'purchaseOrderPT' operation 'sendPurchaseOrder' and one for portType 'shippingPT' operation 'requestShipping'. This violates SA00050 (v26 of the SA List): "In the case of a request-response invocation, the operation might return a WSDL fault message. This results in a fault identified in WS-BPEL by a QName formed by the target namespace of the corresponding portType and the fault name. To ensure uniqueness, this uniform naming mechanism MUST be followed even though it does not match the WSDL’s fault-naming model." Should this be fixed before the freeze? If yes, some adaptions to 5.6 are necessary, too... Best regards/Mit freundlichen Grüßen, Thomas Schulze |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]