[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - R18 - Uniqueness of WSDL Faults
> IMO, this is another situation where WS-BPEL should not attempt to solve a > problem that resides between WSDL and bindings. While I agree with this statement, we are left with the problem that we *require* an implementation to know the fault name. That is the problem that I think we have to address. Dieter Koenig1 wrote: > 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]