RE: [wsbpel] Issue 193: Clarify why the spec mandates that JoinConditions must always be evaluated only after all source activities complete

["Satish Thatte" <satisht@microsoft.com>]

" .. all the activities that precede the activity in question have
completed" is not actually required since some preceding activities may
never be executed and yet the join condition evaluates to TRUE.  I
thought the original sentence was complete already (and not only because
I wrote it :-)).

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com] 
Sent: Tuesday, March 01, 2005 7:22 PM
To: Dumas, Marlon
Cc: wsbpel@lists.oasis-open.org;
Frank.Leymann@informatik.uni-stuttgart.de; andrew.francis@mail.mcgill.ca
Subject: Re: [wsbpel] Issue 193: Clarify why the spec mandates that
JoinConditions must always be evaluated only after all source activities
complete

+1

assaf

Dumas, Marlon wrote:

>Hi Assaf,
>
>I agree with you that this optimization could lead to behaviors that
some may find confusing or counter-intuitive. Allowing BPEL
implementations to perform this optimization could also make the
analysis of BPEL processes more difficult.
>
>Accordingly, I suggest to address issue 193 as follows:
>
>In section 12.5.1, just after the following sentence:
>
>"If an activity that is ready to start in this sense has incoming
links, then it does not start until the status of all its incoming links
has been determined and the (implicit or explicit) join condition
associated with the activity has been evaluated."

>
>..insert the following sentence:
>
>"The purpose of this rule is to ensure that the activity in question
and any other activities that have a control flow dependency on this
activity are not started until all the activities that precede the
activity in question have completed. For a definition of 'control flow
dependency' see Section 13.4.2)."
>
>As Andrew points out, there may still be room for optimizing the moment
of evaluation of join conditions (which is good), but only insofar as
the "control dependencies" entailed by the control links in the process
definition are preserved.
>
>Cheers
>
>marlon
>
>-----Original Message-----
>From: Assaf Arkin
>To: Dumas, Marlon
>Cc: wsbpel@lists.oasis-open.org;
Frank.Leymann@informatik.uni-stuttgart.de; andrew.francis@mail.mcgill.ca
>Sent: 3/1/2005 7:14 PM
>Subject: Re: [wsbpel] Issue 193: Clarify why the spec mandates that
JoinConditions must always be evaluated only after all source activities
complete
>
>Dumas, Marlon wrote:
>
>  
>
>>In order to address issue 193, the last paragraph of this quote (with
>>some re-wording) could be included in the spec.
>>An interesting point about the above formulation is that, while it
>>precludes the activity after the join condition to be started before
>>    
>>
>all
>  
>
>>incoming links have been determined, it does not preclude a BPEL
engine
>>    
>>
>>from determining to "skip" the activity after the join condition and
to
>  
>
>>propagate false values along its outgoing links, as soon as it can be
>>determined that the truth condition will evaluate to FALSE no matter
>>what. In the last paragraph of your e-mail dated 15 February Re: issue
>>189, you suggested that this latter "optimization" is okay. I insist
>>that the question is to determine whether this "optimization" should
be
>>allowed or not. If it is allowed, then the above formulation is OK (or
>>the formulation that I suggested in my previous e-mail as well). If
>>    
>>
>this
>  
>
>>optimization is not allowed, then the above formulation should be
>>expanded to preclude it.
>> 
>>
>>    
>>
>I think this optimization will be confusing, and we should not allow
it.
>
>Consider the case where activity C has the join condition 'A or B' (A 
>and B referring to two other activities), and activity D has the join 
>condition 'C'. If activity A has completed successfully, activity C
must
>
>still wait for activity B to complete, even though the link status will

>not affect the decision to execute C (and subsequently D).
>
>If C has the join condition 'A and B', and D has the join condition 
>'not(C)', then again activity C must wait for both A and B to complete.

>However, if we allow this optimization, then as soon as activity A 
>completes unsuccessfully, activity D is allowed to execute, even though

>activity B has not completed yet.
>
>
>Assaf
>
>
>  
>
>>Cheers
>>
>>marlon
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>>
>>
>> 
>>
>>    
>>
>
> <<SMIME.txt>> 
>
>  
>