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


Do you mean that DPE always ends at "an explicit join condition"?  Every 
activity in a flow has at least an implicit join condition.  While I 
agree that an implementation can do what you describe, the especially 
pathological case that I describe doesn't even meet the (implied) 
semantics of the word "join," since there is only one control path.  I 
am bothered more by the ability to create extremely confusing semantics 
than by any non-implementability.

Danny

Dieter Koenig1 wrote:

>
>
>Formally, I see no problem as DPE always ends at a join condition, so the
>effect caused by the "SecondToThird" transition is perfectly valid. Maybe
>this is something that should be made more clear in the spec language.
>Kind Regards
>DK
>
>
>
>                                                                           
>             Danny van der                                                 
>             Rijn                                                          
>             <dannyv@tibco.com                                          To 
>             >                         andrew.francis@mail.mcgill.ca       
>                                                                        cc 
>             26.01.2005 22:23          wsbpel@lists.oasis-open.org         
>                                                                   Subject 
>                                       Re: [wsbpel] Dead Path Elimination  
>                                       and Join Conditions                 
>                                                                           
>                                                                           
>                                                                           
>                                                                           
>                                                                           
>                                                                           
>
>
>
>
>The contradiction is one of semantics.  There can be no "dead paths" in
>such a case, since a join condition later in the path can "resuscitate" the
>path.
>
>The sentinel case you describe can easily be coded differently, say as the
>2nd activity in a sequence, where the first is a flow.  After the flow
>completes, the sentinel can check conditions.  Of course, it can't check
>link status, but I don't see that as a huge obstacle.
>
>Danny
>
>andrew.francis@mail.mcgill.ca wrote:
>      Hello Danny:
>
>
>            This is in contradiction with my understanding of
>            dead-path elimination. I would prefer to disallow
>            joinConditions whose expression does not require a
>            true input in order that the join condition evaluate
>            to true. Comments?
>
>
>      I do not see how your example contradicts sections
>      12.5.1 (link semantics) or 12.5.2 (dead path elimination)?
>      I think your example is strange but not pathological.
>      Let us pretend the programmer does not like fault handlers
>      and structured the process as a graph with one end activity:
>      Third. In turn, the programmer wants activity "Third" to
>      be a sentinel or assert of sorts, executing only if activity
>      "Second" failed. If my understanding is correct, if "Second"
>      executes and sets "secondToThird"'s transitionCode to true,
>      Third's joinCondition will evaluate to false, not run, and
>      the process is finished: after all nothing bad happened ....
>      and this is what the programmer intended.
>      Cheers,
>      Andrew
>
>
>
>
>
>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
>.
>
>
>  
>


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