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

[bhaugen <linkage@interaccess.com>]

The patterns can be defined as ebXML business collaborations.
The BP group started defining collaboration patterns a little bit
in phase 1 (contract formation and negotiation patterns), and
just talked today about a followon activity to define more.

A "Reserve and Commit" pattern sounds like a good one to
add to the list. (Got a better name?)

The credit authorization from the dropship example in the
phase 1 BP Worksheet document is almost the same thing.

-Bob Haugen

----- Original Message -----
From: Martin W Sachs <mwsachs@us.ibm.com>
To: Collier, Timothy R <timothy.r.collier@intel.com>
Cc: <ebxml-bp@lists.ebxml.org>
Sent: Monday, July 30, 2001 5:32 PM
Subject: RE: multiparty (was) Fwd: Re: message routing


>
> Tim,
>
> I agree.  We can use the patterns without doing a "real" 2-phase commit
> across the two parties.  We just have to be careful how we explain it.
>
> 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
>
****************************************************************************
*********
>
>
>
> "Collier, Timothy R" <timothy.r.collier@intel.com> on 07/30/2001 01:49:13
> PM
>
> To:   Martin W Sachs/Watson/IBM@IBMUS
> cc:   "'ebxml-bp@lists.ebxml.org'" <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
>
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org
>