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

[Martin W Sachs <mwsachs@us.ibm.com>]

The problem with using 2-phase commit patterns for e-business across the
Internet is that the commit process may tie up resources at multiple
business for excessive periods, especially if one or more of the business
has to go out to subcontractors before completing the transaction.
Compensation protocols may be just as effective and much less resource
consuming.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



John Yunker <JohnY@EDIFECS.COM> on 07/26/2001 03:36:09 PM

To:   "Collier, Timothy R" <timothy.r.collier@intel.com>,
      ebxml-cppa@lists.oasis-open.org
cc:   ebxml-bp@lists.ebxml.org
Subject:  RE: multiparty (was) Fwd: Re: message routing



An interesting problem.  It is one that breaks down nicely if you use two
phase commit patterns.

In a two phase commit pattern, the requestor first initiates preparatory
transactions which ask the responder(s) to verify that the transaction will
succeed (disk space, mandatory fields, etc).  If all of the responders
respond positively then they agree to post the binding transaction, if it
arrives within the agreed timeframe.  The initiator then issues the binding
transaction, referencing the setup transaction.

Similarly the travel agent (or any multi-party dependency) should be solved
the same way.  The binding transactions cannot me initiated by the
requestor
until the condition [proposedTransaction.isAcceptable = True] is met for
all
essential components.  This is modeled as guards on the transition(s) from
the setup transactions to the binding transactions.  Any one transaction is
still between two parties and is goverened by the agreement between those
parties.

This is a great example of a collaboration pattern, we could call it the
multi-party-commit pattern.  As a result we could provide a basic framework
of properties on the "proposedTransaction" transaction pattern and its
dependent "bindingTransaction" transaction pattern which could make it easy
for consistent and efficient implementations.

Exactly the kind of work we need to do.

In this case the controlling business entity is clear in each relationship,
as well as on the transaction as a whole, and is modeled correctly on the
actual business relationships being facilitated.

Once again the key is relating the guard conditions on the transition
between transactions to the business requirements.  Another reason why UMM
with its ability to elaborate those requirements onto the collaboration is
important to the process of developing these protocols.

Thanks,
John
(ps, there has been a lot of great preceding work done on modeling
multi-party interactions, and that I do not specifically reference that
work
here does not diminish its importance to this discussion.  I am simply
reiterating that to understand individual responsibilities those
responsibilities need to be discretely modeled as conditions)

Tony, please forward to cppa  :-)
-----Original Message-----
From: Collier, Timothy R [mailto:timothy.r.collier@intel.com]
Sent: Thursday, July 26, 2001 11:35 AM
To: John Yunker; bhaugen; ebxml-cppa@lists.oasis-open.org
Cc: ebxml-bp@lists.ebxml.org
Subject: RE: multiparty (was) Fwd: Re: message routing


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

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