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