RE: Definition of Choreography

David,
 
I *very* much agree on your point where the coordination of message
exchanges is different from the coordination of activities (which is
what workflow engine do) but this is not easy to explain.
 
Regarding public versus private, I was *not* talking about company
boundaries but component/service boundary. The public face of an ERP
system is the information you need to know about that system to
integrate it into your application (even if the application that is
integrating the functionality lives within your corporation). On the
other hand, the private implementation refers to how SAP delivers the
service. 
 
Separating the 2 faces is important because you do not want to overwhelm
the application developer who is doing the integration with the details
of how SAP processes order. Also you want to be able to change the
internals of SAP without having to update all the applications that
integrate to SAP. In the Java world, an Interface is the public face of
a component, a class is the private implementation.
 
If you think that within that context, public/private separation is not
the right dicothomy, I am open to any other suggestion but I believe
that we need to make sure that there is a very clear understanding of
the problem we are solving and the value that a choreography spec will
deliver: will it increase interoperability between business processes or
make the execution of business processes more portable or both.
 
Best,
 
Edwin
 
 

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

-----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