[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: new text for Soap faults and WSRM clarfication
This is the proposed text changes, taking into account Pete Wenzel's
comments:
Clarification of Soap Faults and wsrm:response
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 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.
“
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 this case, when 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. In such a case, the Receiving RMP MUST cause an
wsrm:Response to be sent in a header of 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, when the Response reply pattern
is in use, 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; [email protected]
Tel: +1 732 801 5744 Fax: +1 732 774 5133
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]