Re: Global view requires transactions (RE: Use Cases )

> > At the public process level, we just need to define a transition
> > called "cancel" that go back to an earlier state.  There is no need to
> > define a block of atomic actions.  In other words, BTP, WS-Tx is more
> > relevant to the private process (an implementation concept).
>
> If you want to "cancel" something you need to say what. Cancelling the
> whole choreography is an option if the choreography is very simple. But
> for anything more than a three activities long we tend to want the
> option to cancel or compensate for some of the work, then proceed along
> an alternative path. Like switching from one shipper to another without
> having to cancel the already fulfilled purchase order. So there needs to
> be a notion of some unit of work that gets cancelled.
>
> Whether that gets coordinates using BTP, WS-TX, some other protocols, or
> maybe requires no coordination at all is an implementation issue. The
> choreography should not be married to any specific coordination protocol
> or even require one (some cases do well without it). But it still needs
> the notion of that unit of work you are cancelling or compensating.

Agreed. A unit of work (let's call it an task for now) needs to be uniquely
identifiable via, say, a correlation id (or context) and should be
cancellable. How that cancellation occurs is a back-end service decision,
but the choreography can identify which tasks to cancel or confirm (in some
cases, confirm may be a null-op).

Mark.

Received on Tuesday, 20 May 2003 05:40:36 UTC