Subset
of the Executable Completions Allowed in the Base
With
respect to executable BPEL completions of an abstract process that uses this
profile, the intent of the profile requires a valid completion to follow the
same interactions as the abstract process, with the partners that are specified
by the abstract process. The executable process may, however, perform
additional interaction steps relating to other partners.
Therefore:
a completion MUST NOT change the presence or order of
interactions already in the abstract process, and it MUST NOT perform
additional interactions with the partner links defined in the abstract process.
It is important to observe that one way in which that
the order of interactions can be modified is by changing the value
of a variable used in a condition that affects branching. The condition could
be changed in such a way that the new so
that the new effective branching behavior is in direct conflict
with what is specified by the abstract process. Conditions that affect the flow
of control such as transition conditions, “if-then” or “while”
expressions, among others, can have such an effect on the order of
interactions. For example, adding a new <while> loop with a
“true” condition as a child of an existing <sequence> would
hang the process. In this profile, we will not restrict writing to variables in
a strict manner, but provide this note as an advisory restriction.
The
possible locations of new activities are not explicitly defined in this
profile. Activities may be added anywhere that the Executable
Completions definition (not Basic) allows, where completions to
the base are allowed, as long as the restrictions enumerated below
are followed. In this profile, the valid executable completions of an abstract
process are obtained through both 'opaque token replacement' and 'addition of
BPEL constructs', with the following restrictions:
·
New activities (including those
created to replace opaque activities) MUST NOT interact with partnerLinks already defined in the abstract process. This
rule does not affect adding interactions with new partnerLinks
present in the executable completion but not in the abstract process.
·
The endpoint reference of any partnerLink defined in the abstract process MUST NOT be
modified (whether using an <assign> activity or otherwise). Additionally,
an endpoint reference of any partnerLink defined in
the abstract process MUST NOT be copied into the
reference of a newly created partnerLink. The reason is that the former would effectively
prevent subsequent interactions with that partner and the latter would add new
ones. Remember that 'opaque token
replacement' also replaces opaque tokens omitted through the omission-shortcut.
·
The lexical parent of an
existing BPEL construct (including activities in particular) present in the
abstract process MUST NOT be changed in a valid
executable completion. Hence, the nesting structure of composite activities
around any activity in an abstract process MUST remain unchanged in any legal
completion. Some examples to illustrate this restriction are provided below.
The word ‘existing’ is used in the examples to refer to constructs
defined in the abstract process from which the executable completions are being
created:
o Examples of legal additions:
§
Adding a variable or a partner
link to an existing scope S, even though that scope is the parent of existing
activity A.
§
Adding a new link def to an
existing flow.
o Examples of illegal additions:
§
Adding a <while> activity
around the existing activity A whose parent is another existing activity B.
§
Adding a new scope around an
existing variable definition whose parent is an existing scope S.
·
A valid executable completion MUST
NOT add:
o 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.
o New branches to an existing pick activity.
o New fault, compensation, or termination handlers to an existing scope.
However, they may be added at the process level.
o <exit> activities.
·
Activities that throw non-standard
faults MAY be added only if the exception will not be propagated outside of the
highest newly added ancestor of the
fault-throwing activity. For example,
consider adding an activity A as a child of an existing sequence S. Then, one may only add a <throw> within
A if the fault it throws does not reach the scope of the existing sequence S.
In other words, the fault must be caught and fully handled by A or its descendants, and not be re-thrown by them.
Observe
that executable completions MUST NOT add new links targeting an activity that
exists in the abstract process. Adding such a new link would have the effect of
changing the corresponding join condition, which is in violation of the completion
rules of the base (since it modifies a non-opaque existing value). This
restriction does not affect the addition of links to new activities that are
not replacing opaque activities.