OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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


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.


S/MIME Cryptographic Signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]