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.

		Yaron

Received on Friday, 18 July 2003 17:33:40 UTC