W3C home > Mailing lists > Public > www-ws-arch@w3.org > December 2002

Re: Hypermedia workflow

From: bhaugen <linkage@interaccess.com>
Date: Sun, 22 Dec 2002 07:08:42 -0600
To: www-ws-arch@w3.org
Message-id: <000e01c2a9bb$415a2340$b8eafea9@PC1>

Assaf Arkin wrote:
> > RosettaNet is an interesting case:
> > the configurations are defined by the consortium,
> > but all the interactions and coordination
> > are strictly two-parties-at-a-time.
>
> Actually, all the interactions are a simple as request-response
patterns,
> what ebXML calls business transactions. The patterns are two simple to
> include more than two parties. But if you've seen RosettaNet in action
you
> would realize that partners don't engage in a single PIP. PIP3A4 alone
is
> not sufficient to purchase products, you need notifications, RFQs,
> invoicing. Your real interaction is a set of steps that involves
multiple
> PIPs. Some of these interactions strictly involve two partners, while
some
> of these interactions involve more than two partners.

I agree that real business requires several coordinated PIPs, but:
There are no RosettaNet PIPs that involve more than two partners,
thus there are no multi-party RosettaNet interactions.
All coordination between PIPs must be accomplished internally
by one or more of the trading partners in a virtual multi-party
scenario.  More on this point below.

> The question is, how do you represent that. For most solutions in the
market
> you either use a proprietary language to string these simple
interactions
> together, or you just write a lot of code that delivers the same
result.
> That's proof that you do not need a multi-party choreography language
to
> make it work. I never claimed you do.

UN/CEFACT adopted the RosettaNet business transaction
model and added a Business Collaboration level to coordinate
many 2-party transactions in a standardized way.
ebXML BPSS was derived from this UN/CEFACT work.
Again, more below...

> In fact, my experience, just like yours, proves that any multi-party
> choreography can be broken down into a set of two-party interactions,
and
> any set of two-party interactions that is performed in the proper
order
> would result in a multi-party interaction.

Ok, good.

> But how do you represent that? Let's say you have two products in the
> market, both of which do multi-party interactions. One represents a
> multi-party choreography, while the other represents a set of
two-party
> interactions that happen to result in a multi-party choreography.
Which one
> would you say your customers would prefer to use?

I make a strict separation between internal and external spaces.
When I have external interactions (across administrative or company
boundaries), I like them to be as simple as possible.
Internally, where I have administrative control, I like a richer model
for coordination of external interactions.  But how I do that
is usually none of anybody else's business. Hope that's clear.

ebXML BPSS for example has the ability to represent
multi-party collaborations in one XML document shared
by many parties.  I have raised that as an issue with
the BPSS work group (as yet unresolved), because I
would avoid that like a legal plague.  BPSS documents
will become parts of legal contracts, since they embody
rules for business transactions.  So in many cases,
your question resolves to "how many parties do I want
to negotiate this legal contract with" and then "how many
parties do I want to renegotiate with every time it changes".

These issues have been discussed in UN/CEFACT
with some informal agreement that they are important,
but as far as I know, the only published opinion is in
the paper Tony Fletcher and I wrote which is *not*
accepted by everyone in UN/CEFACT (although
I haven't heard any disagreement on the
assertions about 2-party-interactions).
http://www.supplychainlinks.com/UNCEFACT-papers.htm

The paper also shows some ways to represent
multi-party coordination as an internal responsibility
using UN/CEFACT's methodology.

-Bob Haugen
Received on Sunday, 22 December 2002 08:11:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:11 GMT