RE: RE: [ebxml-bp] Clarification - FORK and BusinessTransaction

["Yunker, John" <yunker@amazon.com>]

I will be on the call for the first 1/2 hour.

Re: "is all complete or just fails" --> complete may either be "business success" or "business failure" and still have "technical success".  Transaction business success / failure may be (are usually) guards on the transitions within the business process.  Technical failure usually requires some sort of technical intervention.

My concern is that transactions are the building blocks for process, and as such once we allow elements of transactions to be the building blocks we destroy the integrity of the transaction.  A transaction should be very well defined in pre-conditions and post-conditions, allowing binding to policy etc, in essence being atomic with respect to the process model.

Talk to you on Monday.

-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] 
Sent: Thursday, May 13, 2004 1:52 PM
To: Monica Martin; Yunker, John
Cc: David RR Webber; BPSS ebXML
Subject: RE: RE: [ebxml-bp] Clarification - FORK and BusinessTransaction




> When you send a PO you should expect to get a response that details 
> the disposition of each line item (accepted, rejected, backordered, 
> error invalid SKU, etc).  That completes the PO transaction.
> In some business cases (automatic backorder or PO saying 
> "backorder if not available") the backorder transaction is part of 
> the Order transaction, in others you are required to send a 
> seperate order with the new delivery instructions.
> 
> When there is a fork between business messages, each business message 
> is its own transaction, since by definition the transaction is the 
> atomic unit.  For instance a optional response becomes a notification 
> (e.g. notification of acceptance, notification of availability).
> 
> We can get into trouble if we break up the atomicy transactions.
> 

John, to me atomicity means that a unit either is all complete or just fails (and possibly there are many ways and flavors of failure, as BPSS distinguishes). But atomicity is not broken if we allow it to have subtransactions, at least not necessarily. If we don't allow subtransactions, we simply cannot properly handles cases like Haugen-Fletcher described. 

I don't think we need in version 2.0 to enter into the full generality of coordination, coherence, transaction semantics (in the prepare-commit sense). A lot of this functionality is not yet needed for designs, and possibly never will find a niche. But we do need to allow RequestResponse BTs where, after the Request, but before the Response, there is another Transaction. The refactor part 2 certainly allows this and builds on the ideas of onInitiation in earlier drafts.

We need to establish that atomicity is compatible with subtransactions. We may wish to have some WF rules for UNCITRAL forms that mandate certain interfaces of superordinate BT with subordinate BT. We should definitely allow some time Monday to discuss atomicity and subtransaction, if you are able to be on the call. 

Thanks,

Dale Moberg