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