- From: Assaf Arkin <arkin@intalio.com>
- Date: Mon, 19 May 2003 18:36:43 -0700
- To: Ricky Ho <riho@cisco.com>
- CC: Bob Haugen <rhaugen@speakeasy.net>, public-ws-chor@w3.org
Ricky Ho wrote: > > I think the "shared state" in this context means "shared visibility" > rather than "transactional update". In other words, it is OK to have > one role just update its state unilaterally and communicate that > result to relevant partners. Of course for certain business-specific > process, the state change may need co-ordination among partners (e.g. > how do I know my PO has been accepted). But such co-ordination is > part of the choreography flow design but not the choreography model > itself. +1 > > 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. > Back to the need of a global view. In most cases that I observe, the > need of a global view (why A cares about the interaction B/C) is > because of causal dependency (ie: there are some dependency between > interaction A/B and interaction A/C). Does anyone see other reasons ? I think that sums it all ;-) arkin > > Lets say there are n roles A(1) ... A(n) within a choreography C. > Lets say A(i) doesn't interact with A(j) at all, then A(i) doesn't > care all interaction A(1)/A(j), ... A(n)/A(j). Similarly, A(j) > doesn't care all interactions A(1)/A(i), ... A(n)/A(i). Therefore, > this choreography can effectively be broken down into two independent > choreographies C1 and C2 where C1 exclude A(i) and C2 exclude A(j). > It is possible that role A(m) who participate at C1 will have an > interaction that depends on another interaction at C2. But such > dependency is at the private process level and not at the public > process level. > > The conclusion I'm trying to draw is ... Within a choreography, every > role needs to know each other, otherwise, it is always possible to > break down into two independent choreographies. Hence no need to > worry about hiding the flow to certain parties within a choreography. > > Rgds, Ricky > > At 07:44 AM 5/19/2003 -0500, Bob Haugen wrote: > >> One consequence of a global view of a choreography >> is that the states on the global view are shared states. >> Shared states require synchronization or agreement, >> which requires transactions, a la BTP or WS-Tx or BPSS >> or UNCEFACT BCP or RosettaNet PIPs. >> >> I'm not raising this as an objection to a global view. >> I think it's a fact anyway, when a process crosses >> trust domains. > -- "Those who can, do; those who can't, make screenshots" ---------------------------------------------------------------------- Assaf Arkin arkin@intalio.com Intalio Inc. www.intalio.com The Business Process Management Company (650) 577 4700 This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, dissemination of this communication is prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately.
Received on Monday, 19 May 2003 21:39:26 UTC