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

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

Sounds like a good approach to me.  General enough to be reusable, but close
enough to the "normal" use that it is easily applied. 

	Tim

-----Original Message-----
From: Welsh, David [mailto:David.Welsh@nordstrom.com]
Sent: Thursday, July 26, 2001 4:16 PM
To: 'John Yunker'; Collier, Timothy R; ebxml-cppa@lists.oasis-open.org
Cc: ebxml-bp@lists.ebxml.org
Subject: RE: multiparty (was) Fwd: Re: message routing


By George, I think he's got it !

-Dave
ps. could you elaborate on the 'rollbackTransaction' transaction pattern. I
take it there was some work done on that too.
Thanks.

> -----Original Message-----
> From: John Yunker [mailto:JohnY@EDIFECS.COM]
> Sent: Thursday, July 26, 2001 12:36 PM
> To: Collier, Timothy R; 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
>