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 org.apache.cxf.ws.rm.DestinationSequence), 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 > (http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01-e1.html). > 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 > >
