OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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.

Issue - 180 - Clarification of WSDL fault declarations and Reply in BPEL

Status: received
Date added: 4 Dec 2004
Categories: Related Standards, Fault handling
Date submitted: 02 December 2004
Submitter: Yaron Y. Goland
Description: Section 11.3 states that WSDL faults in BPEL are identified just with the portType's namespace and the fault's local name even though this does not match the WSDL 1.1 fault model which uniquely identifies faults using a combination of the portType name, operation name and fault name.

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 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 - 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]