OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

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

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

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


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
n:Van Huizen;Gordon
org:Progress Software;XML and Internet Technology
adr:;;14 Oak Park;Bedford;MA;01730;
title:Director, Product Management
fn:Gordon Van Huizen

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC