Re: design-time validation

Jon Dart wrote:

> Assaf Arkin wrote:
>
>>> Yes, you could run it through a validator of some kind, but can you 
>>> write a validator that will tell you if a BPEL choreography (for 
>>> example) can deadlock or not? Having it machine-readable is one 
>>> thing: having interesting properties like this decidable by machine 
>>> is another issue.
>>
>>
>>
>> If it's fairly simple, and most choreographies are, then you can 
>> easily do that. If it's more complicated you need to break it down 
>> and use heuristic and you can tell with some level of confidence. If 
>> I can determine that it's most likely deadlock free, that's good 
>> enough for me. It's much better than having a choreography that's 
>> prone to deadlock and not knowing about it.
>
>
> Ok .. but back to requirements: what restrictions does D-CR-049 
> (design-time validation) place on the choreography language? You 
> mentioned one: that it be machine-processable. I guess this rules out 
> the suggestion that all decision logic be expressed in human language 
> (since machines still don't process that very well). But you are 
> stopping short of saying that deadlock be formally decidable (which I 
> also do not think is reasonable).

Some structuring would help. For example, if you can compose (here we go 
again) a choreography definition from smaller components and validate 
them individuallty, that would make validating the entire choreography 
easier.

In my understanding of the requirement list, I would not ask to include 
'deadlocks should be formally decidable'. It's definitely a requirment 
for me as a vendor to be able to do that for a large class of 
choreographies. And I would judge the resulting specification 
accordingly. I just don't know if this should be a formal requirment for 
the language. Maybe other members feel it should.

arkin

>
> --Jon
>

Received on Wednesday, 30 July 2003 17:47:26 UTC