|Subject:||Re: [wsbpel] Issue - 82.3 - Proposal for vote]|
|From:||Rania Khalaf (rkha...@watson.ibm.com)|
|Date:||Sep 28, 2005 6:19:38 am|
Here is the updated draft. The major change is to the completions section. First phase of two-phase voting (content, then spec wording).
-------------------------------------------------- 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).
- urn:oasis:names:tc:wsbpel:2.0:abstract:ap11 <RK: request from Alex, due to 16>
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", "fromPart", and "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, the intuition is that 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 meet 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).
* An activity existing in the abstract process MUST NOT be added as the target of a newly created link in the 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 to follow)
* 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.