[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [wsbpel] Issue - R18 - Uniqueness of WSDL Faults
There are actually multiple cases: - multiple WSDL fault names with the same WSDL fault message - multiple WSDL fault names with different WSDL fault messages containing the same WSDL part definition(s) For these cases, you may have (a) a binding that provides the fault name --> no issue (b) a binding (like SOAP) that does not provide the fault name --> the service provider should redesign the interface IMO, this is another situation where WS-BPEL should not attempt to solve a problem that resides between WSDL and bindings. Kind Regards DK Dieter König Mail: dieterkoenig@de.ibm.com IBM Deutschland Entwicklung GmbH Senior Technical Staff Member Tel (office): (+49) 7031-16-3426 Schönaicher Strasse 220 Architect, Business Process Choreographer Fax (office): (+49) 7031-16-4890 71032 Böblingen Member, Technical Expert Council Tel (home office): (+49) 7032-201464 Germany Danny van der Rijn <dannyv@tibco.com To > Alex Yiu <alex.yiu@oracle.com> cc 11.10.2006 00:14 wsbpel@lists.oasis-open.org Subject Re: [wsbpel] Issue - R18 - Uniqueness of WSDL Faults Alex Yiu wrote: Hi Danny, Regarding to the suggestion in your first bullet: changing the fault catching behavior to not use fault name, but its data type I am not sure I follow 100%. But, if my understanding is correct, we have already supported that kind of capabilities: ------------- <catch faultName="QName"? faultVariable="BPELVariableName"? ( faultMessageType="QName" | faultElement="QName" )? >* ------------- e.g.: <catch faultElement="foo:aFaultElement"> or <catch faultMessageType="foo:aFaultMsgType"> What I meant in the first bullet is that <catch faultName="QName"> is not a well-defined option if the fault name can't be readily inferred. So it would need to be changed somehow, or removed. Of course, I guess the next question is: is that good enough? and do we need other extra "tools or ropes" suggested in your other bullets? And, I am not sure I follow your third bullet. As for the 3rd bullet, I was suggesting that we specify an algorithm for turning transmitted data into a fault QName. As an example, I was suggesting a lexical first match against the fault elements specified in the WSDL. Note that I don't have a suggestion for fault types, just elements. I imagine types would be similar, though. Thanks! Regards, Alex Yiu ws-bpel issues list editor wrote: This issue has been added to the wsbpel issue list with a status of "received". The status will be changed to "open" if a motion to open the issue is proposed and that motion is approved by the TC. A motion could also be proposed to close it without further consideration. Otherwise it will remain as "received". The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent version of the document entitled in the "Issues" folder of the WSBPEL TC document list - the next posting as a TC document will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL. Issue - R18 - Uniqueness of WSDL Faults Status: received Date added: 10 Oct 2006 Date submitted: 10 October 2006 Submitter: Danny van der Rijn Description: 1) Assume I have a WSDL portType that looks like the following: portType pT operation op input element = "a:b" output element = "a:c" fault name="fault1" element = "a:fault" fault name="fault2" element = "a:fault" Most WSDL transports (e.g. SOAP) do not tranport fault names on the wire. Usually all that is transmitted is the "a:fault" element, wrapped in some information that does not include the fault name. Yet 10.3 states that "This results in a fault identified in WS-BPEL by a QName formed by the target namespace of the corresponding port type and the fault name." We have no way of deriving, in this case, whether we're talking about foo:fault1 or foo:fault2. Possible resolutions include changing the fault catching behavior to not use fault name, but its data type disallowing WSDLs that use the same element in more than one fault in an operation. (In the whole WSDL?) explicitly specifying rules for inferring fault names. For example, we could say that "a:fault" will always be turned into "foo:fault1" and "foo:fault2" will never be inferred. 2) Can't find in the spec what the QName of a non-declared fault is. Changes: 10 Oct 2006 - new issue To comment on this issue (including whether it should be accepted), please follow-up to this announcement on the wsbpel@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - R18 - [anything]" or is a reply to such a message. If you want to formally propose a resolution to an open issue, please start the subject line "Issue - R18 - Proposed resolution", without any Re: or similar. To add a new issue, see the issues procedures document
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]