Re: [ebxml-msg] Groups - Weekly Call added

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

Jacques,

Your summary is based upon the arguments you put forward in your most 
recent email.  Please see below.

On 12-Jan-05 09:26, Jacques Durand wrote:
> A summary of my assessment of the reliability of synchronous pulled 
> messages:
> 
> - we all agree on the fact that the pulled message must be sent reliably 
> (that is a progress...), meaning an RMP Ack be sent back.

Where we disagree here is about the need for special handling of that RMP 
Ack of a pulled message.  For a "standard" RMP, getting an Ack of a message 
it did not explicitly send is just noise.  Such an Ack would be ignored or 
(possibly) result in an error.  To make this Ack at all useful, the RMP 
must be made aware of the message identifier of the reliable message inside 
the Pull response.  This is true whenever we acknowledge the content of 
Pull responses.  That is, both scenarios we have been discussing require 
this special handling in the RMP.

The closest we can get to "normal" use of an acknowledgement for a Pull 
response would be to use the metaphor of a bundled reliable message with 
the RMP-level acknowledgement to the Pull request.  However, WS-Reliability 
1.1 defines such bundling only when using the Callback Reply pattern (as if 
the Pull request was sent using that pattern).

> - if we want to enable some resending behavior I personally favor doing 
> this via the RMP rather than the MSH (we already get that for free).

It is not quite for free, as I mentioned in my previous email.  The caching 
of responses is optional in WS-Reliability 1.1.

> - if we want the possibility for the MSH to keep and recycle again for a 
> later Pull a failed pulled message, this is fine but we don't need to 
> specify this: we can leave it as an implementation enhancement (does not 
> affect interoperability). The other way to do this - making a Pull 
> idempotent by keeping a pulled message in head of queue until 
> acknowledged - introduces complications.

One scenario introduces complications in the MSH another in the RMP.  I 
suggested in my longer email that the idempotent case (complications in the 
MSH) simply extends the use of the queue necessary for providing the 
"submit" behaviour for the consumer application.  The alternative you 
propose complicates the RMP and reduces the chance of using a standard RMP 
component.

> - I would favor an integration that requires the least [implementation] 
> enhancement on the RMP behavior as specified today.

I think that means you prefer the idempotent option because it does not 
require response caching within the receiver RMP.  Your strongest argument 
in favour of that slightly more complicated RMP implementation is 
scalability improvements such as parallel (or pipelined) Pulls.

> Regards,
> 
> Jacques

...

thanx,
	doug