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

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.

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

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 ?

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.

Received on Monday, 19 May 2003 13:33:39 UTC