RE: SequenceNumber and ordering

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

David,

See my replies embedded below.

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:40:07 PM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   "'jacques durand'" <jacques@savvion.com>, Nikola Stojanovic
      <nhomest1@twcny.rr.com>, "ebXML Transport (E-mail)"
      <ebxml-transport@lists.ebxml.org>
Subject:  RE: SequenceNumber and ordering



Marty

The quote ...

"More radically, I think RefToMessageId is great for linking Ack and Normal
messages, or Normal and Error messages, but not Normal to Normal messages:"

... is not one I made. I agree that RefToMessageId is something that can
work on a response to any type of message.

MWS:  OK, if everyone agrees to the above statement, then the rest of the
question is probably moot.

Marty also said ...

>>>If the messaging service can make use of this field without altering its
semantics, fine, but this looks like a case where the messaging service is
taking over and modifying the semantics of a field which was intended for
business process use.<<<

I'm not sure I understand what you are saying, but RefToMessageId is in the
ebXML Message Header which is data that is strictly intended to be used by
the MSH. This means that the MSH must be able to use it for the purposes it
needs, for example, to identify that an earlier message has been received.

MWS:  That's not quite true.  I'm sure that the business process (or at
least
the application-support middleware that is outside of the MSH will use the
TPAId, ConversationID, and ActionId even though the MSH uses them for
routing.

MWS:  As long as the business process can insert the
RefToMessageId value for use by the other side, I have no problem.  However
if TRP has turned this into a quantity which is set and tested by the MSH
and
is intende for use only in MSH ACKs, then it has taken away the field from
the business
process and we need to add a separate field (in ApplicationHeaders?) so
that the business process can supply a past request ID for its own purpose.
I
suspect, however, that for normal messages, RefToMessageId is not used by
the MSH and could well be used by the business process for whatever purpose
it
has.

If an application can also make good use of it then that is fine. Similarly
if an application needs its own equivalent of a messageId, lets call it a
document id, then it needs to define its own equivalent of documentid and
RefToDocumentId and not rely on the one in the header.

David
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Friday, January 05, 2001 10:14 AM
To: Burdett, David
Cc: 'jacques durand'; Nikola Stojanovic; ebXML Transport (E-mail)
Subject: RE: SequenceNumber and ordering



"More radically, I think RefToMessageId is great for linking Ack and Normal
messages, or
Normal and Error messages, but not Normal to Normal messages:"

I beg to differ.  As originally conceived by the IBM Research team and
described in tpaML. RefToMessageId
(we called it past request ID) was specifically for linking normal to
normal messages.  A response message carries in the past request ID field,
the ID of the request message to which it refers.  If the messaging service
can make use of this field without altering its semantics, fine, but this
looks like a case where the messaging service is taking over and modifying
the semantics of a field which was intended for business process use.  If
the messaging service needs a construct with similar but not identical
semantics, please define a separate field for that purpose.

This is one more case where a service interface description would help to
eliminate confusion and misinterpretation.

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 12:40:52 PM

To:   "'jacques durand'" <jacques@savvion.com>, Nikola Stojanovic
      <nhomest1@twcny.rr.com>
cc:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
Subject:  RE: SequenceNumber and ordering



Jacques

See comments below.

David

-----Original Message-----
From: jacques durand [mailto:jacques@savvion.com]
Sent: Thursday, January 04, 2001 4:35 PM
To: Nikola Stojanovic
Cc: ebXML Transport (E-mail)
Subject: Re: SequenceNumber and ordering




Nikola Stojanovic wrote:

> <SHIMAMURA Masayoshi>
> ...
> (1) Guarantee of Message Order
> (2) Effective Duplication Check
>
> The MessageID element in MessageData can not realize the two functions
> above. Especially, there is no way to guarantee Message Order except for
> using SequenceNumber. Because current MS specification has not the
> blocking restriction. The Sender can send some messages without waiting
> for acknowledgement message. Thus when a communication error and retry
> sequence occurs, sent messages will reach the Receiver in invalid order.
> To correct the invalid order in the Receiver, the SequenceNumber must be
> included in each message.
> </SHIMAMURA Masayoshi>
>
> 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.

We had, in the Tokyo POC demo, a bad last minute experience with
RefToMessageId...
It was due to divergent vendor interpretations of its "optional" use for
Normal
messages,
where one vendor required it for sequencing, while the other did not, in a
standard message exchange.
(also, should RefToMessageId of a response message sent by A,
refer to the last message *received* by A, or to the previous message
*sent*
by
A?
Only the latter would amount to sequence numbers. )
<DB>It should be a received message. However the spec defines
RefToMessageId
as follows ...

>>>The RefToMessageId element has a cardinality of zero or one. When
present, it MUST contain the MessageId value of an earlier ebXML Message to
which this message relates. If there is no earlier related message, the
element MUST NOT be present.<<<

This is vague. It should say "... it MUST contain the MessageId value of an
earlier ebXML Message, **received by the MSH**, to which this message
relates ..."

</DB>

More radically, I think RefToMessageId is great for linking Ack and Normal
messages, or
Normal and Error messages, but not Normal to Normal messages:
<DB>One the main reasons for RetToMessageId is so that the sender of a
message *knows* that an earlier message they sent was received. For this
purpose the receipt of another Normal message is equally as effective as an
acknowledgement or an error.</DB>

it should not be used for message ordering that has application semantics.
<DB>It isn't except that a MSH can use it to determine that a message has
been delivered, inform the application that this has occurred, so that the
application then resends the message.</DB>

MessageID is a MSH concept, generated by the MSH
and normally not visible at application level.
<DB>I agree.</DB>

Requiring the application to
access it and use it
to order its messages is somehow contrived.
<DB>I'm not suggesting this.</DB>

 Message ordering that depends on
message content
(rather than on  timestamp) should rather be left to the  application
level,
and rely on app-level IDs, like  DocumentId.
<DB>I agree, but message ordering that is dependent on an application being
told by a MSH that an earlier message has been delivered is what I'm
suggesting.</DB>

In particular,  the MSH (unlike the application) cannot enforce a partial
message order like:

>       1st Message [MessageId = a]
>       2nd Message [MessageId = b, RefToMessageId = a]
>       3rd Message [MessageId = c, RefToMessageId = a]
>       4th Message [MessageId = d, RefToMessageId = b]
>       5th Message [MessageId = e, RefToMessageId = c]

as the MSH cannot do more than mapping this "message tree"
into a sequence when returning it to the app level, leaving to the app the
job
of
figuring the reference links.
I guess most of the time, a combination of conversation ID and document
label
is even sufficient for an app to identify the next message of an exchange,
like
in RosettaNet PIPs.

I tend to think that if supporting ordering at MSH level makes  sense, it
is
mostly for temporal ordering,
where  correcting the receiving order so that it reflects  the sending
order
is just a property of the "connection" (a QoS attribute),
as done for packets that can take different routes in a transport layer.
(note that "connection" may have business definition, e.g. a conversation).
In which case, like for packets, sequence numbers are quite effective and
simple
to use.
<DB>I agree with your last description of the main use of sequence
numbers.</DB>


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

I believe duplicate checks would require maintaining and searching a
possibly
large database of MessageIDs, on the receiver side.
Even if this one is indexed/ordered, the high rate of updates (add /
remove)
would shift the
overhead from search to maintenance of the index.
The same check over seq nbrs only requires searching over a limited number
of
intervals of integers. Less overhead, both space and time.

Regards,

Jacques Durand

>
>
> <SHIMAMURA Masayoshi>
> To realize (1)Guarantee of Message Order and (2)Effective Duplication
> Check, the SequenceNumber is obviously needed.
> </SHIMAMURA Masayoshi>
>
> See comments above.
>
> Regards,
> Nikola