RE: Definition of Choreography

David,
 
It seems that what you are sharing is the public interface of your
service/process. In the example described in [1], you are sharing that
the seller exposes a service that understands Order and ChangeOrder
messages and also that Change Order only makes sense after Order.
 
What you are not sharing is what happens when you get an Order (our
private implementation of this service): that private implementation
could be entirely manual or completely automated. It could itself
include asynchronous interactions with legacy mainframe application,
batch processing etc..
 
There seems to be 2 problems: 
[Problem #1] How do you describe the interface of a complex service such
as the seller service described in one where a client needs to send and
receive multiple message from the service to get its result.
 
[Problem #2] How do you code, execute and run the back end application
that implements the public protocol implemented using problem #1.
 
Problem #2 is about control logic and requires a programming language.
That programming language can be expressed in XML or a script, that is
irrelevant. Standardizing that language will only offer portability
between the workflow engines that execute that language, it will *not*
increase interoperability.
 
Problem #1 can be solved in various ways: 
- Extend WSDL so that it not only defines the port types but also the
public protocols defined 
  between the port types.
 
- "bake" the public protocol into the interface definition of the
service. In the example described in [1]
  this option would be implemented by having the Order operation return
the uri of the ChangeOrder
  operation forcing the Order to be invoked before the change order.
[Paul Prescod posted a couple 
  of email on the merit of that approach]
 
- Coming up with a low tech approach, where the protocol is only
available through a documentation:
  developers have to read the documentation to use the service correctly
and have to handle exceptions
  when they don't (JavaDoc ++ for web services).
 
There are probably many more ways to address this to.
 
 
By choreography, are we trying to solve problem #1 or problem #2?
 
Edwin
 
 
 

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
Behalf Of Burdett, David
Sent: Thursday, October 17, 2002 6: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