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

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

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