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

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