RE: Definition of Choreography

Inside or outside, it is the same. If I want to select a vendor for a 
given task, their choreography will 1) help me know if I am compatible
and 2) if the process meets my requirements

Inside, sharing may help me set up an ad-hoc process with another
division, outside with another partner.

I do think there is a significant difference between public and 
private processes, and I think we *should* be focused on public.
But public/private are not corporate boundaries--the boundary is
where the service developer wants it to be. 

I may implement a complex service with a public interface, but
the private interface uses serivces from 4 other companies.

I may implement a company HR system with public interface that is
only intended for use with other corporate systems.


daveh

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Thursday, October 17, 2002 7:30 PM
To: 'Mark Baker'; Champion, Mike
Cc: www-ws-arch@w3.org
Subject: 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

Received on Friday, 18 October 2002 11:27:02 UTC