OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue 82.3 - Missing Section




Hi,

My comments on top of Rania's and Danny's text are listed below in BLUE:

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

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.

 

In order to achieve the intent of the profile, 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 oOne such illegal [AYIU: I am not sure "illegal" is the right word here ... Because, this profile does not exactly outlaw it. I would suggest to say just "One way"] way in which that the order of interactions can could 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. This profile does not normatively disallow such actions, as it would be too restrictive.  However, the intent of this advisory note should be followed.  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 refer to 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.  New partnerLink declarations that would hide existing ones, thereby changing the partnerLink to which an existing activity refers MUST NOT be used.

 

·        vdRNOTE:  This bullet is completely subsumed by the one before.  Remove it or add it as a note to the previous.  [AYIU: agree with Danny here. Merging it as an elaboration note to the above bullet seems make it flow better.] 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. [AYIU: This is a normative change here. I am not sure this fits the original intent of this profile.]

·  vdRNOTE: Moved from below.  Executable completions MUST NOT add new links targeting an existing 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.

 

·        The lexical parent of an existing BPEL construct (including activities in particular) present in the abstract process MUST NOT be changed in an valid executable completion. Hence, the nesting structure of composite activities around any activity in an abstract process MUST 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:

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, except as disallowed above.

§         Adding a new link def to an existing flow, except as disallowed above

o       Examples of illegal additions:

§         Adding a <while> activity around the existing activity A whose parent is another existing activity B.  vdRNOTE:  if A exists, it already must have an existing parent B

§         Adding a new scope around an existing variable definition whose parent is an existing scope S.  vdRNOTE:  as above.

 

·        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 (i.e. (e.g.?) web service activities whose operations define faults, <throw>) MAY be added only if the exception will not be propagated outside of the highest newly added ancestor of the fault-throwing activity to any existing 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.

 

vdrNOTE:  moved to above.  Observe that eExecutable completions MUST NOT add new links targeting an existing 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.

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

Thanks!

Regards,
Alex Yiu


Danny van der Rijn wrote:
My suggestions for edits are in green below.

Rania Khalaf wrote:
Hi,

A section was mistakenly dropped from the 82.3 resolution. I am attaching it below, with some minor editing fixes (track changes is on).

I am also adding it to the docs list on the web page and here is the link to it.

http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/18359/82.3-lost-section.htm




Web Services Business Process Execution Language

 

 

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 oOne such illegal way in which that the order of interactions can could 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. This profile does not normatively disallow such actions, as it would be too restrictive.  However, the intent of this advisory note should be followed.  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 refer to 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.  New partnerLink declarations that would hide existing ones, thereby changing the partnerLink to which an existing activity refers MUST NOT be used.

 

·        vdRNOTE:  This bullet is completely subsumed by the one before.  Remove it or add it as a note to the previous.  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.

·  vdRNOTE: Moved from below.  Executable completions MUST NOT add new links targeting an existing 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.

 

·        The lexical parent of an existing BPEL construct (including activities in particular) present in the abstract process MUST NOT be changed in an valid executable completion. Hence, the nesting structure of composite activities around any activity in an abstract process MUST 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:

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, except as disallowed above.

§         Adding a new link def to an existing flow, except as disallowed above

o       Examples of illegal additions:

§         Adding a <while> activity around the existing activity A whose parent is another existing activity B.  vdRNOTE:  if A exists, it already must have an existing parent B

§         Adding a new scope around an existing variable definition whose parent is an existing scope S.  vdRNOTE:  as above.

 

·        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 (i.e. (e.g.?) web service activities whose operations define faults, <throw>) MAY be added only if the exception will not be propagated outside of the highest newly added ancestor of the fault-throwing activity to any existing 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.

 

vdrNOTE:  moved to above.  Observe that eExecutable completions MUST NOT add new links targeting an existing 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.

 

 


--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]