[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fw: Initial example violates SA00050?
Because it's only a change in the example and the explaining text I'd like to propose to open a new action item to address this bug (no normative wording needs to be changed). Diane/John, we should discuss this in today's call. Here is my proposal (based on v1.161): >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In section 5.1 in the WSDL change the fault name in portType shippingPT from: <!-- portType supported by the shipping service --> <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> to: <!-- portType supported by the shipping service --> <wsdl:portType name="shippingPT"> <wsdl:operation name="requestShipping"> <wsdl:input message="pos:shippingRequestMessage"/> <wsdl:output message="pos:shippingInfoMessage"/> <wsdl:fault name="cannotCompleteShipping" message="pos:orderFaultType"/> </wsdl:operation> </wsdl:portType> In the process change the process' fault handler from: <faultHandlers> <catch faultName="lns:cannotCompleteOrder" faultVariable="POFault" faultMessageType="lns:orderFaultType"> <reply partnerLink="purchasing" portType="lns:purchaseOrderPT" operation="sendPurchaseOrder" variable="POFault" faultName="cannotCompleteOrder"/> </catch> </faultHandlers> to: <faultHandlers> <catch faultName="lns:cannotCompleteShipping" faultVariable="POFault" faultMessageType="lns:orderFaultType"> <reply partnerLink="purchasing" portType="lns:purchaseOrderPT" operation="sendPurchaseOrder" variable="POFault" faultName="cannotCompleteOrder"/> </catch> </faultHandlers> In section 5.6 change the paragraph before the last from: Certain operations can return faults, as defined in their WSDL definitions. For simplicity, it is assumed here that the two operations return the same fault ("cannotCompleteOrder"). When a fault occurs, normal processing is terminated and control is transferred to the corresponding fault handler, as defined in the <faultHandlers> section. In this example the fault handler uses a <reply> element to return a fault to the customer (note the faultName attribute in the <reply> element). to: Certain operations can return faults, as defined in their WSDL definitions. When a fault occurs, normal processing is terminated and control is transferred to the corresponding fault handler, as defined in the <faultHandlers> section. In this example the fault handler uses a <reply> element to return a fault to the customer (note the faultName attribute in the <reply> element). <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Best regards/Mit freundlichen Grüßen, Thomas Schulze ----- Forwarded by Thomas Schulze/Germany/IBM on 19.07.2006 13:12 ----- Thomas Schulze/Germany/I BM To wsbpel@lists.oasis-open.org 17.07.2006 11:10 cc Subject Initial example violates SA00050? 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]