issue with use of SOAP Faults

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: issue with use of SOAP Faults

In section 4.5 the requirement to use SOAP Faults in specific cases,
may not be feasible:

Because the RMP is unable to distinguish a message that belongs to a Req-Resp MEP, from one
taht belongs to a One-Way, it is not clear how the RMP can behave differently based on this:
- One-Way should not return SOAP Faults in HTTP response (to be WS-I 1.0 compliant)
- but Req-Resp are required to do so in case below:

"In case of a Request-Response WSDL operation type, when the message cannot be passed to the consumer due to a failure in processing the RM headers, and therefore no application response can be returned, a SOAP Fault MUST be returned. If the RM Fault is a Message Format fault, a SOAP client fault MUST be returned. If it is a Message Processing fault, a soap:server fault MUST be returned.

The latter case also applies to responses to duplicate messages that are not delivered. In case a "Response" ReplyPattern was required, the RM-Reply MUST be returned in the header of the SOAP Fault message..."

The intent here , if I remember, was to make sure that the lack of application response would be escalated properly as a fault / exception to the Sender app (or "producer"), which would be achieved by adding a SOAP Fault in the HTTP response.

One way out of this would be to link the use of SOAP Faults in HTTP responses to the
replypattern "Response", instead of to the WSDL op type
(The response reply pattern is supposed to be used only for WSDL Req-Resp ops.)

Also,  in case replypattern is something else: do we still need to use SOAP Faults? (I don't
believe there is a point to it.)

Jacques