RE: Issue 1108 - proposal

ignore previous, hit send key premature - must be a fat finger day.

Gary,

I can't find any mention of 1108 in the minutes/irc log. It also wasn't
on
the agenda or on my outstanding issues list.

The only discussion on isolation was issue 1459, and we should verify
whether
that resolution also resolves 1108 (or verify that 1108 is a dupl of
1459).


Martin.


>-----Original Message-----
>From: Martin Chapman [mailto:martin.chapman@oracle.com] 
>Sent: Tuesday, June 21, 2005 11:47 AM
>To: 'Gary Brown'; 'Steve Ross-Talbot'; 'WS-Choreography List'
>Subject: RE: Issue 1108 - proposal
>
>
>Gary I cant find any mention of 1108 in the f2f minute
>
>>-----Original Message-----
>>From: public-ws-chor-request@w3.org
>>[mailto:public-ws-chor-request@w3.org] On Behalf Of Gary Brown
>>Sent: Tuesday, June 21, 2005 9:36 AM
>>To: Martin Chapman; 'Steve Ross-Talbot'; 'WS-Choreography List'
>>Subject: Re: Issue 1108 - proposal
>>
>>
>>
>>Hi Martin,
>>
>>This was discussed at the f2f and I thought it was agreed that
>>the proposal 
>>would be adopted.
>>
>>The only objection at the time from Nick was that he thought
>>BPEL did it the 
>>same way as the current approach in CDL, but then when we 
>>checked, it was 
>>found that BPEL was inline with approach outlined in the proposal.
>>
>>Regards
>>Gary
>>
>>----- Original Message -----
>>From: "Martin Chapman" <martin.chapman@oracle.com>
>>To: "'Steve Ross-Talbot'" <steve@pi4tech.com>; 
>>"'WS-Choreography List'" 
>><public-ws-chor@w3.org>
>>Sent: Monday, June 20, 2005 10:18 PM
>>Subject: RE: Issue 1108 - proposal
>>
>>
>>
>>For some reason this seems to have fallen through the cracks
>>so lets put it on next weeks agenda.
>>
>>Martin.
>>
>>>-----Original Message-----
>>>From: public-ws-chor-request@w3.org
>>>[mailto:public-ws-chor-request@w3.org] On Behalf Of Steve Ross-Talbot
>>>Sent: Tuesday, May 10, 2005 6:46 PM
>>>To: 'WS-Choreography List'
>>>Subject: Issue 1108 - proposal
>>>
>>>
>>>
>>>Martin,
>>>
>>>here is a possible way forward.
>>>
>>>Cheers
>>>
>>>Steve T
>>>
>>>Begin forwarded message:
>>>
>>>> Resent-From: public-ws-chor@w3.org
>>>> From: "Gary Brown" <gary@pi4tech.com>
>>>> Date: 20 April 2005 09:13:02 BST
>>>> To: <public-ws-chor@w3.org>
>>>> Subject: PROPOSAL related to: Example showing problem with current
>>>> isolation semantics in CDL
>>>>
>>>> We should clearly state in the spec that nested isolation
>>>> choreographies are not permitted.
>>>>
>>>> Proposed Text:
>>>>
>>>> Section 2.4.5 contains the following bullet point:
>>>>
>>>> " When isolation is set to "true", changes to the Variable
>>>information
>>>> MUST be visible for read or for write to its sibling Choreographies
>>>> only after this Choreography has completed "
>>>>
>>>> This should be extended to include the text:
>>>>
>>>> "An isolated choreography cannot directly or indirectly perform
>>>> another isolated choreography."
>>>>
>>>> Regards
>>>> Gary
>>>>
>>>> ----- Original Message -----
>>>>  From: Gary Brown
>>>> To: public-ws-chor@w3.org
>>>> Sent: Tuesday, April 19, 2005 12:56 PM
>>>> Subject: Example showing problem with current isolation
>>semantics in
>>>> CDL
>>>>
>>>> Hi
>>>>
>>>> After the recent discussion on isolation being inherited from the
>>>> enclosing choreography, I wanted to outline the following 
>>example to
>>>> show how simply changing the isolation attribute of an enclosing
>>>> choreography can significantly change the behavior of the 
>>>> choreography.
>>>>
>>>> <choreo A>
>>>>
>>>> <variable name="var1" />
>>>>  <variable name="var2" />
>>>> <choreo B isolation=true >
>>>>
>>>> <assign value "x" to "var1" />
>>>>  <assign value "x" to "var2" />
>>>> </choreo>
>>>> <choreo C isolation=true >
>>>>
>>>>  <assign value "y" to "var1" />
>>>>  <assign value "y" to "var2" />
>>>> </choreo>
>>>>
>>>> <parallel>
>>>> <perform choreo B>
>>>> <bind var1/>
>>>> <bind var2/>
>>>> </perform>
>>>>
>>>> <perform choreo C>
>>>> <bind var1/>
>>>> <bind var2/>
>>>> </perform>
>>>> </parallel>
>>>> </choreo>
>>>>
>>>> If choreo A is not isolated, then choreo B and C are
>>>isolated in their
>>>> own right - and therefore because they are both accessing common
>>>> variables, I assume that one or the other of the performs 
>will wait 
>>>> until the other has completed - so in fact they will be 
>>performed in
>>>> sequence. [If this assumption is not true, then I need to have an
>>>> explanation of the behavior when two sub-choreos have the same 
>>>> isolated variable - at what point do they wait?]
>>>>
>>>> Therefore the result would be that both variables would
>>have the same
>>>> value - either 'x' or 'y' depending on the order in which the
>>>> sub-choreos were actually performed.
>>>>
>>>> However, if we now make choreo A isolated, the isolated
>>>attribute on B
>>>> and C is now ignored, as the isolation is inherited from the parent
>>>> choreography (as described at the last f2f).
>>>>
>>>> This now means that because the variables 'var1' and 'var2'
>>>are within
>>>> the same isolation scope, when the two sub-choreos are performed,
>>>> there is no waiting/blocking. This means that the result of the 
>>>> overall choreography is non-deterministic, the variables 
>could have 
>>>> any combination of 'x' or 'y'.
>>>>
>>>> The problem is that a sub-choreography may be defined on
>>the basis of
>>>> having isolation semantics - and this is effectively
>>overridden when
>>>> performed from an already isolated choreography. Whereas if nested
>>>> isolation was supported, the semantics of the
>>>sub-choreographies would
>>>> be preserved, regardless of the isolation status of the enclosing
>>>> choreography.
>>>>
>>>> This example is showing a simple example, but in a real example the
>>>> isolation of a top level choreography could have unforeseen 
>>>> consequences on a sub-choreography that is many levels of nesting 
>>>> removed from the isolated choreography. A case of a small change 
>>>> having a significant impact on bahavior.
>>>>
>>>> Regards
>>>> Gary
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>

Received on Tuesday, 21 June 2005 10:55:25 UTC