[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
Gimme a break, Dan! I didn't imply any of that. No, we shouldn't set constraints like that on the BPSS. We could't do it even if we wanted to. On the other hand, we have to be careful about heaping complexity on top of complexity to support use cases that aren't realistic. It is not reasonable, in my mind, to define a business process that emits two messages that have no responses and expect them to be always received in the order in which they were issued. Your particular use case only says that the messages have to be sent in a particular order. You did not say anything to support the conviction that they have to be received in the same order. I cannot imagine any reason why it would matter what order they are received in. A classic reason for a business response to each message is precisely to keep the messages in order. Further, your example of using the fork or join to deal with the ordering is exactly correct and sounds to me a lot simpler than loading the messaging service with the ordering function per conversation. In fact, for this case, it is even simpler. If the shipping notice arrives first, post a reminder that the invoice is expected. You surely aren't thinking that the correct ordering means that I must pay before the shipment arrives. By the way, if that were the case, the payment would be the acknowledgment that maintains order since the supplier would probably not ship until it received payment. Please check the actual definition of that business process to see if there any requirement that those two messages be received in the order in which they were sent. If so, that definition ought contain a caveat that a messaging system be used that keeps them in order. Again, why would that business collaboration break if the messages were received in the opposite order? 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 ************************************************************************************* Dan Weinreb <dlw@exceloncorp.com> on 11/30/2001 12:48:44 PM Please respond to "Dan Weinreb" <dlw@exceloncorp.com> To: Martin W Sachs/Watson/IBM@IBMUS cc: shima.masa@jp.fujitsu.com, ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId Date: Fri, 30 Nov 2001 10:28:03 -0500 From: Martin W Sachs <mwsachs@us.ibm.com> This is about the use case for message ordering in the quote from Dan Weinreb's posting below. ... 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? It seems to me that what you're saying is that there must be a restriction on all BPSS's, saying that there SHALL NOT be a business transaction in which the BPSS has two states, one following another, in which the first one receives a message for which there is no business reply, and the second one receives a message. You seem to be proposing that the MS protocol should have no ability to do message-ordering, and that the MS team should tell the BPSS team that this is *their* problem, and they should outlaw all BPSS's that might create the need for ordering in the MS. So if party A wants to send two messages to party B, and there is no need for business responses to these messages, then when A and B get together to agree on how they're going to be do business, they must either (a) introduce a business response that would otherwise not be necessary in order to meet this requirement, or (b) write the BPSS with a split(fork)/join so that it explicitly doesn't depend on the order. That doesn't seem like a constraint that we ought to force onto the BPSS. -- Dan
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC