RE: Requirements Objection: Machine Processable Control Logic

+1

> -----Original Message-----
> From: Assaf Arkin [mailto:arkin@intalio.com]
> Sent: Monday, August 18, 2003 5:02 PM
> To: ygoland@bea.com
> Cc: 'Burdett, David'; 'WS Chor Public'
> Subject: Re: Requirements Objection: Machine Processable Control Logic
> 
> 
> 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.
> 
> arkin
> 
> 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
> >>
> >>
> >>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 Monday, 25 August 2003 15:00:05 UTC