W3C home > Mailing lists > Public > public-ws-chor@w3.org > July 2003

Re: Requirements Objection: Machine Processable Control Logic

From: Andrew Berry <andyb@whyanbeel.net>
Date: Mon, 21 Jul 2003 01:17:00 +1000
Cc: "Yaron Y. Goland" <ygoland@bea.com>, "'WS Chor Public'" <public-ws-chor@w3.org>
To: Assaf Arkin <arkin@intalio.com>
Message-Id: <359A0638-BAC5-11D7-8164-0003936786BC@whyanbeel.net>


On Saturday, July 19, 2003, at 12:42  PM, Assaf Arkin wrote:
> The simple choreography where buyer sends PO and seller sends 
> accept/reject is control logic. It could be done in reverse, or it 
> could be a different message sent in response, or perhaps no response. 
> However, that control logic is "incorrect" since it does not include 
> the "equally critical internally visible inputs" that leads one to 
> either send accept or reject. Furthermore, it is fragile since we 
> freeze the control logic and therefore changing the order of messages 
> or adding other messages is impossible.

I tend to have a different view of these issues (captured to some 
extent in 
http://lists.w3.org/Archives/Public/public-ws-chor/2003Jul/0146.html).  
To respect the autonomy of participants, a choreography specification 
should only specify externally visible behaviour and I would argue that 
it is correct to do so: from the perspective of other participants, 
this is non-deterministic behaviour.  If another participant requires 
visibility of the internal inputs, then those inputs should be made 
explicitly visible in the choreography and we need to find a mechanism 
to do so.  I would also argue that if you distinguish between local 
participant behaviour and interaction behaviour (causal relationships) 
then you do not lose flexibility to add new interactions or local 
behaviour.

Ciao,

AndyB
Received on Sunday, 20 July 2003 11:15:14 GMT

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