W3C home > Mailing lists > Public > public-ws-chor@w3.org > October 2004

Information related to issue 870, for discussion on tonight's call

From: Gary Brown <gary@enigmatec.net>
Date: Tue, 12 Oct 2004 11:11:40 +0100
Message-ID: <007901c4b043$e42b8010$0200a8c0@LATTITUDEGary>
To: "WS-Choreography List" <public-ws-chor@w3.org>

Issue 870: "The current reactive mechanism introduces implicit links between 
concurrent activities that
compromises simplicity and makes model verification difficult. As far as we 
can tell there are no use
case requirements for such a reactive mechanism. Whereas there is a clear 
CSF for simplicity. "


Some further information:

Here is a simple example showing how the use of variables for 
synchronization can implicitly impact the interactions that may be 
performed, and also potentially introduce a different type of deadlock:

<parallel>
    <workunit guard="cdl:getVariable(xyz)" block="true" >
        <interaction operation="foo" >
            ....
            <record>
                <target var="cdl:getVariable(abc)" />
            </record>
        </interaction>
    </workunit>
    <workunit guard="cdl:getVariable(abc)" block="true" >
        <interaction operation="foo" >
            ....
            <record>
                <target var="cdl:getVariable(xyz)" />
            </record>
        </interaction>
    </workunit>
</parallel>

This is an extreme case, but shows how the synchronization based on 
variables can introduce implicit dependencies that affect the true flow of a 
set of interactions.

Possibly the model checking can be enhanced by modeling the variables as 
processes - so that the behaviour of synchronization can become explicit. 
However this will complicate the model checking. I am also not sure what 
would happen if the reactive mechanism was to become more complex, handling 
the unsetting of variables or even reacting to changes in the value of a 
variable.
Received on Tuesday, 12 October 2004 10:11:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:01:06 GMT