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

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

Shimamura

You said ...

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

This is not my recollection. In fact if you look at the DTD in version 0.8
of the spec you will see that SequenceNumber need not be present in a
Routing Header (see line 1268) which is defined as follows ...

<!ELEMENT RoutingHeader (SenderURI , ReceiverURI , ErrorURI , Timestamp ,
SequenceNumber? )>

Making SequenceNumber mandatory is something that we did not agree to do.

Also the current version of the spec uses sequence number so that the
recipient can detect duplicates. However, as Chris Ferris says is in his
email, this doesn't always work. Some additional situations which cause
problems are:
1. If one transport protocol is unavailable, e.g. HTTP, then you might want
to re-send using another protocol for some messages, for example SMTP. If
this is something that you want to do then it means that the HTTP and SMTP
protocols must share the same sequence number. However normally you might
want HTTP and SMTP to have separate sequence numbers because they are
operating separately. So there is a conflict.
2. If one MSH is accepting messages from multiple applications and the
acknowledgement from one message is not receieved because the destination is
down, then it unnecessarily blocks the sending of messages by the other
applications.

However I can see how preserving the sequence could be useful and important
to some applications. So in the current 0.91 version of the spec, the
definition of SequenceNumber is defined as being unique within Conversation
Id so that if you need to preserve message order then you can.

You also say ...

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

I agree, but what I have not seen is an analysis of the performance
implications of looking up a MessageId instead of using sequence number. To
help resolve this I've done a rough calculation where it is assumed that
each MessageId that arrives is checked against a random access database to
check for duplicates (see attached spreadsheet). This indicates that to
support a message arrival rate of 100,000 per hour you would need 12 100Gb
disks. Not much of a resource requirement in my view.

IMO, I think we need to see a reasonable Use Case that demonstrates that
adequate performance by looking up MessageIds in a database is not
realizable, before we require support of the sliding window method.

David





-----Original Message-----
From: SHIMAMURA Masayoshi [mailto:shima.masa@jp.fujitsu.com]
Sent: Wednesday, January 03, 2001 6:37 AM
To: Burdett, David
Cc: ebXML Transport (E-mail); IWASA Kazunori; Jacques Durand
Subject: Re: SequenceNumber [was:minutes 21-Dec-2000 tr&p con-call]


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