[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - 82.3 - Propsoal for vote
Here we go again. Incorporated some changes based on comments received from TC members during the week. ------------------------------------------- Hi everyone, First phase of two-phase voting (content, then spec wording). I've merged the previously named 'proposed changes' section into the main text of this mail since this is the proposal. -------------------------------------------------- AP1.1 refactoring, start. ------------------------------- (add motivation in phase 2) (consider what old text to bring in from spec and how to modify it to introduce various aspects, especially regarding clarifications about initialization of correlation sets and variable omission in phase 2). ProfileURI: - urn:oasis:names:tc:wsbpel:2.0:abstract:ap11 Base Language subset _____________________ .. This profile restricts the base in the following manner: * Allowing all expressions to be opaque except joinCondition. Please note that the joinCondition is based on the transition conditions on the incoming links. If the joinCondition is missing its default value is the disjunction of the status of the incoming links. * The only attributes that can be opaque are the attributes "variable", "inputVariable", "outputVariable", "part" and "toVariable" attribute of "fromPart" element, "part" and "fromVariable" attribute of "toPart", on receive/invoke/reply/onMessage/onEvent (Note: bug fix based on Issue 97: fixing the consistency for elements onMessage and onEvent. "from/toPart" are new in BPEL2.0). * Allowing opaque activity, as a bug fix for the two reasons below. Note that its use elsewhere is superfluous since completions in this profile allow adding new BPEL activities anywhere: -Allows for hiding an activity that is the source or target of -links. Allows for using omission-shortcut in places like fault handlers etc (This had led to Issue 91). * Activity <exit > is not allowed. * Uses omission-shortcut for the opaque tokens above (allowed by all APs anyway). (* sidebar to TC : 'getVariableData' and 'get VariablePropery' are allowed. No need to mention this above since everything not restricted is allowed.) Base Completions subset _________________________ The intent of this profile is for a valid completion to follow the same interactions as the abstract process with the partners of the abstract process, and possibly perform additional steps relating to new partners. Therefore, a completion should not change the presence or order of interactions already in the abstract process, nor perform additional interactions with the partner links defined in the abstract process. Places where new activities may be added are not explicitly defined in processes in this profile. The permitted executable completions of abstract processes in this profile include both 'Opaque Token Replacement' and 'Addition of BPEL Constructs', but subsetting those to provide guildelines to meeting the intent above in a simple way, such that: -In any executable completion: * New activities (including those created to replace opaque activities) MUST NOT interact with partnerLinks already defined in the abstract process. Note that these restrictions still allows for adding new interactions with new partnerLinks (ie: partnerLinks added in the executable completion but not present in the abstract process). * The target of a newly created link MUST NOT be an activity existing in the abstract process during executable completion. Note that adding such a new target would cause the corresponding join condition to change and that would violate the completion rules of the base (ie: cannot modify a non-opaque existing value). This restriction does not affect adding links to new activities (that are not replacing opaque activities). * It is not allowed to add copies in assigns whose 'to' is any of the EPRs of the partnerLinks defined in the abstract process, because that is equivalent to removing subsequent interactions with that partner. Remember that 'opaque token replacement' also replaces opaque tokens omitted through the omission-shortcut. * The lexical parent BPEL construct of an existing BPEL construct (including activities) in the Abstract Process MUST NOT be changed during execution completion. Hence, the nesting structure of composite activities around any activity in an abstract process is unchanged in any legal completion. Examples: --------- OK: add a variable or a partner link to an existing scope, even though that scope is the parent of activity A. OK: add a new link def to an existing flow. Not OK: add a 'while' around the existing activity A whose parent is B. Not OK: add a new scope around an existing variable definition whose parent is an existing scope S. * One MUST NOT add: * New branches to an existing if-then-else activity, unless it has no else branch AND the new branch is added after all existing branches. * New branches to an existing pick activity. * New fault, compensation, or termination handlers to an existing scope. However, they may be added at the process level. * <exit> * <throw> - only in cases where the exception will leak outside of the highest *newly added* activity in the parent hierarchy of the <throw>. However, one may add a <throw> nested within a newly added activity A, as long as the excetion is caught by A or its descendants and not rethrown outside of A. * For a newly added activity, any faults it throws must be caught and handled without leaking to the activities of the AP. (see throw above). Note that one way one could still change the order of interactions is by changing the value of a variable used in a condition that affects branching (transition condition, if-then, while condition, etc), in such a way that the new effective branching behavior is in direct conflict with what was done in the abstract process. In this profile, we will not restrict writing to variables in a strict manner, but provide this note as an advisory restriction.