RE: Definition of Choreography

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