RE: Definition of Choreography

+1 to when Chris said ...
 
>>>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.
<<<

David
 
-----Original Message-----
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Saturday, October 19, 2002 6:53 AM
To: Paul Prescod
Cc: Burdett, David; Champion, Mike; www-ws-arch@w3.org
Subject: 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