RE: Burdett ML gap/fit analysis - first cut

Jon

Some comments in-line below.

David

-----Original Message-----
From: Jon Dart [mailto:jdart@tibco.com]
Sent: Tuesday, July 29, 2003 2:35 PM
To: 'public-ws-chor@w3.org '
Subject: Burdett ML gap/fit analysis - first cut



I made another pass over Burdett ML recently, and have some
comments about requirements it doesn't currently seem to meet.
I am sure there are things I missed, so consider this only a
possible starting point in the gap/fit analysis.

parallel execution - may be implicitly supported already; what if two
processes have same start state/end state? But may need explicit
support.
<DB>Start and end states belong to the choreography as a whole rather than
to a process within the choreography. The rules also say that states must be
unique, so, according to the spec, two processes could not have the same
start and end states. However parallelism is possible if two (or more)
processes or interactions have a "precondition" that are the same. In this
case both processes/interactions should start at the same time. Similarly,
you can synchronize parallel processe/interactions by specifying a compound
pre-condition such as "Process1Complete AND Process2Complete" where each
state marks the completion of a process. Note that you could just have
easily written, if you wanted to, "Process1Complete OR
Process2Complete"</DB>

decision points - currently, the only indication that a process is a
decision point is that it has >1 transition out of it. Should allow
specification of decision logic? This has been discussed previously -
could be a big issue.
<DB>The current spec currently defines decisions using the "Preconditions"
element on a process or ineraction. This means that if a process can have
multiple different final states, then each state can be separately checked
for and an appropriate action taken.</DB>

Error vs. normal transitions - it is a requirement to support these.
Should a process have an implicit error transition to an error handler
(probably)? Raises issues of scope/nesting of error handling - cf. BPEL.
<DB>Handling of errors by a process is definitely an "internal process"
problem that is better defined using things such as BPEL. What the
choreography spec needs to allow is define: a) how an error at one role is
communicated to another role that needs to know, and b) define what a role
should do (in terms of interactions with other roles) once it is aware of an
error. The current spec allows both of these to be specified, however, it
does not specify any standard way of specifying that an interaction is
communicating some sort of error state which might be useful.</DB>

Composition - there is an extension mechanism and import - need other
kinds of composition support? Support for subprocesses is one missing
piece IMO.
<DB>Totally agree ... although I have some ideas on how it could be done ...
;)</DB>

IMO should simplify things so every state doesn't have to be named (I
have made a suggestion about this earlier - see
http://lists.w3.org/Archives/Public/public-ws-chor/2003Jun/0162.html).
But this is not strictly a requirement.
<DB>This is an idea we need to explore further.</DB>

--Jon