Issue 82.3 - Missing Section

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

 

 Hi guys,

here is the missing section from 82.3, after Alex, Danny and I went through it over and over and over... and now it's off to the rest of the TC.

Danny didn't get a chance to read the very last (minor) changes.

If you want to see the diffs, please look at the word or pdf version here. The html below doesn't have them:

http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/18965/82.3-lost-section_EDITED.doc

http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/18966/82.3-lost-section_EDITED.pdf

------------------------

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. This section uses the term ‘existing’ to refer to  constructs present in an abstract process, and  the term ‘new’ to refer to those added to an abstract process while creating an executable completion.

 

In order to achieve the intent of the profile, 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. The completion rules provided below aim to enforce this restriction.

 

Data writing may cause changes in interaction order. Changes caused by data writing are not enforced by the completion rules, but are highlighted here as an advisory note. One example is changing the value of a variable used in a condition that affects branching, in such a way 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.

 

When creating an executable completion of an abstract process belonging to this profile, the possible locations for adding new activities are not explicitly defined: Activities may be added anywhere that the Executable Completions definition in section [todo: add xref here] allows  with the restrictions  below.

 

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 declared 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.  New partnerLink declarations that would hide existing ones, thereby changing the partnerLink to which an existing activity refers MUST NOT be used.

[Last sentence on “New partnerLink …” depends on accepting proposed resolution of 302]

 

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

 

• New variable declarations that would hide existing ones, thereby changing the branching  behavior MUST NOT be used.

[Normative change: assumes/depends on adoption of 302 proposed resolution]

 

• The lexical parent of an existing BPEL construct (including activities in particular) present in the abstract process MUST NOT be changed in an executable completion. Hence, the nesting structure of composite activities around any activity in an abstract process remains 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:
• 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, except as disallowed above.
• Adding a new link definition to an existing flow, except as disallowed above.
• Examples of illegal additions:
• Adding a <while> activity around an existing activity.
• Adding a new scope around an existing variable definition.

 

• A valid executable completion 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> activities.

o       New links whose targets are existing activities. The Executable Completions definition in the Base already disallows adding new links to existing activities that have existing links and use the default join condition. This profile restricts this further by disallowing the addition of new links to any existing activity. However, one may freely add links targeting new activities as long as those activities are not a replacement of one of the abstract process’s opaque activities.

[TODO: This text on links refers to a new clarification to the EC Base definition sent as separate email]

 

• Activities that throw non-standard faults (e.g.web service activities whose operations define faults, <throw>) MAY be added only if the exception will not be propagated to any activity existing in the Abstract Process.  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.

 

Recall from the definition of Executable Completion in the Base that if a construct is optional and has a default value, then the construct needs to be explicitly opaque, in order to allow Executable Completion to specify its value. One example that highlights that is an Abstract Process with a <receive> activity or other IMA that does not have the createInstance attribute. Such an activity is always treated as a non-start activity, an Execution Completion cannot add "createInstance=yes" to it.  If one wants to make a <receive> activity or other IMA optionally become a start activity, the createInstance attribute has to be made explicitly opaque.

 

---