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






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]