RE: Definition of Choreography

Mark

Two parts to this email:
1. Why you need to expose choreographies, and
2. External references in XML (from Paul's web site reference)

WHY YOU NEED TO EXPOSE CHOREOGRAPHIES
The basic reason is to achieve economies of scale. I think that there are
going to be two distinct use cases for web services:
1. To link applications together locally using (relatively) static
interfaces involving few (i.e. <100) interfaces. This is what is now being
called SODA or Service Oriented Development of Applications.
2. To link businesses together for eCommerce. Here there could be thousands
of web services involved but they are all, often doing the same thing, e.g.
order placement, invoice checking, etc.

For the first case you do not need to expose the choreographies you are
using as the scale of the problem is limited and well defined.

However for eCommerce, you do. Imagine that you have a really cool product
that you want to be sell and use eCommerce (by exchanging messages) with
thousands (or more customers), but before you can do that, you have to tweak
your implementation for each one as everyone does it differently because
there is no standardized published choreography being used. It just won't
happen, and it didn't happen with EDI, which is why EDI is only used widely
by the top few tiers of a supply chain.

David
-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org]
Sent: Friday, October 18, 2002 12:45 PM
To: Cutler, Roger (RogerCutler)
Cc: 'Dave Hollander'; Burdett, David; 'Mark Baker'; Champion, Mike;
www-ws-arch@w3.org
Subject: Re: Definition of Choreography


Another +1 from me.  Let's see some use cases that demonstrate why it's
important to expose choreographies.  Because as we've seen from these
specs, they're not exactly simple, and if you can accomplish something
without needing to agreeing to new stuff, that reduces coordination
costs (read; reduces cost of doing business).

I'm convinced that what Paul talks about here;

http://www.blogstream.com/pauls/1032521623/index_html

plus the implicit knowledge that an identifier exposes a common method
(be it GET, or prompt() per Mike's example), is the key to not needing
to expose the choreography in order to implement it, whether intra
or inter-corporate.

MB

On Fri, Oct 18, 2002 at 11:10:55AM -0700, Cutler, Roger (RogerCutler) wrote:
> 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.

-- 
Mark Baker, CTO, Idokorro Mobile.  Ottawa, Ontario, CANADA.
http://www.markbaker.ca             http://www.idokorro.com

Received on Friday, 18 October 2002 16:03:42 UTC