W3C home > Mailing lists > Public > public-ws-chor@w3.org > May 2003

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

From: Mark Little <mark.little@arjuna.com>
Date: Tue, 20 May 2003 10:39:27 +0100
Message-ID: <019f01c31eb3$b810bdb0$850a090a@exhp>
To: "Assaf Arkin" <arkin@intalio.com>, "Ricky Ho" <riho@cisco.com>
Cc: "Bob Haugen" <rhaugen@speakeasy.net>, <public-ws-chor@w3.org>

> > 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).

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:05 UTC