OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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


You make a good point, we need to include the ability to wrap sequence
numbers as Shimamura has suggested.


-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Friday, January 05, 2001 7:41 AM
To: Burdett, David
Cc: SHIMAMURA Masayoshi; ebXML Transport (E-mail); IWASA Kazunori;
Jacques Durand
Subject: RE: SequenceNumber [was:minutes 21-Dec-2000 tr&p con-call]

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

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.



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]


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



-----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
> 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
> to some applications. So in the current 0.91 version of the spec, the
> definition of SequenceNumber is defined as being unique within
> 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.


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC