- From: Burdett, David <david.burdett@commerceone.com>
- Date: Sun, 20 Oct 2002 18:14:08 -0700
- To: Paul Prescod <paul@prescod.net>, Christopher B Ferris <chrisfer@us.ibm.com>
- Cc: www-ws-arch@w3.org
Paul You said ... >>>I didn't say that we should all abandon business processes. I said that we should express those business processes in terms of preconditions and postconditions, not in terms of messsaging rituals.<<< I agree, with the proviso that the preconditions and post conditions must be associated with events and that those events are the sending of messages. David -----Original Message----- From: Paul Prescod [mailto:paul@prescod.net] Sent: Saturday, October 19, 2002 3:23 PM To: Christopher B Ferris Cc: www-ws-arch@w3.org Subject: Re: Definition of Choreography Christopher B Ferris wrote: > Paul, > >.... > > In your example, the waiter should have asked if the customer would prefer > their coffee before > the salad, or vice versa, before making such an assumption. It isn't > logical, but that isn't the point. We have a responsibility to be logical! If the two wanted to negotiate an ordering on the two events then they could and should have done it with pre-conditions and post-conditions. The pre-condition of getting the salad would be that the customer has coffee in front of them. The waiter knows this implicitly. He might walk up to the customer with a coffee and see that the customer already has one. "Where did you get that?" "Another waiter brought it for me." "Okay, then I'll bring the salad." They didn't go through a step-by-step ritual, but who cares? The precondition is fulfilled. Now let's bring this back to web services. The mysterious second waiter is equivalent to a third party service: perhaps some kind of intermediary or cooperating process. As long as the preconditions and postconditions are out in the open, and based on observable state, then the two original parties become expendable, which is important from a scalability and reliability point of view. > Consider these two different business models: > > - service at a fancy restaurant > - service at your local deli > > In the first case: ... > > In the second case: > > ... > > Both cases have the same business objective: the customer gets food. Christopher, I don't think you've understood my message. I didn't say that we should all abandon business processes. I said that we should express those business processes in terms of preconditions and postconditions, not in terms of messsaging rituals. We can say: "You must first win an election. Then take an oath. Then you may become president." Or we can be more flexible ("loose binding") and say: "You must have evidence that you have won an election and evidence that you have taken an oath in order to satisfy the preconditions of becoming the president." Other than ritual, there is probably no reason that the election must precede the oath. On the other hand, if the election DOES have to precede the oath, then we can make the evidence of having won the election a precodition of taking the oath. I'm not saying that the original business problem was irrelevant. I'm saying that a time-sequenced ritual is not the best way to solve the real, underlying business problem. If you want to enforce time-sequencing then you can even do that merely by redeclaring your ritual steps in terms of tokens. Another concrete example: * In order to get your food, you must present a receipt * In order to present a receipt, you must have ordered food. * In order to order food, it must be your turn. * In order for it to be your turn, you must have the next numbered ticket. * In order for you to have the next numbered ticket you must have a numbered ticket. * In order for you to have a numbered ticket you must have picked one up. * In order for you to have a numbered ticket, you must have picked one up. Do you agree that a business process is being enforced? In every case, the precondition is expressed in terms of what I have, not what state we are in the ordering ritual. This opens up a bunch of flexibility. Bob walks in and grabs the numbered ticket. He's busy so he gives $10 to Alice and asks her to do the next part of the process. He hands the ticket it to Alice. Alice times out (got a hot date) and hands it to Carol (with $5.00). Carol orders and gets a receipt. But she has no expertise in waiting for food so she hands it to Daryl. Daryl is notified that the food is ready (through his receipt number). He picks up the food and eats it. It turns out that the food was for Daryl all along. None of the other parties cared about it. By expressing the problem in terms of what you HAVE instead of who you ARE, and preconditions instead of communication history (ritual), I've massively improved the flexibility of the system and the scalability too. (only high volume places bother with customer numbers and ticket numbers) >.... > It may indeed be illogical, but who ever said that business was > necessarily logical? Business is > about relationships, not logic. You can enforce everything that matters to the business via preconditions and postconditions. If you want to be silly and enforce an order where it doesn't matter, you can do that by requiring the ticket produced by one step as the precondition of the next step. On the other hand, are you saying that you realize that using choreography is illogical but you think that there should be a W3C standard for it regardless? Paul Prescod
Received on Sunday, 20 October 2002 21:14:02 UTC