Re: Definition of Choreography

Paul,

I'm afraid I'd have to disagree with your coffee/salad example. There are 
real, compelling,
and legitimate business cases for requiring the order of things. Some are 
cultural, and differ
widely across cultural boudaries. 

In your example, you seem to imply that the waiter was in the right. He 
fulfilled the customer's
requirements as he saw them, a coffee and a salad were delivered as 
requested. Yet, the
customer is unhappy with the service, and rightly so. Recall the adage of 
retail: "the customer
is always right".

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.

Consider these two different business models:

- service at a fancy restaurant
- service at your local deli

In the first case:
        - the diner is seated
        - their order is taken
        - the meal is prepared
        - the meal is delivered
        - the diner enjoys their meal
        - the check is presented
        - the diner pays for the meal
        - end process

In the second case:
        - the customer stands in line
        - the customer orders
        - the check is presented
        - the customer pays for her sandwich
        - the meal is prepared
        - the meal is delivered
        - the customer enjoys her sandwich
        - end process

Both cases have the same business objective: the customer gets food. Yet 
culturally, you would
never expect to pay up front for a meal at the Bay Tower Restaurant in 
Boston. Quelle faux pas!
Yet at your local deli, paying up front for your sandwich is not uncommon 
at all in my experience.
That's just the way of things.

The world is full of businesses that sometimes do not share the same 
business model, even though the
objectives may be the same.

Sometimes you pay before delivery, sometimes you pay afterwards. Sometimes 
it depends upon
who you are (like a well established and reliable customer who has a solid 
track record of paying
for their received goods and services), sometimes it doesn't (such as when 
it is a cultural thing).

Business has a need to communicate the order of their externally visible 
business processes to their 
prospective customers, and the customers have a need to understand and 
abide by the required 
protocol of their prospective business partners. In fact, sometimes the 
very decision to engage with
a business partner is predicated upon whether they share the same business 
model. Sometimes, 
a business will accede to the customer's preferred model, other times not. 
Sometimes the decision
is predicated upon whether the respective systems deployed within each are 
flexible enough to
accommodate the different process ordering. Remember, we're often dealing 
with older systems that 
simply may not have the flexibility to accept transactions out of 
sequence. 

It may indeed be illogical, but  who ever said that business was 
necessarily logical? Business is 
about relationships, not logic.

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624



Paul Prescod <paul@prescod.net>
Sent by: www-ws-arch-request@w3.org
10/19/2002 01:52 AM

To
"Burdett, David" <david.burdett@commerceone.com>
cc
"Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, www-ws-arch@w3.org
bcc

Subject
Re: Definition of Choreography




I know we're not supposed to argue about it but I'm going to try to get 
across how illogical I see this choreography stuff as being.

Burdett, David wrote:
>...
> 
> For the first case you do not need to expose the choreographies you are
> using as the scale of the problem is limited and well defined.
> 
> However for eCommerce, you do. Imagine that you have a really cool 
product
> that you want to be sell and use eCommerce (by exchanging messages) with
> thousands (or more customers), but before you can do that, you have to 
tweak
> your implementation for each one as everyone does it differently because
> there is no standardized published choreography being used. It just 
won't
> happen, and it didn't happen with EDI, which is why EDI is only used 
widely
> by the top few tiers of a supply chain.

David, please give a *concrete use case* of a service and a prose 
description of its associated choreography. I will show you how to 
transform it into a service that does not require choreography and is 
more scalable, flexible and reliable to boot. If I can do this for all 
cases, and even formalize the methodology, then would that be sufficient 
evidence that choreography is not necessary?

One should never impose an order of messages on a business partner. It 
is prefectly reasonable to make them meet certain preconditions. But 
there is no reason to know or care what order of messages got them to 
the state where they meet your preconditions.

Customer: "Garcon, your service was terrible."
Waiter: "You asked for a coffee and a salad. I brought them to you."
Customer: "No, I asked for a salad and a coffee. But you brought me a 
coffee and THEN a salad."

This is the choreography approach. The customer had in mind a 
"gotCoffee" state and a "gotSalad" state and set up a transition between 
them. But there was no reason to enforce an ordering on those 
operations. The business rule was: "Customer needs salad and coffee." 
That can be expressed in WXS, Schematron, RELAX or DAML.

Okay, sometimes the business rule _implies_ an ordering. You don't pay 
for the meal until you've got your check. But that can be expressed as a 
business rule with a slight change in the protocol. The business rule 
can be: "When you pay you must also submit the check." Once again, that 
can be expressed in any of the schema languages.

Tim Bray says that Web Services are in danger of having more 
specifications than running applications. Like UDDI, this choreography 
stuff is in danger of becoming a solution looking for a problem. I 
encourage you to have the courage to say NO!

  Paul Prescod