[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] response to action item to clarify soap faults and WSRMresponses
Pete Wenzel wrote: >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. > > > I agree with this refinement, The RMP shold not have to know what is in the WSDL Description to do its job. >>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.) > > Yes, this is due to the fact that our protocol does not provide reliability on the response to a wsdl operation. > > >>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) > >To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php. > > > -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]