RE: SequenceNumber [was:minutes 21-Dec-2000 tr&p con-call]

["Burdett, David" <david.burdett@commerceone.com>]

Nikola and Shimamura-san

I think that what we should do is the following:
1. Include sequence number as an optional element within the Routing Header
for use to ensure that a receiving MSH delivers messages to the application
in the correct sequence
2. Include the sliding window algorithm as a non-normative appendix as an
alternative method of doing duplicate detection.

I am somewhat reluctant to include the sliding window algorithm since it
then means that we are providing two ways of doing duplicate detection. I
also think that the sliding window method is an optimization that is useful
if you have a high volume of messages going over the same channel but I
don't think this will be the normal case in which ebXML messaging will be
used. If you have a high volume of messages between two parties then they
may well use some proprietary messaging software such as a queuing transport
like IBM's MQ Series or Progress Software's Sonic MQ.

Thoughts?

David
-----Original Message-----
From: Nikola Stojanovic [mailto:nhomest1@twcny.rr.com]
Sent: Friday, December 29, 2000 6:23 AM
To: ebXML Transport (E-mail)
Subject: Re: SequenceNumber [was:minutes 21-Dec-2000 tr&p con-call]


<SHIMAMURA Masayoshi>
...
I think message order is represented by MessageId and RefToMessageId as
following in your idea:
      1st Message [MessageId = a]
      2nd Message [MessageId = b, RefToMessageId = a]
      3rd Message [MessageId = c, RefToMessageId = b]
      4th Message [MessageId = d, RefToMessageId = c]

I don't think it is good idea. Please consider following case:
  The 1st Message includes main business payload. Other Messages (2nd to
  4th) includes addendum business payload to 1st Message's main business
  payload. At same time, the order of business payloads has a meaning in
  business. This is widely used business document structure (ex. license
  agreement). If all the messages have SequenceNumber, the structure can
  be represented correctly as following:
      1st Message [MessageId = a, SequenceNumber = 1]
      2nd Message [MessageId = b, RefToMessageId = a, SequenceNumber = 2]
      3rd Message [MessageId = c, RefToMessageId = a, SequenceNumber = 3]
      4th Message [MessageId = d, RefToMessageId = a, SequenceNumber = 4]

If you use MessageId and RefToMessageId instead of SequenceNumber, you can
not handle the structure above.
</SHIMAMURA Masayoshi>

I cannot see why. Also, it seems to me that using the first example one can
have something like this:

      1st Message [MessageId = a]
      2nd Message [MessageId = b, RefToMessageId = a]
      3rd Message [MessageId = c, RefToMessageId = a]
      4th Message [MessageId = d, RefToMessageId = b]
      5th Message [MessageId = e, RefToMessageId = c]

and I cannot see how SequenceNumber example can handle that.

But, maybe this is just speculating about requirements that don't exist (it
would take me a while to find a Use Case delivery matrix) for Phase 1.
AFAIR, SequenceNumber was introduced in order to do Reliable Messaging and
Temporal Ordering of messages wasn't part of it.

Regards,
Nikola