Re: [wsbpel] Issue 27 - Proposal to vote - Setting link status incase of transitioncondition

[Assaf Arkin <arkin@intalio.com>]

Maciej Szefler wrote:

>Isn't a transition
>condition generating an exception indicative of a faulty process definition?
>Is it realistic for process designers to handle such exceptions?
>  
>
Yes and no.

I would say that transition conditions are definitely expressions that 
are not intended to fault. If there's complex work to be done to 
determine the value of the transition, which by nature of being complex, 
should lead to a fault, it is best done as a separate step (e.g. using 
<assign>) and its values used in the transition condition. So ideally 
transition conditions would never fault and we would never run into this 
problem.

However, to make that practical a transition condition must be very 
limited as far as expression goes. For example, it may be a binary 
expression using variables with no other XPath capabilities (much like a 
join condition), in which case all errors could be determined 
statically. In fact, one possible solution we overlooked is to make 
transition conditions so simplified they would never fault, probably 
because we expect them to be that simplified in practice.

If we allow XPath to be used in its entirety than it's possible that a 
transition condition would fault inspite of the best intentions of the 
designer. A trivial example:

  getVariable('workload')/getVariable('workers') > 
getVariable('interventionRequired')

is a valid transition condition. Which will fault if 
getVariable('workers') is zero. Once we allow faults to occur we need at 
the minimum to provide a base assumption as to how they are handled. If 
we don't expect faults to happen regularly then we can make a 
not-so-optimal solution, in this case I would say that anything that 
works and is simple to define is good enough. But it has to be well 
defined because if not well defined, there's always the possibility that 
one implementation would fault in one way, and another implementation 
would not fault at all but execute some (but not all) of the target 
activities, or any other unpredictable behavior.

And of course, is some behavior is prescribed, expect it to be used 
intentionally by some process designer to get a specific behavior out of it.

arkin

>-maciej
>
>
>
>----- Original Message ----- 
>From: "Assaf Arkin" <arkin@intalio.com>
>To: "Satish Thatte" <satisht@microsoft.com>
>Cc: "Ron Ten-Hove" <Ronald.Ten-Hove@Sun.COM>; <wsbpel@lists.oasis-open.org>
>Sent: Monday, October 20, 2003 7:22 PM
>Subject: Re: [wsbpel] Issue 27 - Proposal to vote - Setting link status in
>case of transitioncondition
>
>
>  
>
>>Satish Thatte wrote:
>>
>>    
>>
>>>Assaf,
>>>
>>>As Ron points out, the setting of link status is meaningful only after
>>>the evaluation of the transition condition is completed.  When a fault
>>>occurs in the scope within which the condition is to be evaluated,
>>>before the evaluation of the condition is complete, the link status is
>>>always set to false.  This is quite independent of the nature and source
>>>of the fault, and there is nothing special about the faults that may
>>>occur within transition conditions as far as this rule is concerned.
>>>Again, this matters only when the corresponding link is leaving the
>>>scope that faulted.
>>>
>>>
>>>      
>>>
>>I understand the intent, but I'm not sure if the text makes that point
>>clear. The way the spec is written that would be true for all the
>>activities that have not completed, but we're at a point where the
>>activity has completed but the transition condition is being evaluated,
>>and I don't think the text clarifies that point. Hopefully it does after
>>we introduce the change discussed by this issue. But it's hard for me to
>>see, since I understand the intent, I may be reading too much into it.
>>
>>The current text as far as I read it does not explicitly state that if
>>two transitions conditions exist for the same activity and one generates
>>a fault, both would set the link status to false. The intent may be
>>there, but if another interpretation is possible, we need to clarify that.
>>
>>    
>>
>>>I would not exactly say that "the transition condition is always
>>>evaluated by the enclosing construct" although the idea is correct.
>>>Conditions are not evaluated by a construct.  I think the most
>>>meaningful thing to say is that "transition conditions are evaluated in
>>>the scope immediately enclosing the source activity of a link".
>>>
>>>
>>>      
>>>
>>Consider the case where a <flow> nested within another <flow> enclosed
>>in a scope, and both flows declare a link with the same name. Currently
>>this behavior is not prohibited. Now the question becomes how the scope
>>evaluates these two links with the same name? Obviously the intent could
>>be that those are two different links inspite of having the same name,
>>but there could be other interpretations of the spec. I think it's safe
>>to conclude at this point that some readers would get horribly confused
>>by this without further clarification.
>>
>>arkin
>>
>>    
>>
>>>Satish
>>>
>>>-----Original Message-----
>>>From: Assaf Arkin [mailto:arkin@intalio.com]
>>>Sent: Saturday, October 18, 2003 6:43 PM
>>>To: Satish Thatte
>>>Cc: Ron Ten-Hove; wsbpel@lists.oasis-open.org
>>>Subject: Re: [wsbpel] Issue 27 - Proposal to vote - Setting link status
>>>in case of transitioncondition
>>>
>>>Would it be fair to say that the transition condition is always
>>>evaluated by the enclosing construct?
>>>
>>>In other words, if activity X is a source activity and has a transition
>>>condition, and is encapsulated by activity Y, then activity Y is in fact
>>>
>>>responsible to evaluate the transation condition using the variables
>>>accessible in its scope and throw a fault if the transition condition
>>>fails? An enclosing construct may also refuse to evaluate any transition
>>>
>>>conditions (e.g. a while activity or an event handler).
>>>
>>>Another point that I don't think was answered so far is what happens
>>>when there are two transition conditions and a fault occurs when
>>>evaluating one of them? Are both of them set to false, or only the one
>>>that generated a fault? I believe for consistency both of the links
>>>should have their status set to false.
>>>
>>>arkin
>>>
>>>Satish Thatte wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>You are right, my sentence is misleading.  The link status is false
>>>>because of the fault not because the transition condition is not yet
>>>>evaluated.  Thanks for the correction.  Incidentally, the link status
>>>>matters only if the link target is outside the scope that faulted.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>------------------------------------------------------------------------
>>>
>>>
>>>      
>>>
>>>>*From:* Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
>>>>*Sent:* Friday, October 17, 2003 1:22 PM
>>>>*To:* Satish Thatte
>>>>*Cc:* wsbpel@lists.oasis-open.org
>>>>*Subject:* Re: [wsbpel] Issue 27 - Proposal to vote - Setting link
>>>>status in case of transitioncondition
>>>>
>>>>
>>>>
>>>>Satish Thatte wrote:
>>>>
>>>>The link status issue is really more general than this as Goran
>>>>pointed out during the call.  A scope can always fault in an unrelated
>>>>
>>>>
>>>>        
>>>>
>>>
>>>      
>>>
>>>>place while one or more transition conditions within it are being
>>>>evaluated, in this case, transition conditions on other links sourced
>>>>at the same source scope.  It is impossible to specify the exact
>>>>behavior in such races in the presence of true (multi-processor)
>>>>concurrency.  If the evaluation of the conditions is not complete
>>>>(i.e., the link has not actually set its status) then the link status
>>>>is False.  In the case of the fault occurring in the evaluation of the
>>>>
>>>>
>>>>        
>>>>
>>>
>>>      
>>>
>>>>transition condition itself the evaluation of the condition is not
>>>>complete and therefore the link status is False.
>>>>
>>>>My understanding is that links are tri-state: empty, true, or false.
>>>>Until the transition condition is evaluated, the link remains marked
>>>>as empty, not false as you suggested. Faulting the scope should case
>>>>the link given in this case to marked as false, as part of dead-path
>>>>elimination.
>>>>
>>>>-Ron
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>------------------------------------------------------------------------
>>>
>>>
>>>      
>>>
>>>>*From:* Prasad Yendluri [mailto:pyendluri@webmethods.com]
>>>>*Sent:* Thursday, October 16, 2003 3:48 PM
>>>>*To:* Ashwini Surpur; Assaf Arkin
>>>>*Cc:* wsbpel@lists.oasis-open.org <mailto:wsbpel@lists.oasis-open.org>
>>>>*Subject:* Re: [wsbpel] Issue 27 - Proposal to vote - Setting link
>>>>status in case of transitioncondition
>>>>
>>>>
>>>>
>>>>True. This aspect was clarified in the discussions related to this
>>>>issue but did not make into the
>>>>proposed resolution (we voted on!).
>>>>
>>>>I also see the need to address what the status of the link ends up
>>>>being in this scenario. The
>>>>obvious answer seems to that "a transition condition evaluation error
>>>>would be same as the
>>>>transition condition having evaluated to 'not ture'/false'." But, I
>>>>somehow feel some will not
>>>>see it this way. In any case we need to make a definitive statement
>>>>here and not leave a
>>>>loose end dangling.
>>>>
>>>>Regards, Prasad
>>>>
>>>>-------- Original Message --------
>>>>
>>>>*Subject: *
>>>>
>>>>
>>>>
>>>>Re: [wsbpel] Issue 27 - Proposal to vote - Setting link status in case
>>>>
>>>>
>>>>        
>>>>
>>>
>>>      
>>>
>>>>of transitioncondition
>>>>
>>>>*Date: *
>>>>
>>>>
>>>>
>>>>Thu, 16 Oct 2003 13:18:25 -0700
>>>>
>>>>*From: *
>>>>
>>>>
>>>>
>>>>Ashwini Surpur <ashwini.surpur@oracle.com>
>>>><mailto:ashwini.surpur@oracle.com>
>>>>
>>>>*Organization: *
>>>>
>>>>
>>>>
>>>>Oracle Corporation
>>>>
>>>>*To: *
>>>>
>>>>
>>>>
>>>>Assaf Arkin <arkin@intalio.com> <mailto:arkin@intalio.com>
>>>>
>>>>*CC: *
>>>>
>>>>
>>>>
>>>>wsbpel@lists.oasis-open.org <mailto:wsbpel@lists.oasis-open.org>
>>>>
>>>>
>>>>
>>>>Also from the discussion on issue 27 I get that the local variables of
>>>>
>>>>
>>>>        
>>>>
>>>the scope
>>>
>>>
>>>      
>>>
>>>>cannot be used to evaluate the transition condition of the links and
>>>>
>>>>
>>>>        
>>>>
>>>only the
>>>
>>>
>>>      
>>>
>>>>variables of the parent scope should be used. This needs to be
>>>>
>>>>
>>>>        
>>>>
>>>documented
>>>
>>>
>>>      
>>>
>>>>explicitly as well.
>>>>
>>>>
>>>>
>>>>-Ashwini
>>>>
>>>>
>>>>
>>>>Assaf Arkin wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>Proposal to resolve issue 27 by adding the following paragraph to the
>>>>>
>>>>>
>>>>>specification in the description of how links are handled (pages
>>>>>
>>>>>
>>>>>          
>>>>>
>>>64/65):
>>>
>>>
>>>      
>>>
>>>>>Note that the transition condition is evaluated after the activity
>>>>>
>>>>>
>>>>>          
>>>>>
>>>has
>>>
>>>
>>>      
>>>
>>>>>completed. If an error occurs while evaluating the transition
>>>>>
>>>>>
>>>>>          
>>>>>
>>>condition,
>>>
>>>
>>>      
>>>
>>>>>that error does not affect the completion status of the activity and
>>>>>
>>>>>
>>>>>          
>>>>>
>>>is
>>>
>>>
>>>      
>>>
>>>>>handled by the activity's enclosing scope. In the case of
>>>>>
>>>>>
>>>>>scopes, completion does not necessarily imply successful completion.
>>>>>
>>>>>
>>>>>          
>>>>>
>>>A
>>>
>>>
>>>      
>>>
>>>>>scope may suffer an internal fault and yet complete (unsuccessfully)
>>>>>
>>>>>
>>>>>          
>>>>>
>>>if
>>>
>>>
>>>      
>>>
>>>>>there is a corresponding fault handler associated with the scope and
>>>>>
>>>>>
>>>>>that fault handler completes without throwing a fault.
>>>>>
>>>>>
>>>>>arkin
>>>>>
>>>>>
>>>>>(This is the same proposal sent on Sep 30, resent for your
>>>>>
>>>>>
>>>>>          
>>>>>
>>>convenience)
>>>
>>>
>>>      
>>>
>>>>
>>>>
>>>>
>>>>
>>>>-----------------------------------------------------------------------
>>>>
>>>>
>>>>        
>>>>
>>>-
>>>
>>>
>>>      
>>>
>>>>To unsubscribe from this mailing list (and be removed from the roster
>>>>
>>>>
>>>>        
>>>>
>>>of the OASIS TC), go to
>>>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
>>>oup.php.
>>>
>>>
>>>      
>>>
>>>>-----------------------------------------------------------------------
>>>>
>>>>
>>>>        
>>>>
>>>-
>>>
>>>
>>>      
>>>
>>>>To unsubscribe from this mailing list (and be removed from the roster
>>>>
>>>>
>>>>        
>>>>
>>>of the OASIS TC), go to
>>>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
>>>oup.php.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>To unsubscribe from this mailing list (and be removed from the roster of
>>>      
>>>
>the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
>  
>
>>>      
>>>
>>
>>To unsubscribe from this mailing list (and be removed from the roster of
>>    
>>
>the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
>  
>
>>    
>>
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
>  
>


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.