Just to make sure I wasn't completely insane, I just checked WSFL, from
which BPEL's link semantics were drawn. From section 3.1.2.1:
Dead-path elimination has to take place whenever it becomes
clear that a particular activity
will never be performed. This is the case when a join condition of a
join activity evaluates to
false, or when the transition condition of an activity with exactly one
incoming control
connector evaluates to false. Originating from such an activity,
dead-path elimination has to
traverse the underlying flow model’s graph until the next join activity
or end activity is
reached.
During this traversal, all visited transition conditions have to be
assigned a truth-value of
false and have to be marked as evaluated. Assume that a join activity
is reached: When the
associated join condition can already be evaluated, this is done; if
the join condition
evaluates to true, the join activity can be performed, otherwise
dead-path elimination
continues. When the join condition of the join activity reached cannot
be evaluated yet, the
decision about whether or not the join activity will have to be
performed is deferred.
It is clear here that join conditions only make sense on join
activities (activities with more than one incoming link). So that's
50% of my issue. The other 50% is what join conditions are allowed to
evaluate to. I think that it's reasonable that we should follow WSFL's
link semantics. I also think, at the risk of beating a dead horse,
that if we deviate from those semantics, we should be explicit about it.
Danny
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.
|