- From: Assaf Arkin <arkin@intalio.com>
- Date: Wed, 30 Jul 2003 14:46:33 -0700
- To: jdart@tibco.com
- CC: public-ws-chor@w3.org
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