[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
+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>> > > >
begin:vcard fn:Assaf Arkin n:Arkin;Assaf org:Intalio adr;dom:;;1000 Bridge Parkway Ste 210;Redwood City;CA;94065 email;internet:arkin@intalio.com title:Chief Architect tel;work:(650) 596-1800 x-mozilla-html:TRUE url:http://www.intalio.com version:2.1 end:vcard
S/MIME Cryptographic Signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]