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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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

Subject: Re: [ebxml-cppa] RE: [ebxml-msg] Comments on ebMS_v1.04c

   Date: Mon, 15 Oct 2001 08:43:37 -0700
   From: Arvola Chan <arvola@tibco.com>

   Under the QualityOfServiceInfo element, I would prefer to see the
   boolean attribute duplicateElimination renamed as reliableMessaging.

The reason for making this change in the first place was to try to
separate the various underlying elements of reliable messaging into
orthogonal dimensions.

The idea is that duplicateElimination is really orthogonal to

retry-and-ack	duplicate elimination	resulting semantics
no		no			best effort
no		yes			at most once (it might not arrive, it might arrive once)
yes		no			at least once (it might arrive once or more than once)
yes		yes			once and only once

This seems conceptually elegant.

Whether it has practical value depends on whether our customers might
really want all four of the possible resulting semantics.  It seems to
me that all four combinations reflect the needs of use cases that are,
at least, plausible.  Whether those use cases are compelling is a
judgement that I don't know how to make.  On the other hand, there
doesn't seem to be much downside to separating these orthogonal

From your later mail:

				       I just find the discussion
   on duplicateElimination in sections and 7.4 not very
   satisfactory. In particular, section 7.4 talks about a ReliableMessaging
   element that is not really described in the document.

I agree that the wording in could be improved.  In my opinion,
it would be better if talks about what duplicate elimination
means, in its own right, rather than being written entirely in terms
of the resulting semantics.

More important, what says currently is assuming that
retry-and-ack is turned on, whereas the whole reason (as far as I
remember it) for separating out duplicateElimination was so that
duplicateElimination could be used either with or without

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

Powered by eList eXpress LLC