OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[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]