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

[Martin W Sachs <mwsachs@us.ibm.com>]

If a conversation really represents a single unit of business, then I would
expect that within a conversation, there would be at most a few tens of
messages.  However if some business process uses the conversation as an
open-ended session, then the number of messages could get very large and
some protocol that handles wrap of the sequence number would be needed.
Since the beginning and end of a conversation are defined by the business
process, there is nothing to stop someone for using it as an open-ended
session.

Once TRP starts to be concerned with how a conversation works rather than
just with passing the conversation identifier from sender to receiver, it
is starting to get outside its scope and is tiptoeing into the business
process domain.  I suggest limiting sequence numbers to whatever is needed
for reliable messaging and making it clear that that's what they are for.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



"Burdett, David" <david.burdett@commerceone.com> on 01/05/2001 02:47:03 AM

To:   SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>
cc:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>, IWASA
      Kazunori <iwasa@fs.fujitsu.com>, Jacques Durand <jacques@savvion.com>
Subject:  RE: SequenceNumber [was:minutes 21-Dec-2000 tr&p con-call]



Shimamura

I think that our thoughts are beginning to converge. I agree that making
sequence number unique within conversation id makes sense.

I have also read your paper, and think that we have two alternatives:
1. Your alternative where we have a separate messageOrderSemantics that
indicates that the sequence of arrival of messages within the conversation
MUST be preserved by a recipient.
2. Use the existence of the sequence number to imply that sequence must be
preserved. This would mean that the first message in a conversation would
have to have a sequence number and the omission of a sequence number later
would be an error. Similarly the presence of a sequence number when there
wasn't one on the first would also be an error.

I do think though that if we do have messageOrderSemantics.

I am also wondering if we need to worry about overflow if sequence number
is
going to be unique with Conversation Id. For example, if sequence has a
maximum value of 99,999,999 then effectively a conversation with a 100
million messages would, I think, in practice never occur.

Thoughts?

David

-----Original Message-----
From: SHIMAMURA Masayoshi [mailto:shima.masa@jp.fujitsu.com]
Sent: Thursday, January 04, 2001 12:56 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 Wed, 03 Jan 2001 12:05:59 -0800
"Burdett, David" <david.burdett@commerceone.com> wrote:
...
> 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.

The SequenceNumber is needed when DeliverySemantics is "OnceAndOnlyOnce".
So the DTD was defined as above, I think.

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

I agree to generation of SequenceNumber for each ConversationId. Thank
you for your suggestion. I hope you also add detailed description of
SequenceNumber and new attribute "messageOrderSemantics" of
ReliableMessagingInfo to the MS spec. I show my modification idea in
attached file.


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