- From: Burdett, David <david.burdett@commerceone.com>
- Date: Fri, 18 Jul 2003 15:12:19 -0700
- To: "'Yaron Y. Goland'" <ygoland@bea.com>, "'WS Chor Public'" <public-ws-chor@w3.org>
Yaron 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. Thoughts? David -----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. Yaron
Received on Friday, 18 July 2003 18:12:21 UTC