[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
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]