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


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]