Subject: Issue - 180 - Clarification of WSDL fault declarations and Reply in BPEL
This issue has been added to the wsbpel issue list with a status of "received". The status will be changed to "open" if the TC accepts it as identifying a bug in the spec or decides it should be accepted specially. Otherwise it will be closed without further consideration (but will be marked as "Revisitable")
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.
Imagine however the following WSDL whose target namespace prefix is "foo" :
portType name="aPort" operation name="o1" ... fault name="aFault" ... ... operation name="o2" ... fault name="aFault" ... ... operation name="o3" ... fault name="aNewFault" ... ...
Now imagine the following BPEL fragment:
... reply partnerLink="..." portType="foo:aPort" operation="o1"/ variable="..." faultName="foo:aFault" ... reply partnerLink="..." portType="foo:aPort" operation="o1"/ variable="..." faultName="foo:aNewFault"
Which of the replies, if any, are legal?
Is the language in section 11.3 only meant to apply when receiving a fault? If so then the first reply is legal (and unambiguous) and the second is not.
If, on the other hand, the language in section 11.3 is meant to apply both to receiving and sending faults then the first reply is illegal but the second is probably legal.
The first reply is illegal because the situation is ambiguous. If 11.3 applies then BPEL overrides the WSDL semantics and requires that faults be identified exclusively by portType name and fault name. In that case having "aFault" defined twice in the same portType (even if the message types were different) is an error that should be caught by static analysis and thus require the process to be rejected.
The second reply is legal because although "aNewFault" is not defined in
operation o1 its fault name and portType combination are unique and so
we can resolve the reference even though it isn't in the same operation
and thus, strictly speaking, isn't legal in canonical WSDL.
Submitter's proposal: I propose that the language in section 11.3 only apply to receiving faults on invokes and that we make this limitation explicit in sections 11.3 and 11.4 so there is no confusion. When sending a fault using a reply we should follow the normal WSDL rules and identify the fault using the unique combination of portType, operation name and fault name. This would mean that in the previous example the WSDL would be accepted and the first reply would be legal and the second would not.
Changes: 4 Dec 2004 - new issue
To comment on this issue (including whether it should be accepted), please follow-up to this announcement on the email@example.com list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - 180 - [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 - 180 - Proposed resolution", without any Re: or similar.
To add a new issue, see the issues procedures document (but the address for new issue submission is the sender of this announcement).
Choreology Anti virus scan completed