[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 JoinConditions must always be evaluated only after all source activities complete
+1 -----Original Message----- From: Assaf Arkin [mailto:arkin@intalio.com] Sent: Tuesday, March 01, 2005 10:14 AM 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 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 > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]