RE: Hypermedia workflow

To both Miles and Bob,

You raise a very valid point. You both point out to the fact that users want
to see multi-party choreographies being described, and you both point out
that there are legality issues.

First, to answer Miles' point, I was referring specifically to
point-to-point interactions (RosettaNet and what I've seen in ebXML). But
you are perfectly right, multi-party interactions that use a
publish/subscribe patterns are not easily transformed into two-party
interactions. This was an over simplification on my part that ignored a very
valid use case.

When I discuss multi-party interactions I refer to different participants
and not necessarily different business partners. What I want to be able to
show is how multiple parties (or participants) that have loosely coupled
services running at each end interact with each other.

In some cases these are different companies with their own agenda, and
getting everybody to agree may pose a problem. In other cases these are
different entities within the same company, reaching agreement is not a
problem, but they are still loosely coupled services. In some cases this is
a company and it's service providers and there is no need to reach an
agreement each and every time.

Look at a typical scenario of buying a product from eBay, paying through
PayPal and having FexEd deliver it. This is a multi-party choreography: a
buyer, a seller, a market place, a clearing house, and a shipper. There is
no costly setup process involved in getting everybody to agree. The
choreography is known in advance and every time I buy a product in that
manner I engage in a new instance of the choreography.

Details such as the product bought, the time to deliver, the actual carrier
used (FedEx or PayPal) the clearinghouse (PayPal or Visa) change, but the
choreography remains the same. I think that is a valid use case for a
multi-party choreography that is reusable.

Another example is getting two companies to sign a contract. Say I want to
sell and expensive piece of software to a customer. I have seen the process
of signing such a contract take over a year as every detail is checked and
double checked, with the usual delays caused by the need to refine the
language, haggle the price, or people going on vacation.

Yet, whether it takes two weeks or ten months, the details are checked or
double checked, the choreography is always the same. It is perfectly
reusable in multiple instances, and as Bob pointed out some of these
instances can take a long period of time.

And it is also a multi-party choreography. Not only would the vendor and
customer interact with each other, and with their lawyer, but the lawyer
would be talking to each other. My customer talks to me, but their lawyer
talks directly to my lawyer. And they want to know how to contact my lawyer,
that I have given the lawyer all the details before they contact the lawyer
directly, and that the lawyer will report back to me.

There is a setup involved, when I first hire the lawyer and when they first
hire their lawyer. But for the purpose of the choreogaphy between the two
companies and their laywers, there is no setup cost. Everybody agrees to
participate in that choreogaphy, you just have to start it and it works.

The last example is one that involves multiple departments in the same
organization. There is some governing entity that ensures they will all
reach agreement. From the business unit leader to the director/VP all the
way up to the CEO. Yes, they are all part of the same business entity as far
as NASDAQ is concerned, but internally the company is divided into smaller
units that are somewhat independent of each other. Their services are
loosely coupled and that would translate into loosely coupled Web services.

This is not a justification for orchestration. Orchestration is when you
introduce yet another party to the mix, a new business process, that has to
interact with the existing parties (e.g a product manager, a project
sponsor). Choreography is there when their interaction produces a business
result and does not require any other party to coordinate the interaction.
Think how HR, finance and legal interact with each other when a new employee
joins. That's a multi-party choreography.

arkin


> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of bhaugen
> Sent: Sunday, December 22, 2002 5:09 AM
> To: www-ws-arch@w3.org
> Subject: Re: Hypermedia workflow
>
>
>
> 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 15:35:55 UTC