RE: Definition of Choreography

Edwin
 
I agree with your descriptions of the two problems that need to be solved.
 
I don't though, think of choreographies as the interface to a complex
service. Instead I think of them as "the sequence of messages exchanged
between two or more services in order to implement a (business) process".
Note that I said "sequence of messages". This means that you could have
different types of services with different WSDL definitions sending and
receiving those same messages in the same sequence. If you don't do it this
way, then you are stopping the re-use of a choreography as the choreography
will be tied to particular services.
 
I also think that this type of choreography needs to be defined using a
choreography language. This is diffferent from a business process language
which defines the sequence in which processes (in this context web services)
are excecuted - i.e. not messages.
 
I also don't think that public vs private processes is the best way of
thinking of this distinction. For example you could have an ERP system which
requires a pre-defined choreography that must be followed and can't be
changed if you want to interact with that ERP. This information may not be
"public" knowledge.
 
So really, I think of choreographies as constraints on what a business
process can do and something which business process languages should
recognize.

David

-----Original Message-----
From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
Sent: Thursday, October 17, 2002 7:02 PM
To: 'Burdett, David'; 'Mark Baker'; 'Champion, Mike'
Cc: www-ws-arch@w3.org
Subject: 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
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0217.html>  

-----Original Message----- 
From: Mark Baker [ mailto:distobj@acm.org <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.markbaker.ca>
http://www.idokorro.com <http://www.idokorro.com>