RE: Proposed Draft Charter for Choreography WG

Bob

It is not a real scenario but it is based on real scenarios. I included
specifics about countries and types of participants to make it less
theoretical, more real and hopefully more understandable. I also excluded
exception handling in order to simplify it, although I would suggest that we
include additional messages to support exception handling if this use case
is carried forward.

Some of the key parts which are real include the following:
1. Using a third party to collect and deliver goods where the
collection/delivery is paid for by the buyer (not the seller), e.g the auto
industry. This is important to them as:
  a) The auto manufacturers are big companies - they can negotiate bigger
discounts and therefore reduce the cost of goods sold
  b) The auto manufactures care very much when goods are delivered in order
to realize just-in-time delivery. Paying for delivery when it makes sense
provides them with more influence and control than dealing indirectly
through the supplier, especially smaller remote suppliers. This does not
mean that they always pay for delivery as some, especially the bigger
suppliers, can meet the delivery timetables that the auto manufacturers
require.
2. International delivery - I suppose this is obvious. However this actually
has other related consequences because the conent of the actual documents
can vary depending on the business context (e.g. geographic region) and
industry. This means that there is a requirement to allow external
choreography definitions to be defined in a way that is independent of the
payload.
3. Choreographies involving more than two parties. Again this is pretty
obvious. Assaf also just provided another use case where a buyer would want
to deal directly with the shipper once the goods had been shipped rather
than via the merchant/seller. The buyer needs to know this in order to
interact correctly with all the different parties involved.
4. Following an externally defined document workflow choreography. In EDI,
document flows are defined in implementation guides. However many of the EDI
guides define the document flows differently (as well as define the
documents differently) as it was left to each industry to develop them, and
sometimes each "big" user produced their own verion as well. Although this
approach where a big company dictates the rules is still going on, the
problem is recognized within organizations such as UN/CEFACT, that this is
barrier to widespread eCommerce and there is a strong desire to avoid making
the same mistakes in the future by providing mechanisms for standardizing
choreographies. Even if international (or even national) standardization of
these choreographies does not succeed, I am sure that some big companies
will still want to dictate the choreographies that are used (as Walmart did
recently with all its suppliers using EDI). So the problem of constraining
an internal business process to the demands of an externally defined
choreography is still real.

Hope this answers your questions.

David 

-----Original Message-----
From: bhaugen [mailto:linkage@interaccess.com]
Sent: Friday, November 08, 2002 4:44 AM
To: www-ws-arch@w3.org
Subject: RE: Proposed Draft Charter for Choreography WG



> An online merchant would be a classical example.

> > The business use case David Burdett forwarded shows this
> > relatively clearly: The three companies and their tools need to know
> > more than "just" the separate interfaces to the other companies.
>
> It would be good to know if that use case,
> in that exact form, has been used in real
> business operations by real companies.

My question was about the particular use case
David Burdett forwarded.  It seemed very particular,
as if it was a real scenario that had been used
by real companies.

I wondered if that was the case, or if it was
hypothetical either in whole or in part?

I'm not asking for the actual company names,
although if it's real, it would be interesting
to know how commonly the pattern is used.

If it's hypothetical, followup questions are not
as interesting.

If the followup questions get too detailed for this list,
I'll take them offline with whoever is interested.

-Bob Haugen

Received on Saturday, 9 November 2002 12:18:07 UTC