[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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC