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

["David RR Webber" <david@drrw.info>]

John,

Now I've got the transaction system working OK - I'm cool with what we
have.

It took some thinking to get the model reflecting the behaviour(s).

As you note - if there is an need for atomicity - it is only in the context
of the transaction block model - not separate messages outside of that.

What may make sense is to provide a clearer way of indicating rules
associated with steps and conditions that we wish to test.  It's not
entirely obvious right now.  Perhaps a bpss: namespace-like approach
may help for XPath statements - where that denotes the values within
the BPSS process instance....and how the state mechanism can be used.

Thanks, DW.

----- Original Message ----- 
From: "Yunker, John" <yunker@amazon.com>
To: "Dale Moberg" <dmoberg@cyclonecommerce.com>; "Monica Martin"
<Monica.Martin@Sun.COM>
Cc: "David RR Webber" <david@drrw.info>; "BPSS ebXML"
<ebxml-bp@lists.oasis-open.org>
Sent: Thursday, May 13, 2004 5:04 PM
Subject: RE: RE: [ebxml-bp] Clarification - FORK and BusinessTransaction


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