Dan,
Thank you for the detailed explanation. One thing is certain: I was
looking at the problem as a message sender and you are looking at it as a
message recipient.
Is there any explicit requirement that can be expressed in the BPSS
instance document to say "these unacknowledged messages must be sent over a
transport that maintains order"?
What happens today (pre-ebXML) if those messages are sent over SMTP which,
if I understand it correctly, will not maintain order? TCP keeps the bytes
in each message in order but it can't keep the emails in order. HTTP will
itself maintain order if all the messages are sent over the same path.
Whoever is configuring the systems has to know not to use SMTP with such a
business process. Is there anything even with ebXML to flag that the CPA
must be written either to use message ordering or not to use SMTP?
Maybe I am being extravagent with business process implementation but my
comfort level is much higher if the business process is written to assure
ordering rather than having to keep an eye on what is going on across
multiple layers to assure that ordering is maintained.
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 05:38:01 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 13:44:17 -0500
From: "Martin W Sachs" <mwsachs@us.ibm.com>
Gimme a break, Dan! I didn't imply any of that.
Hmm. Perhaps I'm misunderstanding. It still seems to me that you are
implying that. It looks like we must be seeing things in a different
way, as if there's some tacit assumption that we're disagreeing on.
Let me try to say it more clearly in hopes of bringing out the
underlying disagreement, whatever it is.
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.
What if the BPSS is written in the most simple and straightforward
way, in which there are two BusinessTransactionActivities, one after
the other, connected by a Transition? Unless I am severely
misunderstanding the semantics of a BPSS, that means that the first
one has to happen before the second one. If you want to write a BPSS
that says "these things can happen in either order", you have to use a
Fork and a Join in order to express that. A Fork and a Join and all
the Transitions needed to hook them all up makes the BPSS more
complicated.
A classic reason for a business response to each message is precisely to
keep the messages in order.
From my point of view, this seems like reverse reasoning. You're
saying that we should always require business responses, in order to
keep the messages in order. Another way of looking at the same thing
is that you want to require business messages to call for responses,
even if there's no need for the response other than to keep the
messages in order, in order to compensate for the failure of the
underlying message system to be able to keep messages in order.
Rather than compensate for a failure in the underlying message system,
we could simply make the message system do it right, so that we don't
put the burden of ordering onto the business layer. Then business
messages that need no reply needn't artificially define a reply that
they have no business need for.
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.
Gee, I guess you and I look at this in a very different way. For me,
it seems extremely natural for a messaging system to deliver messages
in order. It's just like TCP delivering the bytes in order.
At the business level, it's easier to specify a collaboration pattern
in which things always happen in one order; it's more work to define
one in which certain things have to be in order but other things
don't, where some things are sequential and others are concurrent.
Without question, the BPSS ought to have that capability. But using
that capability is more complicated and more work than not using it.
I am looking at this from the point of view of a vendor of software
that executes business processes, understands how to interpret a BPSS
that it is given, and makes sure that in the execution of the process,
the BPSS for each conversation is being followed correctly. Now, what
happens if I am given a business process with two
BusinessTransactionActivities in a row, sequentially, and the first
one doesn't ask for a business response? At the receiving end, I am
trying to validate that the BPSS is being followed. If the messages
arrive out of order, my softare will compare the message traffic with
the BPSS definition and conclude that the sequence of messages that
it's seeing are in violation of the BPSS.
How would you deal with this? It seems to me that if the message
layer does not guarantee the ordering, there is simply no way to make
a collaboration defined by such a BPSS successful. Sooner or later
the messages will arrive in the wrong order and the user will get an
error message saying that the BPSS is violated.
So when you say "A classic reason for a business response to each
message is precisely to keep the messages in order", it sure sounds to
me as if you're saying that the BPSS I described simply should not be
allowed. It seems that you're saying that the definition of the
business process MUST put in a business reponse, in order to keep the
messages in order. (Or else the BPSS should have been written with
the fork and join.)
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.
I admit that this is a hypothetical business process, not one derived
from a real use case. But can we be sure that real use cases won't
ever include the pattern that I described above, and do we want to
make such a pattern illegal or inoperative?
Again, why would that business collaboration break if the messages were
received in the opposite order?
From my point of view: because I'm assuming that my software was
handed, by my users, a BPSS that has two sequential states in it, and
if they don't happen in the specified sequence, a BPSS violation will
be reported.
-- Dan