[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
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