Re: Comment on section 3.3.4, Messaging Service Spec v0-1

[Gordon van Huizen <gvanhuiz@progress.com>]

I think that there are two issues here and that they need to be
decoupled:

1) Whether or not the messaging service is to provide ebXML positive
acknowledgments or not. I'd prefer to see this called "MSAck",
"MessagingServiceAcknowledgement" or some such. "AtMostOnce" has a
number of additional connotations that don't apply here, and it really
blurs the line between what the transport and the message service.

2) Whether or not the underlying protocol is to employ its own QoS for
reliable messaging. This could certainly be dealt with in the TPA, as
previously discussed. Note that we're pushing QoS normalization issues
off to the TPA discussion if we do this (not that doing so would be
inappropriate).

WRT the reliability of the RM spec, I don't mean to discredit the work
that's been done. My point is that I believe that we as a group are not
clearly targeting the same scope for this work. If our goal is to
provide ExactlyOnce semantics over HTTP, we need to do a lot more
work--and be clear that this is our intention (the current naming of the
flag points out that we are not all thinking the same thing).

-gvh-



Jim Hughes wrote:
> 
> Rather than have an extended discussion now on the contents of the "RM
> Spec" (even if it isn't 'reliable', according to individual
> interpretations!), I think the proper conclusion to Change Request 137 is
> to have three values for the ReliableMessagingInfo element:
> 
> 1) "None" - meaning, ebXML semantics are silent
> 
> 2) "AtMostOnce" - meaning, refer to the "reliable messaging spec" for what
> the Sending MSH and Receiving MSH will do. Yes, there are overtones to the
> term "AtMostOnce", but as opposed to "SeeRMSpec", "AtMostOnce" is a better
> value, IMHO. I think we can require that all compliant MSHs must support
> this value for interoperability.
> 
> 3) "TPAdefined" - (or similar) meaning, through the TPA or some other
> means, the two MSHs will agree to use some underlying transport's
> reliability semantics, whether or not some kind of ACK is expected. Support
> of this value is obviously MSH-implementation dependent.
> 
> Comments?
> 
> Jim
begin:vcard 
n:Van Huizen;Gordon
tel;work:510-848-1988
x-mozilla-html:TRUE
url:http://www.sonicmq.com
org:Progress Software;XML and Internet Technology
adr:;;14 Oak Park;Bedford;MA;01730;
version:2.1
email;internet:gvh@progress.com
title:Director, Product Management
fn:Gordon Van Huizen
end:vcard