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 Fri, 21 Jan 2011 00:27:07 GMT
Ah, I think I see how response handling is supposed to work in WS-RM.
CreateSequence can optionally offer to create a separate sequence for
the opposite direction. I'd say the offer should always be configured in
policy when using a request-response MEP, and should always be accepted
by the destination. Then there are separate-but-equal sequences for the
two directions of message flow.

It looks like the Offer handling is in place in CXF, so responses should
automatically be resent if they're missed - I'll test this to see if it
works. That leaves the issue of what should be sent in response to a
duplicate request. I'll see what Metro does in this case.

  - Dennis

On 01/21/2011 11:51 AM, Dennis Sosnoski wrote:
> 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