Title: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
Just adding my 2 cents on the need for message ordering at MSH level:
Coming from a BPM software vendor, I can definitely tell that the
definition of a receiving business process (or of a receiving app) would certainly be
more complex (if not broken), if one cannot assume a sequence order in some exchanges.
Just looking at RosettaNet PIPs of segment 3A (order entry), there are 7 PIPs over 10
where the same party receives a sequence of messages for which order cannot be controlled
using receipts.
I think this is one of these features that you want supported at messaging level,
just as packet switching still guarantees reordering of packets to the receiver.
The fact that the application controls the scope of ordering (conversation ID)
does not make this an application responsibility: it is just a contract with the MSH.
regards,
Jacques Durand
-----Original Message-----
From: Martin W Sachs [mailto:]
Sent: Friday, November 30, 2001 7:28 AM
To: SHIMAMURA Masayoshi
Cc:
Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
This is about the use case for message ordering in the quote from Dan
Weinreb's posting below.
Dan quotes Mike Rowley who said:
> Not quite. Within a single collaboration, it is sometimes important
that the
> messaging system not reverse the order of messages. The BPSS may
require, for
> example, that an Invoice be sent and then an Advanced Shipment Notice
(ASN),
> in that order. Neither of these have response messages so they may be
sent
> one right after the other. The code on the other side will be written
on the
> assumption that the ASN will never arrive before the Invoice, so if
the
> messaging system gets them out of order, it will break the
collaboration.
Someone, please explain why the collaboration will break if I receive the
advance shipment notice before the invoice. If that happens, I will know to
expect the invoice. It seems to me that these two messages are classic
cases for using email, in which case the order of receipt is unpredictable.
The code on the other side could issue a warning to its user if the advance
ship notice comes first but it shouldn't crash the collaboration. If the
collaboration protocol design really requires that the invoice be RECEIVED
before the advance shipment notice, then the collaboration protocol should
specify an acknowledgment to the invoice.
Maybe I am missing an important point in this use case but if I am right,
then I have to ask: why must we design for a broken use case?
Regards,
Marty
