Re: Proposed Draft Charter for Choreography WG

David Burdett wrote:

> It is not a real scenario but it is based on real scenarios.

Thanks for a detailed reply, that's what I expected.
Did any of the real scenarios approach the complexity
of the combined one, and in particular, were any of them
actually choreographed and automated according to
a choreography that included more than two participants?

This is a deep topic, and I wonder if people understand
the size and dimensions of the bite they propose to chew.

The dimensions include business semantics as well as
legal obligations.  It's not enough that you can technically
do something.

Assaf Arkin wrote:
> The choreography by itself does not represent a chain of
responsiblity.

Well, maybe not all by itself, but it is part of a legal framework
that all participants must agree to, one way or another.

As the ISO Open-EDI group discovered (and called Rule One),
you're not just exchanging data, you're making legal commitments.
For example, Purchase Orders are legal contracts.

I expect choreographies (or whatever rules of engagement evolve
for electronic business collaborations) to become legal contracts.
See UN/ECE's recommended Electronic Commerce Agreement
for offer-acceptance transactions:
http://www.unece.org/cefact/rec/rec31/rec31_2000_00tr257.pdf

Lawyers will be involved.  Getting agreement among three
parties is more than half again as difficult as getting agreement
among two parties.  Plus, whenever the "choregraphy" changes,
all parties must agree again, even if the part that changed
did not affect them.

I'm not claiming that no business situation will require
a three-party choreography, just that people should
think about what they're stepping in and see if there's
a simpler way to do it.  Decoupling, anybody?
Break it down into sets of two-party interactions
with coordinators as internal responsibilities
of parties that have dependent commitments
with multiple other parties?

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

Yeah, but most likely the buyer just wanted to track the shipment,
and so just needed a URI and a tracking number for a query parameter.
It's not at all clear that the carrier needed to be part of the same
"choreography" as the buyer and seller.

> 4. Following an externally defined document workflow choreography. In
EDI,
> document flows are defined in implementation guides.

As far as I can discover, the cases where EDI implementation guides
were actually implemented as automated choreographies are few
and far between.

> Hope this answers your questions.

It answered one question and raised a lot more.
As I suggested, this is deep territory.
I'm glad you and I will be involved in the UN/CEFACT
explorations of all these issues.  I hope that W3C
will take advantage of the years of relevant prior work
in that group, still continuing as we ponder here.

UN/CEFACT has specifications for technology-independent
electronic business processes, including a business ontology
which will be presented in UML, XML and RDF.

Plus they have thought through a lot of the legal issues.

I see a little interest here, but not much....?

Later,
Bob Haugen
ebXML Business Process Work Group.
UN/CEFACT eBTWG Business Collaboration Patterns Project
UN/CEFACT TMG Business Process Work Group

Received on Saturday, 9 November 2002 15:42:21 UTC