response to action item to clarify soap faults and WSRM responses

[Tom Rutt <tom@coastin.com>]

Clarification of Soap Faults and wsrm:response

This is in response to Pete Wenzel's comments.

Lines 1025 – 1030

“

*Example case 1:*

For WSDL Request/Response operation types, a SOAP Fault can occur for a 
reliable request which was delivered, but then encountered an 
application level Fault due to something wrong in the payload (SOAP Body 
of request which is not under control of Sending RMP) or application 
processing space outside the realm of the receiving RMP.

That means a Acknowledgment can be delivered on a SOAP Fault.

“

Need to be clarified as follows:

“

“Example case 1:

For WSDL Request/Response operation types, an operation request which 
was successfully delivered by the receiving RMP to the Receiver may 
result in an application level Faults, (e.g., one specified in the WSDL 
description for the operation), to be returned.

In such a case, when the response reply pattern is in use, the Soap 
fault message associated with this application level Fault MUST carry 
the RM-Acknowledgment in a wsrm:Response element. within its Soap header.

This is required so that the Sending RMP gets knowledge of the 
successful Delivery of the Reliable message request, even though the 
operation encountered an application level fault condition associated 
with the processing of the WSDL request/response operation.

“

line 1031 - 1047:

“

*Example case 2:*

For the Response Reply Pattern, used with WSDL two way operation type, 
the return message could conceivably carry an indication of an RM Fault, 
which is not itself carried on a SOAP Fault. The exact behavior in such 
a case might be an implementation matter.

A message with an RM Fault indication MUST NOT be delivered by the 
receiving RMP. If the message cannot be delivered due, say an request 
fault, then there would be no meaningful data for the responder to put 
into the SOAP Body for the WSDL response.

When using the Response RM-Reply pattern, a WSDL operation reply will 
not always be available for the receiving RMP to return with the 
RM-Response. This will occur when there is a Reliable Messaging Fault 
for the message in the request, or when the message in the request is a 
duplicate of a prior delivered message with Duplicate Elimination in use.

When a receiving RMP cannot return the WSDL operation response for a 
request using the Response Reply Pattern, it MUST return the RM Response 
in a SOAP Fault message. If the RM Fault encountered was due to a 
problem with the request header element, a SOAP client fault MUST be 
returned. If the RM Fault encountered was due to a problem with 
processing by the receiving RMP (including the inability to return a 
response due to Duplicate Elimination), a

soap:server fault must be returned.

“

Need to be clarified to the following:

“

*Example case 2:*

A message with an RM Fault indication MUST NOT be delivered to the 
receiver by the receiving RMP. In such a case, when the response reply 
pattern is in use:

    * If the WSDL response has no parts bound to the soap:body, a Soap
      return message could be constructed by the receiving RMP, with an
      indication of an RM Fault in a wsrm:Response element in its
      Soap:header, and with an empty soap:body. It would also be valid
      to return a soap:fault in this case, with the wsrm:response
      element in its soap:header. The exact behavior in such a case is
      an implementation matter.

    * If the WSDL response has parts bound to the soap body, the
      receiving RMP would not have the ability to construct a meaningful
      WSDL response to put into the SOAP body. In this case, if the
      Response RM-Reply pattern is in use, a WSDL operation response
      will not be available for the receiving RMP to return with the
      RM-Response including an RM-fault indication. It would have to
      cause the wsrm:response to be sent in a soap:fault message.

This same condition arises when the message in the request is a 
duplicate of a prior delivered message with Duplicate Elimination in 
use. The Receiving RMP, in such a case, has no meaningful WSDL response 
to return for that WSDL request/response operation, so it must cause a 
soap:fault to be returned. The difference in behaviour with this 
duplicate elimination condition, is that an RM-Fault indication is not 
sent for that request in the soap:fault message.

In cases where a receiving RMP MUST NOT deliver a WSDL request/respose 
operation request to the receiver, that receiving RMP must be able to 
initiate the return of a SOAP Fault message, associated with that 
request, as follows:

    * If the RM-Fault indication was due to a problem with the request
      header element, a SOAP client fault MUST be returned.
    * If the RM Fault encountered was due to a problem with processing
      by the receiving RMP (including the inability to return a response
      due to Duplicate Elimination), a soap:server fault must be returned.

“

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133