- From: Paul Prescod <paul@prescod.net>
- Date: Sat, 19 Oct 2002 15:56:39 -0700
- To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
- CC: www-ws-arch@w3.org
Champion, Mike wrote: > >... > > Hmm ... in the absurdly hypothetical situation where I come into a > restaurant and let my Bluetooth or WiFi-enabled PDA deal with an automated > waiter via SOAP messages, I would disagree. I might want water and salad, > then a a main course with wine, and then dessert with coffee. I for one > would be highly annoyed if dinner started with dessert and wine, then I got > salad and coffee, and ended with a main course and water. Let's not get too obsessed with the restaurant example. The point is that if it is a precondition of the desert that you've already had a meal then it would be very simple to express that by simply giving you a "had-a-meal" token which you present when you ask for desert. If you got one from your best friend who had a meal yesterday, then (from a business sense) that's fine, no matter what the social custom is. If there is a business problem that cannot be solved _conveinently_ in this way, then we can easily end the conversation with a single a use case. > ... > Tim has a point, and to pick up another of Tim's mantras, I think we should > be focussed on doing the "minimum required to declare victory" here. Business rules as preconditions and postconditions of operations is the MRTDV. And it is a *subset* of what you need to do in order to do choreogaphy. Choreography is preconditions + postconditions + temporal constraints on how you achieve them. All I'm saying is that we can throw away the last factor. In the rare case where it is really necessary (haven't heard a use case) it can be easily expressed in terms of the first two. Paul Prescod
Received on Saturday, 19 October 2002 18:57:18 UTC