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

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

Dale,

I think the current approach can finesse this.

If you send an InformationDistribution transaction first,
then once you get acknowledgeReceipt - actually kick-off
the BusinessTransaction.

Another scenario could be where you are sending
multiple transactions at once, either the same type of
transaction (say multiple orders) or a combination of
say two or three messages.  Maybe the way here is
to define a <package> within <BusinessTransaction>, and
allow you to block up those messages.  You would need
someway of denoting start/end of package - but the ebMS
may already have that....?

Certainly that would be easy to do - and would not hurt the
model.  You would need to use a Join on the return side - to
wait for all the returning answers.  I simple count of sent v
expected responses would work there perhaps.

Anyway - as you note - the current model works for a
lot of scenarios as is.

DW.

----- Original Message ----- 
From: "Dale Moberg" <dmoberg@cyclonecommerce.com>
To: "Monica Martin" <Monica.Martin@Sun.COM>; "Yunker, John"
<yunker@amazon.com>
Cc: "David RR Webber" <david@drrw.info>; "BPSS ebXML"
<ebxml-bp@lists.oasis-open.org>
Sent: Thursday, May 13, 2004 4:51 PM
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