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

Re: Requirements Objection: Machine Processable Control Logic

From: Assaf Arkin <arkin@intalio.com>
Date: Mon, 18 Aug 2003 17:01:38 -0700
Message-ID: <3F4168E2.1030507@intalio.com>
To: ygoland@bea.com
CC: "'Burdett, David'" <david.burdett@commerceone.com>, "'WS Chor Public'" <public-ws-chor@w3.org>

I think what we're looking for is not 'machine readable' but 
'deterministic' or 'computational complete'.

If the flow is 'receive X, reply with either Y or Z', then we can 
express it as machine readable. That allows a machine to read the 
definition and use it for any number of purposes, like validation or 
creating a skeleton. It's not deterministic. Either Y or Z would happen 
after X, and in fact you can't even tell Y/Z would happen after X, only 
that something is wrong if neither one happens. And, of course, it's not 
computationally complete.

What we are looking for, IMO, is abstraction. If our concern is to allow 
the implementation to change over time, or just pick different 
implementations, than we need to work at the abstract level. It all 
boils down to letting it be as abstract as you want it to be. If it 
*cannot* be abstract then it's not going to serve some of the use cases, 
like supporting variety of implementations. Within abstraction there's 
any number of capabilities we can have to make the language simpler or 
richer without violating that one principle.

I think it's misjudging to say that we should not 'specify control logic 
in a machine readable form' to support abstraction, because that's 
exactly what the example David gives below is all about. It's abstract, 
but if it was written in BurdettML then it would be machine readable.


Yaron Goland wrote:

>I think we are basically in agreement, the ugliness is over the term
>'machine readable'.
>I want the directed graph describing the legal messaging patterns to be
>'machine readable'. What I'm trying to avoid is having the logic used when a
>decision is made be machine readable for the reasons that you state more
>clearly below than I did in my original letter.
>		Yaron
>>-----Original Message-----
>>From: Burdett, David [mailto:david.burdett@commerceone.com]
>>Sent: Friday, July 18, 2003 3:12 PM
>>To: 'Yaron Y. Goland'; 'WS Chor Public'
>>Subject: RE: Requirements Objection: Machine Processable Control Logic
>>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
>>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.
>>		Yaron
Received on Monday, 18 August 2003 22:15:13 UTC

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