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

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

Mr. David Burdett, 

On Fri, 29 Dec 2000 08:08:32 -0800
"Burdett, David" <david.burdett@commerceone.com> wrote:
> 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

In previous TRP Meeting in Tokyo, we already discussed whether we should
provide following two QoS or not in Reliable Messaging:

  (a) Both message delivery and message order are guaranteed
  (b) Message delivery is guaranteed, but message order is not
      guaranteed

As the result of the discussion, we leaved only (a) and deleted (b) from
RM Phase 2 in the Delivery Matrix. Thus guarantee of message order is
one of main requirements of RM Phase 2 in the Delivery Matrix. Therefore
SequenceNumber should be mandatory element, it should not be optional.

If both the QoS (a) and (b) are needed, I'd like to propose that we
add a new attribute "messageOrder" to ReliableMessageInfo to support
both (a) and (b) formally.
    - messageOrder = "Guarantee"
        Message order is guaranteed by SlidingWindow and SequenceNumber.
    - messageOrder = "NotGuarantee"
        Message order is not guaranteed.

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

I think the high volume messaging is one of most important usage of
messaging middleware in B2B. I don't understand why we should exclude
such important usage from our targets.

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