Re: Requirements Objection: Machine Processable Control Logic

If I remove the single sentence mentioning XPath and read this e-mail 
again, it seems to suggest that WS-Chor should do as little as possible 
beyond usage of WSDL.

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.

If we want it to be really loosely coupled I suggest we avoid any 
machine readable logic and just stick to WSDL. Or just use UML diagrams.

We are after all creating something other than a UML diagram, a language 
that is machine processable and does cover logic. The question is, how 
do we make if effective and efficient.

I said by ignoring the sentence mentioning XPath because XPath does have 
the nasty habit of complicating things. It's not easy to extend the 
external logic to form an internal logic, nor is it easy to track 
conformance. And in our experience you only use a small subset of XPath, 
for 100% of the use cases I have the usage is extermely trivial. XPath 
as per the XPath specification is an overkill.

I'm sure that if we use our collective technical experience and 
specification skills, we can come up with something that meets our 
requirements and is as effective but far easier to implement. Perhaps a 
profile of XPath (e.g. BPEL does that for join conditions), perhaps a 
simpler expression language or a more refined constraint language.

But if we flat out reject the requirements and it boils down to a 
decision between something and nothing, as complicated as it may be, I'm 
going to stick with something.

arkin


Yaron Y. Goland wrote:

>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 Saturday, 19 July 2003 00:28:29 UTC