Re: Hypermedia workflow

bhaugen <[email protected]>
Newsgroups gmane.comp.web.services.ws-arch
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.