[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC