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

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

> 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