- From: bhaugen <linkage@interaccess.com>
- Date: Sun, 22 Dec 2002 07:08:42 -0600
- To: www-ws-arch@w3.org
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 UTC