RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId

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

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

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Friday, November 30, 2001 7:28 AM
To: SHIMAMURA Masayoshi
Cc: ebxml-msg@lists.oasis-open.org
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