[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 6.2 - Proposal For Vote
If we pass 147 and someone wants to defined 6 as an extension of 147 that's o.k. with me. But we should first pass 147. Satish Thatte wrote: > One concern with making all children scopes is that this is kinda > useless when your control flow is governed mostly by links, in the WSFL > style. This also creates additional concerns relating to compensation > order and the constraints imposed by the resolution of issue 10 on link > structure crossing scope boundaries. > > This is one reason why I had suggested limiting the early completion > proposal to the proposed parallel foreach construct, which, being a > specialized form of flow, can have more peculiar semantics, although I > am sure Yaron will not thank me for this suggestion :-) > > Satish > > -----Original Message----- > From: Yaron Y. Goland [mailto:ygoland@bea.com] > Sent: Tuesday, April 05, 2005 3:14 PM > To: Alex Yiu > Cc: wsbpel@lists.oasis-open.org; Trickovic, Ivana > Subject: Re: [wsbpel] Issue 6.2 - Proposal For Vote > > Requiring that all the children of the flows be scopes is just bizarre. > If such contortions are needed to make this proposal work then I would > humbly suggest that this proposal is not ready for approval. > > Yaron > > Alex Yiu wrote: > > Hi all, > > > > Ivana and I were still discussing an open technical issue about this > 6.2 > > proposal. That is: whether branches of <flow> should be restricted to > a > > scope-based only when <completionCondition> / earlyCompletion is used. > > > > However, since there is a Apr 1st deadline for proposal submission, it > may be > > better to submit the proposal on what was drafted so far without > waiting to > > resolve this open issue. And, let other people comment on this open > issue. > > > > Here is my detailed viewpoints and analysis we need a scoped-only > restriction > > when early completion is used: > > > > ======================================================== > > > > Scope-based-only branches restriction for early completion is needed, > because: > > > > * early completion mechanics does not change fundamentally > regardless > > whether we are using <complete> activity or > <completionCondition> > > * we need a scope to encapsulate activities of branch as _"units > of work"_ > > to minimize the need of defining <completionHandler> > > * a partial termination of a scope is NOT well-defined in BPEL, > while > > termination of the whole scope is already well-defined in BPEL > spec. > > > > > > *_How termination mechanism works in BPEL: _* > > Here is my understanding of how the termination mechanism in BPEL > works: When a > > scope is sent with a termination signal, the targeted scope will: (1) > cascade > > the termination signal inner child scopes (2) stop all the inner > activities > > within the targeted scope (3) execute the termination handler. Then, > done. > > > > As of now, the termination signal MUST alway go through a scope to > other > > NON-scope activity. And, the termination Handler of the corresponding > scope MUST > > got activated. > > > > Hence, termination of the whole scope is well defined. However, a > partial > > termination of a scope is NOT well-defined. That is we have not > defined: > > > > * what should happen if some branches got terminated, while some > branches > > are completed. > > * what should happen if the termination signal to sent to > NON-scope > > activities without going through a <scope>. > > > > > > *_Example #1_* > > > > Consider the following, a flow with two sequence as branches, which is > NOT > > scope-based. > > > > <scope name="A"> > > <flow> > > <completionCondition> ... </completionCondition> > > <sequence name="B1"> > > ... > > <scope name="B1SS1"> ... </scope> > > <receive name="B1R2" ... /> > > ... > > </sequence> > > <sequence name="B2"> > > ... > > <scope name="B2SS1"> ... </scope> > > <receive name="B2R2" ... /> > > ... > > </sequence> > > </flow> > > </scope> > > > > Say, sequence "B2" finishes. The completionCondition is fulfilled. > Sequence > > "B1" is being terminated when it is waiting a message at the receive > "B1R2". > > Now, we got the following questions _unanswered, if we don't want to > invent a > > brand variation of termination mechanism_: > > > > * Will the terminationHandler of scope "A" be activated? > > * Should the compensation handler of scope "B1SS1" be invoked? > Which > > "handler" logic is responsible to determine that? > > > > > > Ok. Let's change it into scope-based branches. > > > > <scope name="A"> > > <flow> > > <completionCondition> ... </completionCondition> > > <scope name="B1"> > > <terminationHandler> ... </terminationHandler> > > <sequence> > > ... > > <scope name="B1SS1"> ... </scope> > > <receive name="B1R2" ... /> > > ... > > </sequence> > > </scope> > > <scope name="B2"> > > <terminationHandler> ... </terminationHandler> > > <sequence> > > ... > > <scope name="B2SS1"> ... </scope> > > <receive name="B2R2" ... /> > > ... > > </sequence> > > </scope> > > </flow> > > </scope> > > > > The above questions got _answered clearly, with reusing the current > termination > > mechanism easily_: > > > > * Will the terminationHandler of scope "A" be activated? > > o No. > > * Should the compensation handler of scope "B1SS1" be invoked? > Which > > "handler" logic is responsible to determine that? > > o It is up to the terminationHandler to decide whether to > invoke the > > compensation handler of scope "B1SS1". By default, the > > terminationHandler of scope "B1" will invoke that > compensation handler. > > > > > > Hence, we minimize the need of "completionHandler". I hope I have > refreshed your > > memory on why we come up with this scope-based branches. (Regardless > we use > > <complete> activity or not). > > > > > > *_Example #2_* > > > > One important to remember: <flow> only controls the parallelism of > execution. It > > does not interfere the compensation and termination structure of a > process. > > > > Without scope-based-branch only restriction, the net effect of a > <flow> is just > > a parallellized execution of activities inside the flow in an > undeterministic > > order. So, in one extreme case of this undeterministic order, one > inner branch > > got completed first and then the other inner branch got executed. > Hence, one > > extreme case of <flow> is equivalent to the following nested sequence > pattern in > > the context of compensation and termination. (I replace <flow> in > exmple #1 with > > an outter <sequence> ... You can also think of one control-link is > used from > > sequence "EX2B1" to "EX2B2"). > > > > -------------------------------- > > <scope name="EX2A"> > > <sequence> > > <sequence name="EX2B1"> > > ... > > <scope name="EX2B1SS1"> ... </scope> > > <receive name="EX2B1R2" ... /> > > ... > > </sequence> > > <sequence name="EX2B2"> > > ... > > <scope name="EX2B2SS1"> ... </scope> > > <receive name="EX2B2R2" ... /> > > ... > > </sequence> > > </sequence> > > </scope> > > -------------------------------- > > > > Say, the execution is waiting at receive "EX2B2R2". Now due to early > completion, > > we need to do this "partial" termination magic. We don't have a > well-defined way > > to terminate sequence "EX2B2" without affecting sequence "EX2B1". > Similarly, we > > don't have a well-defined way to terminate sequence "EX2B2" without > affecting > > "EX2B2SS1" > > > > Now think again, if we have scope-based-only branches, all activities > are > > separated in units-of-work. Now those branches have independent > compensation and > > termination structure now. > > > > Last not least, if we map this early completion idea to transaction > world, it > > does not seem like a good idea to allow partial transaction-work > rollback > > (mapped to termination & compensation) without any units-of-work > boundary marker > > or checkpoints (mapped to <scope>). > > > > ======================================================== > > > > > > > > Thanks!!! > > Thank you so much for reading this long email! > > > > > > > > Regards, > > Alex Yiu > > > > > > Trickovic, Ivana wrote: > > > >>Motivation > >>=========== > >>The current semantics of the flow activity is that it completes when > all > >>its (directly) nested activities have completed, either successfully > or > >>unsuccessfully. However, there are scenarios where it is necessary to > >>have ability to complete the flow activity before all its nested > >>activities complete in order to speed up the process execution. For > >>example, a process waits in parallel for 3 reviews of a paper. If 2 > >>positive reviews are received the process may continue with the > >>execution without waiting for the last, third response. > >> > >>The completion condition of may have the following flavors: > >>* Wait for N out of M nested activities to complete > >>* Wait until after boolean condition C evaluates to true > >> > >>The completion condition is interesting for a flow activity enclosing > >>identical nested activities and for the parallel for-each activity > >>(still under discussion). > >> > >>Proposal > >>========= > >> > >>Syntax: > >> > >><flow standard-attributes> > >> standard-elements > >> <links>? > >> <link name="ncname">+ > >> </links> > >> <completionCondition>? > >> activity+ > >></flow> > >> > >><completionCondition> > >> <branches expressionLanguage="URI"? > >> countCompletedBranchesOnly="yes|no"?> > >> an-integer-expression > >> </branches>? > >> <booleanExpression expressionLanguage="URI"?> > >> a-boolean-expression > >> </booleanExpression>? > >></completionCondition> > >> > >> > >>Semantics: > >> > >>(1) The completionCondition element is an optional element of the flow > >>activity. Default behavior of the flow activity is that it waits for > all > >>its nested activities to complete. > >> > >>(2) There are two kinds of completion condition: > >>A> <booleanExpression>: A boolean condition operating upon process > >>variables. It is evaluated at the end of execution of each nested > >>activity. > >>B> <branches>: An integer value expression which is used to define > >>condition of flavor N out of M. It is evaluated at the end of > execution > >>of each nested activity. This condition has "at least N out of M" > >>semantics. (The exact N out of M condition semantics involve resolving > >>racing condition among nested activities.) > >> > >>(3) Both conditions (<branches> and <booleanExpression>) may be > >>specified at the same time. They will be evaluated at the end of > >>execution of each nested activity. If at least one condition evaluates > >>to true the <flow> activity completes successfully terminating all > >>remaining running nested activities. If both conditions are specified, > >>the <branches> will be evaluated first. If the boolean condition is > >>specified the evaluation of the condition is done in a serialized > >>fashion with respect to the nested activities directly enclosed in the > >>flow activity. > >> > >>(4) If the integer value evaluated from the <branches> expression is > >>larger than the number of nested activities in the <flow>, then > >>bpws:invalidBranchCondition fault MUST be thrown. Note that the number > >>of branches may be known only during runtime in some cases. Static > >>analysis should be encouraged to detect this erroneous situation at > >>design time when possible. (E.g. when the branches expression is a > >>constant.) > >> > >>(5) <branches> expression has an optional attribute > >>"countCompletedBranchesOnly". Its default value is "no". If > >>countCompletedBranchesOnly is "no", it means the BPEL processor will > >>count branches which have completed (either successfully or > >>unsuccessfully). If countCompletedBranchesOnly is "yes", it means the > >>BPEL processor will count branches which have completed successfully > >>only. > >> > >>(6) If flow activity specifies a completionCondition element the > >>completion condition is evaluated each time a nested activity > completes. > >>If the completion condition evaluates to true the flow activity > >>completes successfully. All still running nested activities will be > >>terminated. > >> > >>(7) Standard BPEL termination semantics applies to running nested > >>activities when the completion condition is met. The termination of > >>running nested activities follows the termination semantics defined in > >>the specification (see section 13.4.4 Semantics of Activity > >>Termination). > >> > >>(8) If all nested activities of the flow activity have been completed > >>but the completion condition evaluates to false the > >>"bpws:completionConditionFailure" MUST be thrown by the flow activity. > >> > >>(end) > >>---------------- > >> > >>Ivana > >> > >>--------------------------------------------------------------------- > >>To unsubscribe from this mail list, you must leave the OASIS TC that > >>generates this mail. You may a link to this group and all your TCs in > OASIS > >>at: > >>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > >> > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]