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


I think that at that point, we would need to eliminate the term 
"elimiation" as well, and just describe what join conditions are for, 
without trying to attribute any fancy names to the procedure of 
evaluating them.

Yaron Y. Goland wrote:

> If we were to change anything I would imagine it should be the name 
> dead-path-elimination. If we called it 
> 'unexecutable-activity-elimination' would that resolve any confusion?
>
>         Yaron
>
> Danny van der Rijn wrote:
>
>> If most people thought that the current behavior needs no change, then I
>> was going to propose that wording be added to explicitly allow
>> joinConditions to evaluate to true when all inputs are false, and vice
>> versa.
>>
>> Danny
>>
>> Yaron Y. Goland wrote:
>>
>>  > If you feel like doing the work to re-edit the text into something a
>>  > little less confusing I wouldn't have any objections.
>>  >     Yaron
>>  >
>>  > Danny van der Rijn wrote:
>>  >
>>  >> Every time I read the following paragraph, my feeling is reinforced.
>>  >> The only time that I would expect a join condition to evaluate to 
>> true
>>  >> (last sentence) is when an incoming link is true.  Yes, I am reading
>>  >> more into those words than exist.  Yet I still say that this is
>>  >> unclear.  The title of the section is about paths, which would 
>> make no
>>  >> sense otherwise.  However, I raised this point initially to gauge
>>  >> reactions, not to change opinions.  If the opinions are against 
>> me, I
>>  >> can accept that.  I guess we'll find out at the call.
>>  >>
>>  >> Danny
>>  >>
>>  >>
>>  >> 12.5.2. Dead-Path-Elimination (DPE)
>>  >>
>>  >> In cases where the control flow is largely defined by networks of 
>> links,
>>  >> the normal
>>  >> interpretation of a false join condition for activity A is that A 
>> should
>>  >> not be performed,
>>  >> rather than that a fault has occurred. Moreover, there is a need to
>>  >> propagate the
>>  >> consequences of this decision by assigning a negative status to the
>>  >> outgoing links for A.
>>  >> WS-BPEL makes it easy to express these semantics by using an 
>> attribute
>>  >> suppressJoinFailure on an activity. A value of "yes" for this 
>> attribute
>>  >> has the effect of
>>  >> suppressing the bpws:joinFailure fault for the activity and all 
>> nested
>>  >> activities, except
>>  >> where the effect is overridden by using the suppressJoinFailure
>>  >> attribute with a value
>>  >> of "no" in a nested activity. Suppressing the bpws:joinFailure is
>>  >> equivalent to the fault
>>  >> being logically caught by a special default handler attached to an
>>  >> implicit scope that
>>  >> immediately encloses just the activity with the join condition. The
>>  >> default handler
>>  >> behavior is an empty activity, that is, the handler suppresses 
>> the fault
>>  >> and does nothing
>>  >> about it. However, because the activity with the join condition 
>> was not
>>  >> performed, its
>>  >> outgoing links are automatically assigned a negative status 
>> according to
>>  >> the rules of Link
>>  >> Semantics. Thus within an activity with the value of the
>>  >> suppressJoinFailure attribute
>>  >> set to "yes", the semantics of a join condition that evaluates to 
>> false
>>  >> are to skip the
>>  >> associated activity and to set the status of all outgoing links from
>>  >> that activity to negative.
>>  >> This is called dead-pathelimination because in a graph-like
>>  >> interpretation of networks of
>>  >> links with transition conditions, these semantics have the effect of
>>  >> propagating negative
>>  >> link status transitively along entire paths formed by consecutive 
>> links
>>  >> until a join
>>  >> condition is reached that evaluates to true.
>>  >>
>>  >> Yaron Y. Goland wrote:
>>  >>
>>  >>  > Since the algorithm is an optimization (e.g. BPEL can run just 
>> fine,
>>  >>  > if slower, without it) and since it is not something that users
>>  >> should
>>  >>  > need be aware of I don't see a compelling case for changing the
>>  >>  > terminology. But I'm always open to a good argument.
>>  >>  >
>>  >>  >     Yaron
>>  >>  >
>>  >>  > Ron Ten-Hove wrote:
>>  >>  >
>>  >>  >> 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. 
>>
>>  >>
>>  >>  >>>
>>  >>  >>>
>>  >>  >>
>>  >>  >
>>  >>  > 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. 
>>
>>
>


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