wsbpel message

Subject: RE: [wsbpel] Issue - 272 - Status of links after error in transitionCondition

From: "Mark Ford" <mark.ford@active-endpoints.com>
To: <wsbpel@lists.oasis-open.org>
Date: Mon, 1 May 2006 13:11:29 -0400

This issue was opened and closed during the San Jose face to face. The submitters proposal was accepted with a slight edit. The last sentence of the proposed text was moved to the previous paragraph.

From: ws-bpel issues list editor [mailto:peter.furniss@erebor.co.uk]
Sent: Friday, April 28, 2006 7:51 PM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Issue - 272 - Status of links after error in transitionCondition

This issue has been added to the wsbpel issue list with a status of "received". The status will be changed to "open" if a motion to open the issue is proposed and that motion is approved by the TC. A motion could also be proposed to close it without further consideration. Otherwise it will remain as "received".

The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent version of the document entitled in the "Issues" folder of the WSBPEL TC document list - the next posting as a TC document will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL.

Issue - 272 - Status of links after error in transitionCondition

Status: received
Date added: 28 Apr 2006
Date submitted: 28 April 2006
Submitter: Mark Ford
Description: Section 11.6.2 states that when an activity has multiple outgoing links, the order in which the status of the links and the associated transition conditions are evaluated is defined to be sequential, according to the order the links are declared in the <source> element.

The resolution for Issue 169 added text that stops the evaluation of the remaining links after the first fault. These other links will remain in an unset state. The problem is that these other links may cross the boundary of the scope that catches the fault and leave the target activities in a state where they'll never be executed due to the status of their links being unset.

Consider the following example:

<flow name="F1"> 
   <links> 
      <link name="linkE1_causesFault"/> 
      <link name="linkE2_neverEvaluated"/> 
   </links> 
   <scope name="S1"> 
      <flow name="F2"> 
         <empty name="E1"> 
            <sources> 
               <source linkName="linkE1_causesFault"> 
                  <transitionCondition> 
                      --- some expression that faults --- 
                  </transitionCondition> 
                   </source> 
               <source linkName="linkE2_neverEvaluated"/> 
            </sources> 
         </empty> 
         <empty name="E2"> 
            <targets> 
               <target linkName="linkE1_causesFault"/> 
            </targets> 
         </empty> 
      </flow> 
      <faultHandlers><catchAll>...</catchAll></faultHandlers> 
   </scope> 
   <empty name="E3"> 
      <targets> 
         <target linkName="linkE2_neverEvaluated"/> 
      </targets> 
   </empty> 
</flow>

Here are the steps:

E1 completes normally.
E1's links are evaluated sequentially
The first link named "linkE1_causesFault" contains a transitionCondition that faults when it executes.
The remaining outbound links for E1 MUST NOT be evaluated and remain in unset state (as does the link that faulted)
Scope S1 catches the fault and does nothing
S1 completes
Flow F1 cannot complete until E3 completes or goes dead path. E3 will not complete or go dead path until the state of its links are known.

This same section contains text that handles the case of the faulting link crossing a scope boundary. In this case, the link is set to false instead of being left in the unset state. This same text should apply to all of the unevaluated links that cross a scope boundary.
Submitter's proposal:

Change the text introduced by Issue 169's resolution to account for unevaluated links that cross a scope boundary by requiring that they be set to false.

From:

If an error occurs while evaluating the transition condition of one of an activity's outgoing links, then all remaining outgoing links from that activity as well as their associated transition conditions MUST NOT be evaluated. There is no difference in the status of the link that faults on transition condition evaluation and one whose transition condition has not been evaluated.

To:

If an error occurs while evaluating the transition condition of one of an activity's outgoing links, then all remaining outgoing links with targets within the source activity's enclosing scope MUST NOT have their transition conditions evaluated and remain in the unset state. If the target of a remaining outgoing link is outside the source activity's enclosing scope then the status of the link MUST be set to false. There is no difference in the status of the link that faults on transition condition evaluation and one whose transition condition has not been evaluated.

Changes: 28 Apr 2006 - new issue

To comment on this issue (including whether it should be accepted), please follow-up to this announcement on the wsbpel@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - 272 - [anything]" or is a reply to such a message. If you want to formally propose a resolution to an open issue, please start the subject line "Issue - 272 - Proposed resolution", without any Re: or similar.

To add a new issue, see the issues procedures document (but the address for new issue submission is the sender of this announcement).

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