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.
As soon as I read that last sentence, I was instantly reminded of the
Monty Python sketch featuring the "argument
clinic." In that spirit:
In the BPEL context, the word "path" suggests something we'd probably
model as a sequence: a set of concurrent activities constrained by a
single links: A1 -> A2 -> ... -> AN.
If the "path" becomes dead (a link in the path is marked as "negative")
at the completion of activity Aj, j < N, then all
activities Ak j < k <= N are marked as dead, since
they cannot be executed. [1]
This definition only holds if default join conditions are used. Under
such conditions a sequence is best used to model the behaviour desired.
A custom join condition, shown in Danny's example, causes the so-called
path to develop pot-holes. With default join conditions holding, it
seems that the use of <sequence> would predominate, and this
would be an uncommon pattern for concurrent activities. This is true
whether you take a textual or graphic view of the process definition.
The phrase "dead activity elimination" (DAE) is more accurate,
especially if it is defined in terms of a single activity. Indeed,
section 12.5.2 (DPE) states
"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 defined entirely in terms of the behaviour of a single activity
suffering a suppressed join failure, suggesting that
dead-activity-elimination is a more accurate phrase. It certainly seems
sufficient, given that it applies to all activities with outgoing
links. However, 12.5.2 does go on to justify the use of "path":
"This is called
dead-pathelimination[sic] 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."
which brings us back to the original problem: the simplistic
supposition that links will be used largely to define sequences! This
use of path is at best academic, and, as we have seen, at worst
misleading. The pragmatic answer to Danny's complaint is to switch to
more accurate terminology. Note that I am NOT suggesting that we change
existing BPEL behaviour (as understood by the majority, at least), but
simply improving on a phrase that apparently mislead the minority.
To summarize: we should
- Eliminate the sentence, quoted above, defining DPE.
- Rename the remaining occurences of DPE to DAE, and Dead Path
Elimination to Dead Activity Elimination.
Cheers,
-Ron
[1] Assuming join failures are suppressed.
[2] This is way more prose than this issue deserves, don't you think?
:-)
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.
|