Issue 180 - Proposal For Vote

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

(sorry, my previous posting screwed up the subject line)

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.