Re: [wsbpel] Issue - 82.3 - Proposal for vote]

[Rania Khalaf <rkhalaf@watson.ibm.com>]

Hi everyone,

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).

ProfileURI:

- 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.