Re: [wsbpel] Issue R18 - final resolution

["Monica J. Martin" <Monica.Martin@Sun.COM>]

>Diane Jordan wrote:  As decided on the Oct. 25 TC call: 
>In Section 10.3,  after the paragraph that says:
>n 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. 
>Add:
>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 determine which fault was 
>intended. In this case, the WS-BPEL processor MUST select the fault that:
>Matches the transmitted data and
>Occurs first in lexical order in the operation definition. 
>A result of this requirement is that a process, which uses the <catch> 
>construct based on faultName and deals with such an operation definition, 
>may have different behavior when deployed against different bindings.  
> 
>In section 3, P. 11, in the li  
>Change:
>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)
>To:
>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 10.3 Invoking Web Service Operations - Invoke)
>
mm1: Note in reviewing, we may have missed another section that may be 
impacted by or need revision given R18 resolution. See Section 10.4 
given how we are not technically binding agnostic:

    WS-BPEL treats faults based on abstract WSDL 1.1 operation
    definitions, without reference to binding details. This limits the
    ability of a WS-BPEL process to determine the information
    transmitted when faults are returned over a SOAP binding.