[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Initial example violates SA00049?
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]