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

[SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>]

Mr. Nikola Stojanovic, 

On Wed, 27 Dec 2000 09:31:28 -0500
Nikola Stojanovic <nhomest1@twcny.rr.com> wrote:
...
> In addition to MessageID element in MessageData there is a RefToMessageId
> element as well. While using MessageID only for the purpose of temporal
> ordering of messages (sequencing being just one instance of it) is not
> enough, utilizing both MessageID and RefToMessageId can allow MS Handlers to
> do sequencing and much more. In that case SequenceNumber doesn't need to be
> included in each message.

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. In addition, processing to correct
invalid message order using MessageId and RefToMessageId in the Receiver
becomes more complex than processing to correct invalid message order using
SequenceNumber. Using SequenceNumber is more natural way than
using MessageId/RefToMessageId to correct invalid message order in the
Receiver.

I believe that the MessageId/RefToMessageId and SequenceNumber have
different function each other. Both are needed. We should not use
MessageId/RefToMessageId instead of SequenceNumber to guarantee message
order.

> It is not easy for me to understand a full meaning of "Effective Duplication
> Check", but I can't see a problem in using the approach explained in the
> current MS spec (0.9a) (again, without SequenceNumber).

Advantage of SequenceNumber:
    - The SequenceNumber is integer value. The MessageId is variable
      length string. Comparison of integer values can be done faster
      than comparison of variable length strings for duplication check.

Advantages of SlidingWindow with SequenceNumber:
    - The Receiver can know required maximum table size previously for
      duplication check, which hold received messages' SequenceNumbers.
      It is specified as WindowSize.
    - The Receiver can expect correct range of SequenceNumber. If a
      received message's SequenceNumber is out of range, the Receiver
      does not need to compare it with SequenceNumbers in the table for
      duplication check (since it is invalid message, the Receiver
      returns Error Message).
    
For more detail, please see page 16 to 19 in the latest RM spec v0-088
<http://lists.ebxml.org/archives/ebxml-transport/200011/pdf00006.pdf>.


Regards, 

--
SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>
TEL:+81-45-476-4590(ext.7128-4241)  FAX:+81-45-476-4726(ext.7128-6783)
Planning Dep., Strategic Planning Div., Software Group, FUJITSU LIMITED