MHonArc v2.5.0b2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ebxml-msg] an assessment of the reliability of pulled messag es
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]