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

["Welsh, David" <David.Welsh@nordstrom.com>]

This discussion sounds awfully familar to one going on right now in the OASIS BTP group on 2PC !
-Dave


> -----Original Message-----
> From: Collier, Timothy R [mailto:timothy.r.collier@intel.com]
> Sent: Monday, July 30, 2001 10:49 AM
> To: 'Martin W Sachs'
> Cc: 'ebxml-bp@lists.ebxml.org'
> Subject: RE: multiparty (was) Fwd: Re: message routing
> 
> 
> Marty,
> 
> 	I agree that the traditional 2PC implementations, using 
> locking, are
> inappropriate for internet based transactions, however, the 
> "pattern" is
> appropriate for use.  An implementation of the pattern would 
> have to use a
> much looser resource commitment - like a 24 hour hold from an 
> airline - but
> the application pattern could be the same.  If the only way 
> allowed to solve
> this forces all applications to use presume commit and compensation, I
> believe that we have needlessly taken away options from the developer.
> 	Maybe, what could be done is to allow a sharing of 
> global context
> between the binary collaborations.  In that way, the binary 
> participants
> could make use of the "state" data without having to know in 
> advance who the
> other participants are.  It would not force the binary 
> participants to use
> or not use the information.  It would not force them to use a 
> 2PC design or
> a presume commit design. This would also not require a 
> centralized manager
> for the collaboration.  
> 	The related patterns approach of John Yunker would 
> work, IMHO, but
> if that creates too much heartburn, then maybe the same goal could be
> achieved by allowing shared state data between binary only 
> collaborations.
> 
> 	Tim
> 
> 
> 
> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Sunday, July 29, 2001 7:05 PM
> To: John Yunker
> Cc: Collier, Timothy R; ebxml-cppa@lists.oasis-open.org;
> ebxml-bp@lists.ebxml.org
> Subject: RE: multiparty (was) Fwd: Re: message routing
> 
> 
> 
> 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
> 
> 
> 
> 
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org
>