Re: [ebxml-msg] an assessment of the reliability of pulled messag es

[Doug Bunting <Doug.Bunting@Sun.COM>]

Jacques,

One specific point.  I think we can cover the rest on our call.

thanx,
	doug

On 10-Jan-05 20:19, Jacques Durand wrote:

...

>  Put another 
> way, the receiver RMP has to do something special with the pulled messages 
> and their acknowledgements because it cannot resend the messages: An 
> acknowledgement in this scenario may end caching of the response but does 
> not relate to any "retry loop" in that RMP.  
> (Note: Ending caching might  result in problems for later duplicate Pull requests.)
> 
> <JD> We can't really do cache-ending on criteria other than Expirationtime, because we still have to accommodate 
> the current behavior as required by WS_Reliability 1.1:
> - Caching is currently required for any SOAP Response, when duplicate elimination
> is used for the Request, regardless of whether the SOAP Request is a Pull or a regular message (RMP can't know!).  
> - So we already have a (RMP-level) resending mechanism for responses that is driven by duplicates of the Request
> (either a Pull or a business message), though that is not in any way controlled by an Ack for responses... 
> - But with duplicate elimination on sender RMP, all this would remain invisible to the MSH layer.
> So I do not see "Acks having a cache-ending semantics" a necessity even with your scenario.
> </JD>

The above is not correct.  Caching of responses is (unfortunately) optional 
in WS-Reliability 1.1.  We can impose a requirement that the WS-Reliability 
implementations used in support of an ebXML Messaging 3.0 deployment 
implement this option but that significantly narrows the field of "of the 
shelf" options.