[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 6.2 - Proposal For Vote
I will continue and move this part of discussion under Issue 147 thread. Thanks! Regards, Alex Yiu Yaron Y. Goland wrote: > Indeed, I don't see any compelling reason to introduce an explicit > scope on D. It doesn't add anything. In fact, if you want to start > slapping scopes everywhere then you should first start with event > handlers who have a similar variable assignment issue to for-each. > > Yaron > > Alex Yiu wrote: > >> Just want to add few brief comments: >> >> *(A)* During the last F2F, I thought Satish only suggested to limit >> early completion to <completionCondition> in <flow>, maybe in >> parallel <forEach>. I guess I got the wrong impression. Restricting >> early completion to parallel <forEach> only is a way too restrictive >> usage from viewpoint. And, restricting to <forEach> only make the >> issue 6 discussion totally dependent on Issue 147. And, if Issue 147 >> does not get passed, the discussion of Issue 6 becomes meaningless. >> >> *(B)* I tend to think it is not that common to have early completion >> logic to apply to a flow where control links are used. Because, when >> early completion condition is used, different branches within a flow >> are usually relatively independent tasks to achieve the same goal >> (i.e. completion condition). (Of course, I would be happy to hear >> convincing counter examples from others). >> >> *(C)* Ok. Let's say we want to cover the edge case of control-links + >> early-completion. Assume we accept Satish's supplementary >> interpretation of activity termination. Then, we shall be able to >> allow a flow with early-completion condition with control links >> without enforcing scope-based restriction. Then, it goes back to the >> same old question, as Satish rephrased it: >> "/should we protect the naïve process designer from unintended >> pitfalls by enforcing a scope boundary for branches that may be >> prematurely terminated by early completion?/" >> >> Do we trust our users that they can write a flow with control links + >> early completion and still get the compensation handler right? That >> is a conscious choice that we need to make. As of now, I am neutral >> to this question. >> >> *(D)* BTW, if we pass Issue 147 parallel for-each, I tend to think a >> scope-based restriction should be applied again to child activity in >> a parallel-each for to hold the iterator value properly for >> compensation ... (Of course, that should be the discussion of 147 >> ... and of course ... Yaron will yell at me again after he read this >> part of email ... ) >> >> >> >> Regards, >> Alex Yiu >> >> >> >> 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 >>> >>> >> > > > --------------------------------------------------------------------- > 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]