FW: multiparty (was) Fwd: Re: message routing

[Cory Casanave <cory-c@enterprise-component.com>]

In the BPSS a multi-party collaboration is supported as a composition of
binary collaborations.  Any party that collaborates in more than one binary
collaboration can have transitions <<between business transactions in these
binary collaborations>> which enforce the multi-party collaboration
semantics.  This is slightly different than the "arbitrary" multi-party
collaboration of UMM in one sense.  In the arbitrary multi-party
collaboration conditions can be expressed on party-"A" based on a business
transaction between party-"B" and party-"C".  While this may make a nice
picture it is clearly not a contract that party "A" has the knowledge or
responsibility to enforce and should not be allowed (the collaboration
between "B" and "C" are not visible to "A" so they can not constrain "A").

Any "legal" multi-party collaboration can be directly mapped between the UMM
multi-party collaboration and the BPSS multi-party collaboration expressed
as a synthesis of binary collaborations and the associated transitions
within the business partner roles.  No one role needs to be the "hub" or
coordinator, any party that participates in more than one binary
collaboration is, essentially, a hub.  The BPSS structure also clearly
identifies a particular business partner as being responsible for a
particular control constraint.  It does no good to say "this is what should
happen" without saying who is responsible for making it happen.  Think about
this as a set of independent parties who do "choreographed" things based
only on when something happens to them.  No "global knowledge" or "global
control" of the process exists or should be required - this lack of a global
controller is essential to real "B2B" business processes.

The issues of backout or undo must be part of the process choreography.
Anything beyond a single business transaction is done once it is done - this
fits with reality as we know it (the world does not "abort").  If you have
made an airline reservation the airline expects you to buy a ticket or
cancel the reservation - "canceling" or "going forward" are not that
different from a process modeling point of view and the business semantics
of that process will reflect when resources (inventory) are or are not
committed.  (We all know how the airlines solved this, just overbook!.

In the given example it is the travel agent that is calling the shots and
would be the "hub" of doing and undoing things using the protocols of the
airline, hotel & rental car.  This is as it should be because the contract
of interaction between the travel agent and the airline should not involve
the other parties.  Each of the binary contracts of interest will probably
be developed by independent parties in independent companies or standards
bodies and are only integrated by the travel agent.

Regards,
Cory Casanave
Data Access Technologies
www.enterprise-component.com

-----Original Message-----
From: bhaugen [mailto:linkage@interaccess.com]
Sent: Thursday, July 26, 2001 2:52 PM
To: ebxml-cppa@lists.oasis-open.org
Cc: ebxml-bp@lists.ebxml.org
Subject: Re: multiparty (was) Fwd: Re: message routing


From: Collier, Timothy R:
> You problem you get into with the automatic decomposition of multi party
> collaboration into multiple two party collaborations is the control issue.
> For example, in the popular travel itinerary scenario, you could break the
> interchanges down into
> traveler<->travel agent,
> travel agent<->airline,
> travel agent<-> hotel,
> travel agent<-> rental car
>
> But the problem with this is then the airline, hotel, and rental car
company
> can only assume that they are obliged to provide the service they offered
> and they must commit the changes immediately.  Later, if things change,
they
> must provide and undo/cancel.  This may be appropriate for many/most
> situations, but some businesses may have a problem with the churn of their
> inventory caused by this (not even getting into the malicious use of
this).
> If a multi-party interaction were possible then, the permanent changes
would
> not be applied until all of the participants agreed.

Great example, thanks!

Slight clarification:  I wouldn't try automatically decompose anything
at this stage of my understanding.  Or maybe ever.  Plus, decomposition
into dialogs does not mean "no coordination of the dialogs".

In this example, I think the travel agent is the 'hub' as Todd Boyle
suggested.  In other words, the travel agent is the controller, and
must make the decision of whether the contract with the traveler
is commited or not.

In other words, this is a set of coordinated dialogs as you outlined
it above.  Whether the airline, hotel and rental car companies
commit immediately or leave everything in a 'proposal' state
until a confirmation from the travel agent is up to them.
But I do not see (in this example) where there would be any
side conversations between airline, hotel and rental car company.

Do you have a better solution for this scenario where
everybody talks to everybody else?

Thanks,
Bob Haugen



------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org