RE: Definition of Choreography

I'm really glad to see this discussion, because much same questions have
been bothering me.  It is certainly clear that choreographed processes are
important for business use.  An example would be the back and forth,
possibly following a number of potential paths, involving purchase orders,
confirmations, invoices, etc necessary for one company to purchase something
from another.  However, it has been MUCHO less than clear to me what the
leverage is for doing this in a standardized way.  So what if my company
uses SAP workflow, another participant in the process an EAI system with a
different business process engine, and a third has Uncle Fred come in on the
weekends and figure out what the next message is supposed to be?

Common to all these situations is the unspoken assumption that the primary
mechanism for setting up these processes is written, negotiated agreements.
PDF files, Word documents, and so on that are based on agreements between
people.  I think that this is a VERY good assumption for us, at least for
the next few years and maybe for much longer.  If that is so, what benefit
does one get by using the SAME formalism for expressing the choreography?

Well, being able to change out tools more easily has come to mind in our
shop, but I don't think that's the driving factor for most people in this
space.  Ease and accuracy of communication with business partners?  Well,
maybe -- but if the written document is normative and the choreography
markup is something that a techie makes on the basis of that written
document (again, this is the norm I expect), how big is this advantage?
Decrease the cost of putting the process in place once the agreement is
made?  This one is a bit more plausible.  Basically, only one techie has to
get the implementation of the process correct, not a whole bunch.  Better
uniformity of implementation of the process?  Again, more plausible for the
same reason.  The translation to techie is happening once so minor
differences will have less chance to creep in.  Easier and cheaper to build
the tools used to implement the processes (like SAP workflow or whatever)?
Not an issue that we, as an end-user company understand very well.
Availability of cheap or shareware tools usable by small to medium sized
companies so they can play the game without spending big bucks on an SAP
system?  That could be a real winner, I think, if it works out that way --
although in that case I'm mystified by the push on the subject from
companies that make the expensive products.

Frankly I don't see these advantages as being worth the HUGE emphasis that
everybody seems to be putting on this subject, but I would be more than
happy to be proved wrong.  One way to do so would be to generate some use
cases that clearly demonstrate the advantages.  I don't think that the
ubiquitous travel agent use case really does so, at least not in a way that
I find very clear and compelling.  So what if the airline, the hotel, the
car rental company, the travel agent and the purchaser all view the process
differently or each sees a different aspect or subset of the process?  The
hotel gets a request and answers it.  Does the hotel have to know all
aspects of the process?  No, actually it probably shouldn't know.  In this
case I think only the travel agent has to know what's going on, and that
travel agent can model the choreography however best suits the
circumstances.

-----Original Message-----
From: Dave Hollander [mailto:dmh@contivo.com] 
Sent: Friday, October 18, 2002 10:21 AM
To: Burdett, David; 'Mark Baker'; Champion, Mike
Cc: www-ws-arch@w3.org
Subject: 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 14:11:25 UTC