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

["Collier, Timothy R" <timothy.r.collier@intel.com>]

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.


	my $.02

		Tim


-----Original Message-----
From: John Yunker [mailto:JohnY@EDIFECS.COM]
Sent: Thursday, July 26, 2001 9:53 AM
To: bhaugen; ebxml-cppa@lists.oasis-open.org
Cc: ebxml-bp@lists.ebxml.org
Subject: RE: multiparty (was) Fwd: Re: message routing


This issue gets really thorny unless you keep two concepts front and center:
Any one "transaction" is between two parties, and a party's responsibilities
and capabilities are specified in the protocol in which they "agree" to
participate.

This is exactly why the UMM represents a BCP "Business Collaboration
Protocol" (multi-party exchange of messages) as a correography of individual
transactions.  Each transaction is between two parties. (indeed even the
information distribution patterns are executed between two specific parties
in any one instance)

The premis is simple, if a party to an agreement has a trggering condition
(as defined in the BCP), they will initiate a transaction.  It MUST be that
simple -> if the guards are satisfied, then execute the transaction!

The important part of this is that the responsibilities in a multi-party
protocol are specified in the agreement and its referenced BCP.  Any
additional messages are outside the context of the agreement and its
referenced BCP.

This reduces the question of "who controls a BCP / transaction" to "what are
my allowed actions at this point in the collaboration".  For, when it comes
down to it, the BCP is simply modeling and allowing efficient communication
of the business relationship.  It is the business relationship that spells
out who controls a business transaction.

I agree that working out scenarios and verifying they allow proper business
control is a good way to achieve both a reasonably capable BPSS and correct
BCPs, which allocate control in accordance with the business they model.
Control must be as simple as your ability to initiate a transaction causing
a binding business action (and associated e-business transaction) at any
specific point in the collaboration.

This is why I see a robust ability to describe guards (rules) on transitions
between transactions based on message contents (business information) as the
key enabler to effective multi-party collborations. (heck, the ability to
override specific guards in the agreement would be dandy as well!)

Thanks,
John

(Tony, I can't post to cppa yet, could you please forward.)
-----Original Message-----
From: bhaugen [mailto:linkage@interaccess.com]
Sent: Thursday, July 26, 2001 5:42 AM
To: ebxml-cppa@lists.oasis-open.org
Cc: ebxml-bp@lists.ebxml.org
Subject: Re: multiparty (was) Fwd: Re: message routing


This is really an important conversation.

I think it is imperative to think of the business requirements here
and not trip off into all the possible permutations of multi-party
interactions.

* Questions:
1. What are the real business scenarios requiring business collaborations
composed of multiple related transactions?  (I mean transactions in
the BPSS BusinessTransaction sense here.)

2. What are the real business scenarios requiring multi-party
collaborations?

* Tentative stabs at answers:
1. The most common business scenario will probably be order-fulfillment,
where one transaction forms the order (a kind of contract) which could be
composed of many commitments (e.g. line items) to deliver and pay for
goods or services.

So in this case, some of the transactions in the collaboration will have
commitment-fulfillment relationships between them.  (This is all described
or at least sketched out in UMM.)

I have proposed on the BP list that commitment-fulfillment relationships
be used explicitly to manage multi-transaction collaborations in the next
stage of BPSS work, when UN/CEFACT gets rolling.

But you can still think of them implicitly as one of the main business
requirements for multi-transaction collaborations, where one transaction
has depencies on another.

2. One of the main scenarios involving multiple parties is when one
party needs help to fulfill commitments to another party.  I think,
but cannot yet prove, that most or all of these scenarios can be
resolved into reciprocal commitments between two parties.
(Bill McCarthy says there is proof that all multi-party scenarios
can be broken down into binary commitments.)

So it may be possible to resolve multi-party collaborations to
a simpler group of related dialogs, not only as a temporary
expedient but as a permanent solution for at least a large
majority of real use cases.

I agree with Jamie that good examples are required here.  Besides
the one that he sketched out, the dropship scenario used in the ebXML-BP
Worksheet document would work for a starter.

I fully agree that there important unresolved issues of who controls
the overall multi-party collaboration, who gets what information,
who controls each transaction (which will be different from who controls
the overall collaboration), etc.

-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