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

[Karsten Riemer - Sun IR Development <Karsten.Riemer@Sun.COM>]

I think patterns is definitely a good approach to reserve and commit,
even a multiparty reserve and commit.
Does anyone have thoughts on how to reflect these patterns in BPSS?
Perhaps this would be a good agenda item for Thursday?
EDOC has done some work, too, on applying patterns to collaborations. If anyone 
is interested, contact me or Cory.

-karsten

> >Date: Mon, 30 Jul 2001 18:19:09 -0500
> >From: bhaugen <linkage@interaccess.com>
> >Subject: Re: multiparty (was) Fwd: Re: message routing
> >To: Martin W Sachs <mwsachs@us.ibm.com>, "Collier, Timothy R" 
<timothy.r.collier@intel.com>
> >Cc: ebxml-bp@lists.ebxml.org
> >MIME-version: 1.0
> >X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
> >Content-transfer-encoding: 7BIT
> >X-Priority: 3
> >X-MSMail-priority: Normal
> >List-Owner: <mailto:ebxml-bp-help@lists.ebxml.org>
> >List-Post: <mailto:ebxml-bp@lists.ebxml.org>
> >List-Subscribe: <mailto:ebxml-bp-request@lists.ebxml.org?body=subscribe>
> >List-Unsubscribe: <mailto:ebxml-bp-request@lists.ebxml.org?body=unsubscribe>
> >List-Archive: <http://lists.ebxml.org/archives/ebxml-bp>
> >List-Help: <http://lists.ebxml.org/elists/admin_email.shtml>, 
<mailto:ebxml-bp-request@lists.ebxml.org?body=help>
> >
> >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
> >>
> >
> >
> >------------------------------------------------------------------
> >To unsubscribe from this elist send a message with the single word
> >"unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org

---------------------------------------------------
Karsten Riemer,
b2b Architect
XML Technology Center
Sun Microsystems Inc.,
MailStop UBUR02-201
1 Network Drive,
Burlington, MA 01803-0903

ph. 781-442-2679
fax 781-442-1437
e-mail karsten.riemer@sun.com