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霵ig Mail: IBM Deutschland Entwicklung GmbH
Senior Technical Staff Member Tel (office): (+49) 7031-16-3426 Sch霵aicher Strasse 220
Architect, Business Process Choreographer Fax (office): (+49) 7031-16-4890 71032 B鐽lingen
Member, Technical Expert Council Tel (home office): (+49) 7032-201464 Germany
Danny van der
Rijn
< To
> Alex Yiu <>
cc
11.10.2006 00:14
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
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
