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

["Dumas, Marlon" <marlon.dumas@sap.com>]

Hi Satish

You're right. The sentence that I proposed needs to be re-worded. Please let me have a second try:

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 an activity B will not start if there is an activity A upon which B has a control dependency, such that activity A has started and has not yet completed. For a definition of 'control dependency' see Section 13.4.2."

The reason why the current formulation requires clarification is the following. The existing sentence says that an activity cannot start until all its incoming links have been determined. Fine. But suppose that at a given point during the execution, the BPEL engine detects that the join condition associated to a given activity B will necessarily evaluate to false, even though some of the B's incoming links have not yet been determined. This can be the case for example if the join condition is 'False' (i.e. the expression that always evaluates to false). The question is: Can the BPEL engine immediately raise the 'bpws:joinFailure' at this point in time without waiting for all the incoming links to be determined? 
If this "optimization" is allowed and the bpws:joinFailure is raised, then activity B is skipped (assuming suppressJoinFailure="yes") and negative values are immediately propagated along its outgoing links. These links thus become "determined", and this may in turn cause some of the activities that follow activity B to start, even though there are still some activities preceding activity B that are still "executing".

If some BPEL implementations perform this optimization and others don't, then there will be BPEL implementations which exhibit different behaviours (i.e. different execution orderings) for the same process definitions, thus creating interoperability issues. The new clarifying sentence will prevent this interpretation. The clarifying sentence is also consistent with the operational semantics defined in paragraphs 6 and onwards of section 12.5.1, where it is implied that bpws:joinFailure is only be raised after all the incoming links have been determined.

Kind regards

marlon

-----Original Message-----
From: Satish Thatte
To: Assaf Arkin; Dumas, Marlon
Cc: wsbpel@lists.oasis-open.org; Frank.Leymann@informatik.uni-stuttgart.de; andrew.francis@mail.mcgill.ca
Sent: 3/3/2005 2:16 PM
Subject: RE: [wsbpel] Issue 193: Clarify why the spec mandates that JoinConditions must always be evaluated only after all source activities complete

" .. 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
>
>