Re: [wsrm] response to action item to clarify soap faults and WSRM responses

[Pete Wenzel <pete@seebeyond.com>]

Thus spoke Tom Rutt (tom@coastin.com) on Tue, Apr 20, 2004 at 09:23:43PM -0400:
> Lines 1025 - 1030
> 
> Need to be clarified as follows:
> 
  Example case 1:

  For the WSDL Request/Response operation type, an operation request
  which was successfully delivered by the Receiving RMP to the receiving
  application may result in an application-level Fault, (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 gains 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.

Great; your proposed description is substantially better than before.
(I've only tweaked the terms slightly in the version above for
consistency.)

> line 1031 - 1047:
> 
> 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.

I would suggest having the RMP cause a SOAP Fault to be emitted in
both cases above, and disallow the empty soap:body, so that the RMP
need not have knowledge of the expected WSDL-defined response format.

> 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.

Let me see if I understand this:
In the above case, a duplicate request is received.  The RM-Ack is
regenerated, and must be attached to a SOAP Fault message because we
have limited the capabilities of the Receiving RMP such that it will
not have stored the original response message for retransmission.  So
if the original response was lost, it will never be delivered to the
Sending RMP; only this SOAP Fault with RM-Ack will.  (Noted in Section
5.2 as no reliability of response.)

> 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.

--Pete
Pete Wenzel <pete@seebeyond.com>
Senior Architect, SeeBeyond
Standards & Product Strategy
+1-626-471-6311 (US-Pacific)