RE: [wsbpel] Issue 53 - Motion for consideration by the TC

["Haugen Robert" <Robert.Haugen@choreology.com>]

Ok then, I'll answer myself (below):

> Satish Thatte wrote:

>> 2. The simple outcome-notification for cancel/confirm
>> is just one stylized pattern for process coordination.  
>> Other patterns are possible -- for instance one where 
>> the original work (e.g., a purchase order) may be changed 
>> rather than just cancelled/confirmed.  But with the 
>> explicit handler approach this would require additional
>> syntactic extensions (a change handler?).

> Do you mean where one party makes an offer to buy
> (which is the business semantic of a purchase order)
> and the counter-party, instead of accepting or rejecting
> the offer, makes a counter-offer?

> In other words, do you mean a negotiated order?

While many configurations of messages are possible,
only a few deserve to be called patterns
(in the sense of well-accepted and well-formed 
solutions to problems).

So I think in this case as well as the one in 
your original slides on this topic, what appears
to be an impediment is just an ill-formed as opposed 
to a well-formed business transaction.

In business, the most common pattern for an order
(or any other kind of contract) is Offer-Acceptance.
You can look it up in Google and get 36K hits,
many of them on-topic, for example:
http://www.ledgerism.net/UCCformation.htm

Offer-Acceptance fits into a simple business transaction
protocol very nicely.  

Order negotiation (an extended series of counter-offers
with an eventual acceptance or giving up) fits very
nicely also.  Here's one way written by Jamie Clark, Esq:
http://www.ebxml.org/specs/bpPATT.pdf

Another way would be to include a whole series of
counter-offers in the active phase of one transaction,
followed by confirm or cancel.

Both ways are easily accomodated by any of the
candidate business transaction protocols.

Once an offer is accepted, it's a contract, and neither
party can change it unilaterally.  Changes or cancels
at that point need to go thru another business transaction.

We went through this same point-counterpoint at the F2F,
where I thought you agreed that the business transaction
in your slides should be significantly refactored,
which would make it correspond much more cleanly
to a typical transaction protocol.

My argument above is not intended to dismiss the issue
of application data on transaction notifications,
just to dismiss the requirement for a change handler
in addition to confirm and cancel.