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 - 188 - Dead Path Elimination and Join Conditions


The problem may lie with interpretion of the phrase "dead-path 
elimination", especially the term "path". This implies that something 
pathlike is being eliminated. I for one think of paths in graphs as 
usually having more than one node, which isn't really how DPE works. The 
example shows that DPE is more accurately termed "dead activity 
elimination,"  although more conventional use of links does indeed lead 
to something pathlike being eliminated.

Is the above holds true, then the question is, is the phrase "dead-path 
elimination" so misleading that we should change it?

-Ron

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

S/MIME Cryptographic Signature



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