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

RE: Requirements Objection: Machine Processable Control Logic

From: Burdett, David <david.burdett@commerceone.com>
Date: Fri, 18 Jul 2003 15:12:19 -0700
Message-ID: <C1E0143CD365A445A4417083BF6F42CC053D1C1A@C1plenaexm07.commerceone.com>
To: "'Yaron Y. Goland'" <ygoland@bea.com>, "'WS Chor Public'" <public-ws-chor@w3.org>


I think you are making four main points:
1. Control logic requires internal and externally visible inputs
2. Control logic changes over time and these changes should be hidden so
that we have loose coupling
3. Specifying control logic in "machine readable" form means we freeze the
control logic used by a participant
4. We should therefore not specify control logic in a machine readable form
(e.g XPATH)

Although I basically agree, I think there a lot depends on what is meant by
"machine readable", so I would rephrase 3 above positively as "Control logic
should be specified in a machine readable but implementation independent
form". This means that the control logic could be processed - which is
useful, for example, for run-time validation that a choreography is being
followed correctly, but would allow individual implementations to vary one
from another as well as evolve over time.

One way you could do this is to define control logic in the choreography in
terms of "states", for example, "If OrderError then ..." where OrderError is
a state which has a well defined semantic. In an implementation the
"OrderError" could then be mapped to a combination of conditions which were
partly internal (e.g. a look up of the CustId against a database) and partly
external, e.g. Order Message received.



-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com]
Sent: Friday, July 18, 2003 2:33 PM
To: 'WS Chor Public'
Subject: Requirements Objection: Machine Processable Control Logic

Non trivial control logic requires both externally visible inputs (messages)
and internally visible inputs (local variables, databases, etc.). If WS-Chor
only supports specifying control logic based on externally visible inputs
then WS-Chor will be unable to express the equally critical internally
visible inputs to a decision and so will specify incorrect logic.

Of course WS-Chor could choose to specify both the internal and external
inputs, which would necessitate the creation of a full fledged programming
language which would require duplicating the work BPEL is doing. I would
suggest we are best advised to leverage their work than to duplicate it.

More generally, non trivial control logic changes over time. However the
whole point of web services is the idea of loose coupling which means in
this case that control logic should be able to change within fairly wide
parameters without having to change the behavior of partners. By explicitly
specifying control logic in a machine readable form we freeze the control
logic used by a participant since any changes they make will break
assumptions their partners have made based on seeing what their logic looks
like. This is why I believe that in the majority of cases WS-Chor
specifications won't have accompanying BPELs since in most cases specifying
the BPEL would be counter productive as it would 'over specify' things. Put
more generally, in most cases specifying control logic in any machine
readable form (XPATH) causes choreographies to become unnecessarily fragile
and is hostile to the goal of interoperability.

This is why I object to including requirements to specify control logic in
machine processable format, even if we restrict the control logic to only
addressing externally visible inputs.

Received on Friday, 18 July 2003 18:12:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:10 UTC