[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 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.
> >
> >
> >
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]