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

[bhaugen <linkage@interaccess.com>]

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