Re: [wsbpel] Issue - 188 - Dead Path Elimination and Join Conditions

[Danny van der Rijn <dannyv@tibco.com>]

The example is no longer eliminating "Dead *Paths*" but "Dead 
Activities."  That's the problem for me.  BTW, the "less pathological" 
case that I chose to ignore is where all inputs are true, but the 
joinCondition evaluates to false.  That, IMO, also fails the 
"joinCondition" semantic test, but seems to have a more valid use case, 
and doesn't tamper with the "Dead Path Elimination" semantic.

Danny

Yaron Y. Goland wrote:

> I gotta admit that I don't see the current state of the spec as being 
> a bug. I think that the example in the issue is not pathological or 
> even counter intuitive. Dead path elimination is simply an 
> optimization that allows one to skip having to execute activities when 
> one has sufficient information to determine that those activities can 
> never execute. In the example given in this issue dead path 
> elimination can clean up second but not third. That seems fine to me.
>
> I realize I'm quite likely being thick but I reviewed the entire 
> thread on this issue and I just don't see a problem.
>
>         Yaron
>
> Tony Fletcher wrote:
>
>> This issue has been added to the wsbpel issue list with a status of 
>> "received". The status will be changed to "open" if the TC accepts it 
>> as identifying a bug in the spec or decides it should be accepted 
>> specially. Otherwise it will be closed without further consideration 
>> (but will be marked as "Revisitable")
>>
>> The issues list is posted as a Technical Committee document to the 
>> OASIS WSBPEL TC pages 
>> <http://www.oasis-open.org/apps/org/workgroup/wsbpel> 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 
>> <http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php> - 
>> 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 
>> <http://www.choreology.com/external/WS_BPEL_issues_list.html>.
>>
>>    
>> -------------------------------------------------------------------------------- 
>>
>>
>>
>>     Issue - 188 - Dead Path Elimination and Join Conditions
>>
>> *Status:* received
>> *Date added:* 29 Jan 2005
>> *Categories:* State management 
>> <file:///C:/Perlscripts/wsbpel_issues30.html#category_state_management>
>> *Date submitted:* 27 January 2005
>> *Submitter:* Danny van der Rijn <mailto:dannyv@tibco.com>
>> *Description:* This is a question dealing with a pathological 
>> condition that the spec allows that I think we should disallow. 
>> Currently, it is legal to have a joinCondition which negates 
>> dead-path elimination. The simplest way to do this is to have an 
>> activity with one incoming link and whose joinCondition is 
>> not($incoming). A more detailed expression of this follows. Apologies 
>> if the syntax isn't quite right.
>>
>> <flow suppressJoinFailure="yes">
>>     <links>
>>        <link name="first2second"/>
>>        <link name="second2third"/>
>>     </links>
>>
>>     <someActivityname="first">
>>        <sources>
>>           <source linkName="first2second">
>>              <transitionCondition>
>>                 false
>>              </transitionCondition>
>>        </sources>
>>     </someActivity>
>>
>>     <someActivityname="second">
>>        <sources>
>>           <source linkName="second2third">
>>        </sources>
>>        <targets>
>>           <target linkName="first2second"/>
>>        </targets>
>>     </someActivity>
>>
>>     <someActivityname="third">
>>        <targets>
>>           <joinCondition>
>>              not(getLinkStatus("second2third"))
>>           </joinCondition>
>>           <target linkName="second2third"/>
>>        </targets>
>>     </someActivity>
>> </flow>
>>
>> A flow from first to second to third. The transition from "first" to 
>> "second" has some condition. If it is false, "second" will not 
>> evaluate. Yet according to my reading of the spec this merely sets 
>> the link status of "second2third" to false, which in turn causes 
>> "third" to execute.
>>
>> This is in contradiction with my understanding of dead-path elimination.
>>
>> *Submitter's proposal:* I would prefer to disallow joinConditions 
>> whose expression does not require a true input in order that the join 
>> condition evaluate to true. Comments?
>> *Links:*     Announcement, 29 Jan 2005 
>> <http://lists.oasis-open.org/archives/wsbpel/200501/msg00054.html>
>> *Changes:* 29 Jan 2005 - new issue
>>
>>  
>>
>> Best Regards,
>>
>> Tony/                           /
>>
>> / <http://www.choreology.com/>/
>>
>>     
>>
>> Tony Fletcher
>>
>> Technical Advisor
>> Choreology Ltd.
>> 68, Lombard Street, London EC3V 9L J   UK
>>
>> Phone:
>>     
>>
>> +44 (0) 1473 729537
>>
>> Mobile:
>>
>>     
>>
>> +44 (0) 7801 948219//
>>
>> Fax:  
>>     
>>
>> +44 (0) 870 7390077
>>
>> Web:
>>
>>     
>>
>> /www.choreology.com <http://www.choreology.com/>/
>>
>> Cohesions™
>>
>> Business transaction management software for application coordination
>>
>> Work: tony.fletcher@choreology.com
>>
>> Home: amfletcher@iee.org <mailto:amfletcher@iee.org>
>>
>>  
>
>
> 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. 
>
>
>