RE: Requirements Objection: Machine Processable Control Logic

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 Wednesday, 13 August 2003 19:30:49 UTC