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

[Dan Weinreb <dlw@exceloncorp.com>]

   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