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