Re: [wsbpel] R18 - Proposal For Vote

[Alex Yiu <alex.yiu@oracle.com>]

Hi Danny,

[1]
Regarding to your new paragraph, I would like to tighten up the wordings a bit and add one more guideline for users:

From:

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.

To:

In WSDL it is possible to define 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 processor to infer which fault was intended. In this case, the WS-BPEL processor MUST infer the first fault by lexical order in the operation definition that matches the transmitted data. A result of this requirement is that a process, which uses <catch> construct based on faultName and deals with such an operation definition, may have different behavior when deployed against different bindings. One possible way to avoid different behavior results from bindings is to use <catch> construct based on faultElement or faultMessageType, instead of faultName.

What do you think?


[2]

Regarding to editorial cross-reference changes in section 3
-----------------------------

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

-----------------------------

I think both references to 10.3 and 12.5 are needed.

If my memory is correct, restrictions in section 12.5 is talking about multiple operations in multiple porTypes can use the same fault name. Given a particular fault name, one cannot tell which portType/operation is coming from.

So, in short, I am suggesting to add a reference, not replace a reference.


Thanks!



Regards,
Alex Yiu




Danny van der Rijn wrote:

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