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 193: Clarify why the spec mandates that JoinConditionsmust 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.


>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org

fn:Assaf Arkin
adr;dom:;;1000 Bridge Parkway Ste 210;Redwood City;CA;94065
title:Chief Architect
tel;work:(650) 596-1800

S/MIME Cryptographic Signature

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