Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4D38D2DB.5060406@sosnoski.com>
Date: Fri, 21 Jan 2011 13:27:07 +1300
From: Dennis Sosnoski <dms@sosnoski.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.1.11) Gecko/20100714 SUSE/3.0.6 Thunderbird/3.0.6
MIME-Version: 1.0
To: dev@cxf.apache.org
Subject: Re: Postponing or blocking message delivery from interceptor
References: <4D36BBFA.4030208@sosnoski.com>
 <201101191419.43735.dkulp@apache.org> <4D37E921.6010303@sosnoski.com>
 <201101201657.12764.dkulp@apache.org> <4D38BC6F.8080905@sosnoski.com>
In-Reply-To: <4D38BC6F.8080905@sosnoski.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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