Proposal For Vote - 180

["Yaron Y. Goland" <ygoland@bea.com>]

180 - Clarification of WSDL fault declarations and Reply in BPEL

Proposal: Mandate that all WSDLs submitted for use with a BPEL MUST use 
the same message type with the same fault name for all faults defined in 
the same portType. Also specify that BPEL message operations can receive 
faults that are not defined in the operation but cannot send faults 
(using BPEL message activities) that aren't defined in the operation. 
Also specify that the message type for faults sent via reply MUST use 
the same type as specified in the portType. Also specify that when throw 
is used with a fault whose name is specified in a WSDL that the type has 
to match.

Rationale: This is really just filling out the requirement already in 
section 11.3 that faults be treated as using a consistent name/type 
across an entire portType. It also clarifies that WSDLs don't 
necessarily capture every single possible fault that could be received 
on an operation.

Section 11.3

Add the following after "This is an important shortcoming of the WSDL 
fault model that will be removed in future versions of WSDL.": All 
faults with the same name used in the same portType included with a 
WS-BPEL process MUST use the same message type or the WS-BPEL process 
MUST be rejected, this requirement MUST be statically enforced.

Section 13.4

Add the following after "A fault response to an invoke activity is one 
source of faults, with name and data aspects based on the definition of 
the fault in the WSDL operation (please refer to the Implementer’s Note 
in Section 11.3 for important details regarding access to fault 
information when faults are transmitted using SOAP).":  Note, however, 
that faults MAY be received that were not defined in the WSDL operation.

Section 11.4

Add the following after "We refer to the Implementer’s Note in Section 
11.3 for additional details.": The fault referred to by the faultname 
attribute MUST be defined as a fault on the associated operation, the 
previous requirement MUST be statically enforced.

Section 11.6

Add the following after "This provides a very lightweight mechanism to 
introduce application-specific faults.": Note, however, that if the 
fault name referred to in the faultName attribute matches a fault name 
defined in an associated WSDL portType then the type of the variable 
specified in the faultVariable attribute MUST match the messageType 
specified in the portType. The previous requirement MUST be statically 
enforced.