A situation I don't want to end up with. A process has two paths for
execution. One path is executed when the order has been accepted by the
supplier, and static analysis indicates that is has undefined semantics.
The other path is executed when the order has been rejected, promptly
ending the process, and static analysis indicates it then executes to
completion. The process will result in no orders ever being completed,
yet an implementation must execute it.
I propose that instead we suggest three separate cases:
1. if static analysis reveals there are only successful paths of
execution, must accept process
2. if static analysis reveals there are no successul paths of execution,
must reject process
3. if static analysis reveals there are successful paths of execution,
or a non-zero probability of them being successful paths of execution,
may accept process
an implementation can be pessimistic in determining only 1 or 2, of
optimistic in determining 1, 2 and 3, and leaving the decision up to the
discretion of the implementation or the user.
Assaf
Yaron Y. Goland wrote:
> Section 5:
> From: BPEL4WS takes it as a general principle that compliant
> implementations MAY choose to perform static analysis to detect and
> reject process definitions that may have undefined semantics. Such
> analysis is necessarily pessimistic and therefore might in some cases
> prevent the use of processes that would not, in fact, create
> situations with undefined semantics, either in specific uses or in any
> use.
>
> To: BPEL4WS takes it as a general principle that compliant
> implementations MAY choose to perform static analysis to detect and
> reject process definitions that may have undefined semantics. Such
> analysis MUST be performed optimistically, that is, assuming the
> process has no syntactic errors then if there exists at least one
> execution path from each start activity in the process that can
> complete successfully then the process MUST be accepted for execution.
>
> To unsubscribe from this mailing list (and be removed from the roster
> of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
>
>
