cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <>
Subject Re: Postponing or blocking message delivery from interceptor
Date Thu, 20 Jan 2011 22:51:27 GMT
On 01/21/2011 10:57 AM, Daniel Kulp wrote:
> On Thursday 20 January 2011 2:49:53 am Dennis Sosnoski wrote:
> ..................
>> The WS-RM code does implement duplicate message checks if AtMostOnce is
>> specified (in, in which case
>> it throws an exception that goes all the way up the call stack to
>> PhaseInterceptorChain. I'd think that would result in a Fault response
>> to the client when using two-way calls, though - so it really needs to
>> be handled using the above type of approach instead, right?
> Isn't that correct though?  Looking at  the RM 1.1 spec section 3.2.2 on 
> duplicate elimination, it says:
> ------------------------------
> When the Response RM-Reply Pattern is requested with Duplicate Elimination for 
> a Reliable Message, the Receiving RMP cannot deliver that message to the 
> Consumer again (because it is a duplicate of a previously delivered message), 
> and a Consumer response payload is expected, the response of the SOAP MEP 
> instance MUST contain one (but not both) of the following:
> • a copy of the original response payload returned for that Message (in the 
> SOAP Body) in addition to the Acknowledgment Indication (in the SOAP Header)
>  or
> • a SOAP server Fault (in the SOAP Body) in addition to the Acknowledgment 
> Indication (in the SOAP Header). The Sending RMP and Producer expect either a 
> complete response or a SOAP Fault when using the Response RM-Reply Pattern; 
> these two allowed behaviors satisfy that expectation.
> ----------------------------------
> Since we don't save the response to the original request, the second option of 
> the fault is, I think,  the  only option.    Right?   (this could be a 1.1 
> change though.  I don't have the 1.0 spec handy right now0

It looks like you're getting that from the WS-Reliability 1.1 spec,
rather than WS-RM 1.1
WS-RM doesn't appear to say anything about responses to duplicates.

My own feeling is that responses should be cached and resent in response
to duplicate request messages - otherwise, WS-RM is pretty much useless
for request-response flows - but that does add potentially a lot of
overhead since all responses would need to be held until the sequence
was closed.  :-( Let me see what Metro does in this case, and also check
with one of the WS-RM people to see why they didn't address it in the
spec. It seems like it would have made sense to include response
acknowledgments to handle this case.

  - Dennis

View raw message