RE: Definition of Choreography

Mark

You said ... Why would I ever need to *share* a description with anybody?

If you are inside your own business you don't. But choreographies can go
between businesses, in which case you definitely do - see [1].

Both sides **need** to know exactly what choreography they are following
otherwise you don't get interoperability. For example we have identified 14
different choreographies that can be used to place an order. Without a) a
precise definition of the choreography that is actually going to be used,
and b) a shared understanding of that choreography by both ends, it just
won't work.

... or am I missing something ...

Regards

David
[1] http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0217.html

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org]
Sent: Thursday, October 17, 2002 6:15 PM
To: Champion, Mike
Cc: www-ws-arch@w3.org
Subject: Re: Definition of Choreography



On second thought, I'd like to focus on this part of your response,
Mike;

On Wed, Oct 16, 2002 at 09:50:12PM -0400, Champion, Mike wrote:
> 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)

This is a good example.  And one could certainly specify a language for
describing such a flow of operations.  But why is a *standardized*
language required?  Why would I ever need to *share* a description with
anybody?

As I see it, that flow (minus conditions, which are encapsulated within
the service) can be observed at runtime, so doesn't need to be specified
earlier, at least for interop reasons.  So I invoke "prompt()" on the
first service, which returns "why are you doing this to yourself?",
which I answer by invoking "answer('because I feel like it')".  The
response to that invocation is then another question, or perhaps a
pointer to the next service which I invoke prompt() on, etc, etc..

Behind the scenes, I could certainly be using some description language
to drive this flow.  But again, why does it matter if it's standardized
or not?  The only reason I could think of, is because we're trying to
enable somebody to reuse their rules with different tools.  But that
seems quite different than the motivation I've seen for some of the
choreography specs out there.  For example, all of them integrate with
WSDL, which suggests that choreography is part of the interface, not
just the implementation.

Can anybody shed some light on this?

MB
-- 
Mark Baker, CTO, Idokorro Mobile.  Ottawa, Ontario, CANADA.
http://www.markbaker.ca             http://www.idokorro.com