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: R18 - Proposal For Vote

Section 10.3, p. 86 currently says:

In the case of a request-response invocation, the operation might return a WSDL fault message. 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. To ensure consistent fault identification, this uniform naming mechanism MUST be followed even though it does not match the WSDL’s fault-naming model. WSDL 1.1 does not require fault names to be unique within the namespace where the service operation is defined. Therefore, in WSDL 1.1 it is necessary to specify a port type name, an operation name, and the fault name to uniquely identify a fault. Using WSDL 1.1's scheme would limit the ability to use fault-identification and handling mechanisms to deal with invocation faults.

I propose adding the following paragraph after that:

In WSDL it is possible to declare an operation that declares more than one fault using the same data type.  Certain WSDL bindings do not provide enough information for the WS-BPEL process to infer which fault was intended.  In this case, the WS-BPEL process MUST infer the first fault declared for the operation that matches the transmitted data.  A result of this requirement is that a process may have different behavior when deployed against different bindings.

I propose that this is marked as a substantive change.

In addition, I propose the following editorial change:

Section 3, P. 11 currently says:

While WS-BPEL attempts to provide as much compatibility with WSDL 1.1 as possible there are three areas where such compatibility is not feasible.

·        Fault naming with its restriction, as discussed later in this document (see section 12.5. Fault Handlers)

But Section 12.5 says

Data thrown with a fault can be a WSDL message type or a XML Schema element. Each <catch>, which specifies a QName as its faultName attribute value, can only catch a fault with a matching QName (see section 10.3. Invoking Web Service Operations – Invoke for the description of how to construct this QName from a fault defined in WSDL).

Proposed change:

P. 11 should have its reference to 12.5 replaced with one to 10.3

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