Re: [wsbpel] Bug Issue (?): BPEL Internal Faults

[Danny van der Rijn <dannyv@tibco.com>]

-1

As I pointed out in our last face to face, this kind of approach will 
make any kind of modularization extremely difficult.  It will give no 
way for a developer of a piece of BPEL code to protect against the 
"modelling error" (legacy term: "programming error") of another modeller 
whose attempt to model the real world failed in a tangible instance.

Danny

Dieter Koenig1 wrote:

>Bug Issue (?): BPEL Internal Faults
>
>Related Issues:
>187 - http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue187
>163 - http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue163
>169 - http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue169
>
>There are a number of cases in the current spec where the behavior of a
>process is described as *undefined*, in particular, after recognizing a
>internal errors described as standard faults.
>
>With the exception of "bpel:joinFailure", *all* of these situations
>represent modelling errors that cannot be dealt with by the business
>process itself in a meaningful way. This behavior becomes even more
>questionable for catchAll handlers that try to deal with multiple
>application faults and unexpectedly encounter a standard fault.
>
>Instead of allowing processes to catch these as standard faults, we propose
>that the process instance must *terminate* immediately when such a
>situation is encountered.
>
>The behavior of terminate is well-defined in BPEL -- as far as BPEL is
>concerned the instance execution ends when terminate is encountered without
>any fault handling behavior.  Any additional facilities for extended
>support for, e.g., repair and continue, is definitely out of scope.
>
>This approach would also create a clear direction for dealing with any
>pathological situation within an inlined language (Issue 163) and therefore
>also for errors within transition conditions (Issue 169).
>
>Kind Regards
>DK
>
>
>
>
>
>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.
>
>
>  
>