Jacques,
All you have said is that some sequences in RosettaNet cannot be controlled
using receipts. You have not said what would actually happen if the
messages are not received in order. Is it possible that they are not
controlled with receipts because the order in which they are received does
not matter? Dan Weinreb's use case sounds particularly trivial since I
can't think of a good reason why it should matter if the advance shipping
notification is received before or after the invoice. Maybe there are
cases where it does matter but then I would ask why, if it matters, isn't
an acknowledgment prescribed?
Packet switching is a separate matter. The packet switching systems I am
aware of do not guarantee order. If you need to keep IP packets in order,
you put TCP on top of it. Also, if you need to keep the TCP messages in
order, you send them over the same path. Same for the HTTP messages. So it
seems to me that message ordering in the ebXML message service is there
strictly for the cases where the collaboration protocol doesn't force
ordering and the messages are being sent over SMTP. If those are important
cases, fine, but the example that Dan gave doesn't warrant the extra
complexity.
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
*************************************************************************************
Jacques Durand <JDurand@fs.fujitsu.com> on 11/30/2001 01:25:27 PM
To: Martin W Sachs/Watson/IBM@IBMUS, SHIMAMURA Masayoshi
<shima.masa@jp.fujitsu.com>
cc: ebxml-msg@lists.oasis-open.org
Subject: 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