Re: SequenceNumber and ordering

[jacques durand <jacques@savvion.com>]

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

More radically, I think RefToMessageId is great for linking Ack and Normal
messages, or
Normal and Error messages, but not Normal to Normal messages:
it should not be used for message ordering that has application semantics.
MessageID is a MSH concept, generated by the MSH
and normally not visible at application level. Requiring the application to
access it and use it
to order its messages is somehow contrived. 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.

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.



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