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

[Philip Goatly <philip.goatly@bolero.net>]

Hi Folks,

      I don't think sequences of 'messages' is the answer but the 'state' of
the transaction which can only be completed
when all relevant states are set to 'true'

For example a trucker can only pick up goods at the port if the Custoems
authority has cleared the Goods and also the goods are unloaded from the
ship. So the 'Customs Clearing Process' must be in a 'Cleared' State AND the
'Unloading Process' must be in an 'Unloaded' state and both these process
states are preconditions for the 'Trucker Collection Process'

This is why UMM is very interested not only in collaborations but the
Activity States as well.

Cheers, Phil
----- Original Message -----
From: "bhaugen" <linkage@interaccess.com>
To: <ebxml-cppa@lists.oasis-open.org>
Cc: <ebxml-bp@lists.ebxml.org>
Sent: Thursday, July 26, 2001 7:52 PM
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
>
> _____________________________________________________________________
> This message has been checked for all known viruses by the
> MessageLabs Virus Scanning Service. For further information visit
> http://www.messagelabs.com/stats.asp
>