RE: Definition of Choreography

> -----Original Message-----
> From: Edwin Khodabakchian [mailto:[email protected]]
> Sent: Wednesday, October 16, 2002 8:41 PM
> To: 'David Orchard'; [email protected]
> Subject: RE: Definition of Choreography
> 

> Also who is the "client" of that specification? Meaning for example, 
> it is:  

I'm sure Dave knows far more about this than I do, but here's how I was
thinking about it:

I think of "Choreography" sortof like a policy, not a program.  For example,
we probably all have to deal with the travel policy police at our employers
:-(  .  Mine say that to travel anywhere, I need to get my manager's
approval on a form saying what/where/how much, I need to deal with
such-and-such an online travel service to make all plane, hotel, and car
reservations, I need to submit an expense report spreadsheet, I need to have
given my bank account information to the accountants, etc.  I think that's
something like a "choreography" -- it defines the logical interdependencies
and ordering relationships between the messages and services involved in
approving, boooking, and getting reimbursed for travel.  I can imagine it
being used sortof like a schema or WSDL document -- to describe the
high-level constraints on a compound web service in a way that various tools
could use to validate that an actual process meets the policy constraints,
to be the inputs into a tool that might prompt for details and generate an
actual workflow, to use by humans to understand how the system works ...

It's not a "program" (workflow, orchestration, business process execution,
whatever).  It doesn't define the instructions for HOW to jump through the
hoops, just what the hoops are.  To automate a "deal with the travel
bureaucracy" compound web service would be considerably more challenging,
and would clearly require a language at the level of BPEL4WS that would
define the mind-numbing sequence of tasks and the conditions under which one
"branch" or another is taken.

reason = prompt("why are you doing this to yourself?")
destination = prompt("where are you going")
departure = prompt("when do you leave")
return = prompt("when do you return")
tripId = TentativelyBookTravel(destination, departure, return)
estimatedCost = getCost(tripId)
if (estimatedCost > managerApprovalLimit)
   approved = getVPApproval(reason, estimatedCost)
else
   approved = getManagerApproval(reason, estimatedCost)
if (approved)
  confirmTrip(tripId)
else
  cancelTrip(tripId)

Of course, all this stuff executes in human time not machine time, and I'm
making it all up anyway :-)  But that's my understanding of the usage
scenarios for "choreography" vs "workflow/orchestration/BP execution"