[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 6 - Rough draft of proposal for vote
in that case, don't you have some serious concurrency issues? Yaron Y. Goland wrote: > Actually no. I just meant them as generic wrappers. I could just as > easily have used sequence instead of scope. > > Danny van der Rijn wrote: > >> >> >> i assume that the leaf scopes are serializable and that's why they're >> there? >> >> Yaron Y. Goland wrote: >> >> > Below is an example of 2 out of 3, it is generalizable from there. >> > >> > scope >> > variables >> > variable name="counter" type="xs:int" >> > sequence >> > assign >> > copy >> > from literal="true" >> > "0" >> > to >> > $counter >> > flow >> > scope >> > ... >> > assign >> > copy >> > from >> > $counter + 1 >> > to >> > $counter >> > switch >> > case >> > condition >> > $counter >= 2 >> > break >> > scope >> > ... >> > assign >> > copy >> > from >> > $counter + 1 >> > to >> > $counter >> > switch >> > case >> > condition >> > $counter >= 2 >> > break >> > scope >> > ... >> > assign >> > copy >> > from >> > $counter + 1 >> > to >> > $counter >> > switch >> > case >> > condition >> > $counter >= 2 >> > break >> > >> > >> > Trickovic, Ivana wrote: >> > >> >> >> >> >> >> Yaron, >> >> >> >> Would you illustrate how break activity could be used? How does it >> >> resolve problems tackled by proposals we have on table at the >> moment? >> >> >> >> Regards, >> >> >> >> Ivana >> >> >> >> > -----Original Message----- >> >> > From: Yaron Y. Goland [mailto:ygoland@bea.com] >> >> > Sent: Dienstag, 14. September 2004 00:01 >> >> > To: Alex Yiu >> >> > Cc: Trickovic, Ivana; Axel Martens; Frank Leymann; Dieter >> >> > Roller; Dieter >> >> > Koenig1; edwink@collaxa.com; satisht@microsoft.com; >> >> > wsbpel@lists.oasis-open.org >> >> > Subject: Re: [wsbpel] Issue 6 - Rough draft of proposal for vote >> >> > >> >> > >> >> > I believe that the complexity of the current proposal is well >> >> > above the >> >> > capabilities of what I expect to be the average BPEL programmer. >> >> > Completion conditions, ignorable faults, new XPATH functions, >> etc. >> >> > introduces a lot of complexity that I believe that average BPEL >> >> > programmer would not be interested in dealing with. >> >> > >> >> > We know from many decades of language experience that average >> >> > programmers can deal with break/continue. I know from at >> >> > least our own >> >> > experience at BEA that users can deal with the concept of a >> >> > flow where a >> >> > break in the flow results in the other members of the flow being >> >> > terminated in the BPEL meaning of the term. >> >> > >> >> > Defining a break activity and specifying that if break is used >> in the >> >> > context of flow then this means that the flow activity ends >> and any >> >> > uncompleted members of the flow are terminated would both fit >> >> > directly >> >> > into BPEL's existing syntax and semantics and I believe be >> >> > simple enough >> >> > that the average programmer can handle it. I would therefore >> >> > offer break >> >> > (and it's relative 'continue') as an alternative. >> >> > >> >> > Thanks, >> >> > >> >> > Yaron >> >> > >> >> > Alex Yiu wrote: >> >> > >> >> > > >> >> > > Hi, >> >> > > >> >> > > Ivana, thanks for sending out this proposal. >> >> > > I believe a number of us (including me) like the >> >> > <completionConditon> >> >> > > construct from your proposal high level speaking. >> >> > > >> >> > > After reading the proposal, I guess we need to work on a >> number of >> >> > > details. I would like to ask a few questions / mention a few >> >> points: >> >> > > >> >> > > * Minor syntax and semantics questions : >> >> > > o Do we want to allow expression for branch >> >> > attribute? instead >> >> > > of just a constant integer? >> >> > > o We may need to some minor syntax adjustment for >> >> > expression >> >> > > attribute because we have passed Isseu 13 already. >> >> > > o If answers to the above question are yes, then >> >> > the condition >> >> > > syntax may become a choice (xsd:choice) of the >> >> > following two: >> >> > > <condition >> >> > > > >> >> expressionLanguage="anyURI"?>boolean-expression</condition> >> >> > > <branchCondition >> >> > > > >> >> expressionLanguage="anyURI"?>integer-expression</condition> >> >> > > >> >> > > * About completionConditionFailure : it looks like a >> >> > nice idea so >> >> > > far ... >> >> > > >> >> > > * About the new "isCompleted()" function : I am not >> >> > against this >> >> > > function. But, I tend to think there are usually BPEL >> >> > variables >> >> > > being modifed as the execution result of a flow >> >> > activity. (See the >> >> > > train-or-plane-and-hotel example). Is it more typical >> to have >> >> > > completionCondition to be evaluated on those variables? >> >> > > Also, after the completion of the whole flow, it is >> >> > not uncommon >> >> > > for people to have logic to find out which branch is >> finished >> >> > > (especially when "or" is involved in the condition). The >> >> > > "isComplete()" function would be available only within >> the >> >> > > completionCondition within the flow. People may get >> >> > confused and >> >> > > attempt to use the "isComplete()" function outside >> >> > the flow. If >> >> > > the completionCondition relies on variables, the same >> >> logic is >> >> > > applicable outside of the flow. >> >> > > >> >> > > * About the IgnoreFault semantics: I recall this >> >> > ignoreFault idea >> >> > > back to March F2F. With ignoreFault semantics, it >> essentially >> >> > > introduces two brand new semantics. >> >> > > o It turns <flow> into a semi-<scope> like construct >> >> > > o It adds this new "ignoreFault" semantics: which >> catches >> >> > > certain fault and the catching action will not >> cause >> >> any >> >> > > scope to be marked as faulted. >> >> > > >> >> > > I tend to think this "ignoreFault" functionality has >> >> > quite a heavy >> >> > > weight impact to <flow> and fault handling picture in >> >> > BPEL. If there >> >> > > is an alternative way to achieve similar business >> >> > logic, I would go >> >> > > for the alternative way. >> >> > > >> >> > > Quoted from Ivana's email: >> >> > > " Not all activities must complete in order the >> enclosing flow >> >> > > activity to complete. The way to identify that an >> >> > enclosed activity >> >> > > did not complete is to propagate faults. " >> >> > > >> >> > > I agree with the first sentence. But, I am not sure >> >> > that propagating >> >> > > fault is the only way to identify an enclosed activity >> did not >> >> > > complete. I would rather use a scope as an activity >> enclosed by >> >> > > flow. If we wish to suppress any minor fault which >> >> > happens during >> >> > > the execution of the scope, then we can just add a >> >> > fault handler. If >> >> > > the fault that happen, the scope will be marked as >> "faulted". >> >> > > >> >> > > The completeConditon can identify the "incomplete" state >> of the >> >> > > scope by two ways: >> >> > > >> >> > > * completeCondition can be evaluated based on BPEL >> >> > variables, >> >> > > which are set to "incomplete" state by pre-flow >> >> > initialization >> >> > > or related fault-handler logic. >> >> > > * branch-based condition will interprete a faulted >> scope as >> >> > > "incomplete" branch and will not count them into >> >> > the required >> >> > > N branches. >> >> > > >> >> > > This will allow us to suppress minor fault with or >> without the >> >> > > <completionCondition> construct. Please see the >> >> > following example. >> >> > > It is already legal and working today. It shows how to >> suppress >> >> > > "foo:barFault" without the <completeCondition> construct >> >> > > >> >> > > <flow> >> >> > > <scope name="A"> >> >> > > <faultHandler> >> >> > > <catch faultName="foo:barFault" ... > ... </catch> >> >> > > </faultHandler> >> >> > > <sequence> >> >> > > ... <invoke name="doA" ... /> ... >> >> > > </sequence> >> >> > > </scope> >> >> > > <scope name="B"> ... <!-- similar to A --> ... </scope> >> >> > > </flow> >> >> > > >> >> > > If the invoke of "doA" triggers "foo:barFault", the >> >> > scope "A" will >> >> > > be marked as faulted. On the other hand, scope "B" will >> >> > be allowed >> >> > > to continue and complete. After scope "B" is completed, the >> >> > > compensation handler of scope "B" will be installed. >> And, the >> >> > > overall execution of flow is still considered a normal >> >> > completion. >> >> > > >> >> > > I hope I have illustrated we can achieve similar logic >> without >> >> > > introducing a new "ignoreFault" construct and concept to >> BPEL. >> >> > > >> >> > > What "completionCondition" does should be just >> >> > providing a way to >> >> > > pro-actively cancel/terminate other flows without >> >> > waiting to them to >> >> > > complete or to be faulted. >> >> > > >> >> > > * About "Cancel-other-flows": (Let me consolidate what >> I am >> >> > > leaning towards so far.) We need to formal define the >> >> > notion of a >> >> > > " cancel-other-flows " mechanism. This mechanism is >> >> > specified and >> >> > > attached to <flow> construct (and future parallel forEach >> >> > > construct). When this mechanism is triggered by one >> >> > of parallel >> >> > > flows, it will cancel/terminate other parallel flows >> which >> >> are >> >> > > still running, after the triggering flow is completed. >> If the >> >> > > other flow activties are scope activities, the scope >> will be >> >> > > marked as cancelled. >> >> > > >> >> > > This mechanism will be triggered upon the >> >> > completionCondition is >> >> > > evaluated to be true. >> >> > > >> >> > > [Note: (a) since this mechanism is triggered by >> >> > without using any >> >> > > fault directly. This will again decrease the need of >> >> > "ignoreFault" >> >> > > construct (b) This mechanism will affect the wordings >> >> > of Issue 135 >> >> > > to an extent.] >> >> > > >> >> > > [Question: again, should we enforce scope-only >> activity when >> >> > > completionCondition is used? I tend to say yes.] >> >> > > >> >> > > >> >> > > >> >> > > Thank you all for following and reading this email thread!!! >> >> > > >> >> > > >> >> > > >> >> > > Regards, >> >> > > Alex Yiu >> >> > > > > >> >> > > >> >> > > Trickovic, Ivana wrote: >> >> > > >> >> > >> > >> >> >> > >> Here is a proposal for the completion condition - it >> >> > addresses some >> >> > >> issues not tackled so far (at least not in case of >> >> > >> <completeCondition>). It is a version of the proposal for >> >> > completion >> >> > >> condition for the bundle element. This proposal includes >> >> > comments from >> >> > >> many people including Frank Leymann, Dieter Koenig, Dieter >> >> > Roller and >> >> > >> Satish Thatte. It does not mean that they completely >> support the >> >> > >> proposal - they may have issues with any part of the proposal. >> >> > >> >> >> > >> > >> >> >> > >> > >> >> >> > >> Completion condition >> >> > >> >> >> > >> ===================== >> >> > >> >> >> > >> The current semantics of the flow activity is that it >> >> > waits for all >> >> > >> concurrent activities to complete. The completion also >> >> > means that an >> >> > >> enclosed activity/scope may end abnormally or be skipped >> (e.g. the >> >> > >> join condition of the activity evaluated to false). If a >> fault is >> >> > >> thrown within an enclosed activity/scope and one of the >> >> > local fault >> >> > >> handlers catch the fault (and does not rethrow the fault), the >> >> > >> enclosed activity/scope will be deemed to be completed >> >> > (although ended >> >> > >> abnormally). If a fault is not caught by any local fault >> >> > handler (or >> >> > >> is rethrown) the flow activity will terminate all active >> >> > concurrent >> >> > >> activities and corresponding fault handler may be initiated. >> >> > >> >> >> > >> > >> >> >> > >> A completion condition for the flow activity is needed for >> >> > scenarios >> >> > >> where not all concurrent activities of a flow activity >> >> > must complete >> >> > >> in order the flow activity to complete. Note: We are not >> >> > talking about >> >> > >> "successful completion" of enclosed concurrent activities >> >> > because that >> >> > >> would not be consistent with the semantics of the current >> >> > flow activity. >> >> > >> >> >> > >> > >> >> >> > >> The completion condition may have different flavors, such as: >> >> > >> >> >> > >> (1) N out of M >> >> > >> >> >> > >> (2) The two most important requests completed >> >> > >> >> >> > >> (3) A Boolean condition operating upon process variables >> >> > >> >> >> > >> > >> >> >> > >> Not all activities must complete in order the enclosing >> >> > flow activity >> >> > >> to complete. The way to identify that an enclosed activity >> did not >> >> > >> complete is to propagate faults. We may distinguish between >> severe >> >> > >> faults and those that can be ignored. Severe faults cause the >> >> > >> enclosing flow activity (or more precisely, enclosing >> scope) to >> >> > >> terminate the flow activity, including all active concurrent >> >> > >> activities, and corresponding fault handler may be >> >> > initiated. Other >> >> > >> faults may be ignored - the flow activity is "informed" that a >> >> > >> concurrent activity did not complete but still allows other >> active >> >> > >> concurrent activities to continue with execution. >> >> > >> >> >> > >> > >> >> >> > >> Ignore semantics >> >> > >> >> >> > >> ================= >> >> > >> >> >> > >> Faults thrown within enclosed concurrent activities/scopes >> and not >> >> > >> handled by local fault handlers are rethrown. Enclosing >> >> > <flow> element >> >> > >> decides which of these rethrown faults can be ignored. This >> new >> >> > >> "ignore" semantics should be part of the completion >> condition and >> >> > >> should apply to all enclosed activities. This new >> >> > semantics does not >> >> > >> introduce a new fault handling mechanism. It is needed for >> >> > identifying >> >> > >> how many of the enclosed activities failed. >> >> > >> >> >> > >> > >> >> >> > >> > >> >> >> > >> Proposed syntax >> >> > >> >> >> > >> ================ >> >> > >> >> >> > >> <flow standard-attributes> >> >> > >> >> >> > >> standard-elements >> >> > >> >> >> > >> <completionCondition/>? >> >> > >> >> >> > >> <links>? >> >> > >> >> >> > >> <link name="ncname">+ >> >> > >> >> >> > >> </links> >> >> > >> >> >> > >> activity+ >> >> > >> >> >> > >> </flow> >> >> > >> >> >> > >> > >> >> >> > >> <completionCondition> >> >> > >> >> >> > >> <conditions branch="xsd:integer"? >> >> > >> >> >> > >> expression=xpath?/>? >> >> > >> >> >> > >> <ignoreFaults>? >> >> > >> >> >> > >> <fault name="qname"? value="ncname"?/>* >> >> > >> >> >> > >> <ignoreAll/>? >> >> > >> >> >> > >> </ignoreFaults> >> >> > >> >> >> > >> </completionCondition> >> >> > >> >> >> > >> > >> >> >> > >> Attribute branch is used to specify a condition of flavor >> >> > "wait for >> >> > >> /N/ out of /M/ activities to complete", or more precisely >> value N. >> >> > >> Attribute expression is used to specify a Boolean >> >> > condition operating >> >> > >> upon process variables or a condition of flavor "the two most >> >> > >> important requests completed". >> >> > >> >> >> > >> > >> >> >> > >> Both conditions ( branch and expression) may be specified >> >> > at the same >> >> > >> time. They will be checked when one instance of the scope >> activity >> >> > >> reaches the end. If at least one condition evaluates to >> true all >> >> > >> active instances will be terminated. >> >> > >> >> >> > >> > >> >> >> > >> Element <ignoreFaults> specifies faults that may be >> >> > ignored. Element >> >> > >> fault is used to specify a fault which may be ignored >> >> > (fault name and >> >> > >> fault data may be specified). Element <ignoreAll> would >> >> > mean that all >> >> > >> faults thrown/rethrown by any concurrent activity/scope may be >> >> > >> ignored. If this element is specified <fault> element must >> >> > be omitted. >> >> > >> >> >> > >> > >> >> >> > >> Completion condition failure >> >> > >> >> >> > >> ============================= >> >> > >> >> >> > >> A new standard fault, e.g. completionConditionFailure, >> should be >> >> > >> introduced to notify that the completion condition of a >> >> > flow activity >> >> > >> evaluated to false (note: all concurrent activities have been >> >> > >> completed). The fault is thrown in the scope enclosing the >> >> > flow element. >> >> > >> >> >> > >> > >> >> >> > >> Completion condition and links >> >> > >> >> >> > >> ============================== >> >> > >> >> >> > >> There should be no difference between a flow activity with a >> >> > >> completion condition and a flow activity without >> >> > completion condition. >> >> > >> For example, if the completion condition fails all links >> >> > leaving the >> >> > >> flow activity should have value "false" (or be reverted to >> >> > a negative >> >> > >> status). >> >> > >> >> >> > >> > >> >> >> > >> There are just a few additional rules: >> >> > >> >> >> > >> (1) Let's assume enclosed activity A is the source of a >> >> > link. If the >> >> > >> completion condition evaluates to true and activity A is >> >> > not completed >> >> > >> it will be terminated and the value of the link will be >> >> > set to "false". >> >> > >> >> >> > >> (2) Let's assume enclosed activity A is the source of a >> >> > link and the >> >> > >> activity failed but the fault is "ignored" by the enclosing >> flow >> >> > >> activity. The value of the link will be set to "false". >> >> > >> >> >> > >> > >> >> >> > >> New function for completion condition of flavor "the two most >> >> > >> important requests completed" >> >> > >> >> >> > >> >> >> > ============================================================== >> >> > ============================== >> >> > >> >> >> > >> >> >> > >> For completion conditions of flavor "the two most >> >> > important requests >> >> > >> completed" standard attribute "name" must be specified for all >> >> > >> enclosing activities in order to be able to distinguish >> them. In >> >> > >> addition a new function, e.g. isCompleted('activityName') >> must be >> >> > >> introduced. The semantics of the function is: if activity >> >> > completed >> >> > >> successfully the function returns value true. >> >> > >> >> >> > >> > >> >> >> > >> Example >> >> > >> >> >> > >> <completionCondition expression= >> >> > >> >> >> > >> "isCompleted('A') AND isCompleted('B')" >> > >> >> >> > >> </completionConditions> >> >> > >> >> >> > >> > >> >> >> > >> > >> >> >> > >> Regards, >> >> > >> >> >> > >> > >> >> >> > >> Ivana >> >> > >> >> >> > >> > >> >> >> > >> -----Original Message----- >> >> > >> *From:* Alex Yiu [mailto:alex.yiu@oracle.com] >> >> > >> *Sent:* Samstag, 11. September 2004 00:49 >> >> > >> *To:* Axel Martens >> >> > >> *Cc:* 'edwink@collaxa.com >> >> > <mailto:edwink@collaxa.com>'; Trickovic, >> >> > >> Ivana; 'satisht@microsoft.com >> <mailto:satisht@microsoft.com>'; >> >> > >> 'wsbpel@lists.oasis-open.org >> >> > >> <mailto:wsbpel@lists.oasis-open.org>'; Alex Yiu >> >> > >> *Subject:* Re: [wsbpel] Issue 6 - Rough draft of >> >> > proposal for vote >> >> > >> >> >> > >> >> >> > >> Hi, Axel, >> >> > >> >> >> > >> Thanks for liking parts of my proposal so far. >> >> > >> Actually, the idea of my proposal is borrowed from a >> part of >> >> > >> presentation from Ivana and Dieter Roller in March F2F. >> I just >> >> > >> generalize it to apply to <flow> also. >> >> > >> >> >> > >> About using links or not: >> >> > >> I don't have a huge opposition to Axel's proposal >> >> > which enriches >> >> > >> the semantics of joinCondition evaluation. However, it >> >> > is not that >> >> > >> difficult for people to make mistakes in joinCondition. >> >> Look at >> >> > >> the 2-out-of-3 example. The join condition already gets so >> >> > >> complicated. If people make a mistake in their >> >> > joinCondition, the >> >> > >> whole flow can get struck for no good reasons. (The >> >> > >> completeCondition approach will less likely to have >> >> > the whole flow >> >> > >> struck. Because, it does not introduce a new parallel >> >> > activity in >> >> > >> the flow). But, if this is what Petri-net-oriented and >> >> > >> control-link-oriented audience really want, I can >> >> > accept it in a >> >> > >> sense, as long as this is not the only way to achieve >> similar >> >> > >> business logic. >> >> > >> >> >> > >> About static vs dynamic parallelism: >> >> > >> Static parallelism is basically <flow> construct in >> >> > BPEL. Dynamic >> >> > >> parallelism is "parallel forEach" or "bundle". Issue 4 >> >> > and 147 are >> >> > >> related issues. >> >> > >> > >> >> http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue4 >> >> > >> > >> >> http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue147 >> >> > >> >> >> > >> About "Terminating still running tasks versus >> proceeding in >> >> > >> control flow while those tasks are >> >> > >> still running": >> >> > >> I am not 100% that I understand your question. Let me >> try to >> >> > >> answer it anyway. The completeCondition is about >> triggering >> >> > >> termination of still-running tasks. The "proceeding in >> control >> >> > >> flow" (if I understand you correctly) will be handled >> >> > by an outter >> >> > >> flow. [I guess it is related to (hotel and (train or >> >> > plane)) flow??] >> >> > >> >> >> > >> About changes of "forcedTermination" fault handler: >> >> > >> If you got a chance to see some recent emails on Issue >> >> > 135, Satish >> >> > >> has recently suggested to remove the notion >> >> "forcedTermination" >> >> > >> fault and replace its fault handler with cancelHandler. >> Frank, >> >> > >> Yaron, Edwin and I all agree with this direction. Because, >> >> > >> overloading fault with the concept of >> "forcedTermination" is a >> >> > >> "false economy" and it creates quite a bit of >> >> > unnecessary confusion. >> >> > >> >> >> > >> I don't think we should go back to this route or even >> further >> >> > >> overload the "forcedTermination" fault handler >> >> > semantics. Because, >> >> > >> fault handling is way too generic and the changes you >> >> mentioned >> >> > >> will create even more confusion. (e.g. Will this >> >> > change of marking >> >> > >> as "completed" apply to all "forcedTermination" fault >> >> handler / >> >> > >> cancel handler of all scopes? ) >> >> > >> >> >> > >> I guess most of us agree that we should have a new >> >> mechanism to >> >> > >> kill / do an early completion of a flow in a nice and >> >> > clean way. >> >> > >> However, overloading a standard fault handler does not >> >> > seem to be >> >> > >> the best one. I would rather introduce a construct >> >> > which is very >> >> > >> specific to <flow> or parallel-forEach. For example, this >> >> > >> <completeCondition> construct or maybe a new activity >> called >> >> > >> <completeFlow />. I will send out more emails on >> >> > joint thinking >> >> > >> of both Issue 6 and Issue 135. Please stay tuned. >> >> > >> >> >> > >> >> >> > >> Thanks! >> >> > >> >> >> > >> >> >> > >> >> >> > >> Regards, >> >> > >> Alex Yiu >> >> > >> >> >> > >> >> >> > >> Axel Martens wrote: >> >> > >> >> >> > >>> >> >> > >>> Hi, >> >> > >>> >> >> > >>> I like the simplicity of the syntax of Alex's >> >> > proposal. Although, >> >> > >>> for me it is quite easy to model in terms of links and >> join >> >> > >>> conditions, and I want to keep my proposal alive >> >> > (because of the >> >> > >>> minimal changes to BPEL's syntax and semantics), it >> >> > looks like a >> >> > >>> nice macro to provide more convenience to the customers. >> >> > >>> >> >> > >>> Alex, could you shortly explain to me, what do you >> >> > mean by static >> >> > >>> and dynamic parallelism? How do you handle the two >> >> > different cases >> >> > >>> after evaluating the completeCondition: Terminating >> >> > still running >> >> > >>> tasks versus proceeding in control flow while those >> tasks are >> >> > >>> still running (Sorry, I missed your previous emails)? >> >> > >>> >> >> > >>> I agree to Alex's opinion, that we need a mechanism to >> kill >> >> > >>> parallel flow nice and clean. This could be done >> >> > either by a new >> >> > >>> mechanism which does not throw a fault or by changing >> the way >> >> > >>> fault are handled. I have discussed already an example >> of the >> >> > >>> second case with Ivana, and I like to tell you, what I >> >> have in >> >> > >>> mind. Look at the following example: >> >> > >>> >> >> > >>> <scope name="scopeFlow"> >> >> > >>> ... >> >> > >>> <flow> >> >> > >>> <link name="linkA"/> >> >> > >>> <link name="linkB"/> >> >> > >>> >> >> > >>> <scope name="scopeA"> >> >> > >>> ... >> >> > >>> <invoke name="A" ...> >> >> > >>> <source linkName="linkA" ...> >> >> > >>> </invoke> >> >> > >>> </scope> >> >> > >>> >> >> > >>> <scope name="scopeB"> >> >> > >>> ... >> >> > >>> <invoke name="B" ...> >> >> > >>> <source linkName="linkB" ...> >> >> > >>> </invoke> >> >> > >>> </scope> >> >> > >>> >> >> > >>> <throw name="C" faultName="bpws:forcedCompletion" >> >> > >>> joinCondition="linkA OR linkB" >> >> > >>> joinEvaluation="immediate"> >> >> > >>> <target linkName="linkA" ...> >> >> > >>> <target linkName="linkB" ...> >> >> > >>> </throw> >> >> > >>> >> >> > >>> </flow> >> >> > >>> </scope> >> >> > >>> >> >> > >>> First, I explain the situation: In the example above, >> >> > activity C >> >> > >>> will be executed if one of the two activities A and B was >> >> > >>> successfully completed. Activity C throws the fault >> >> > >>> "forcedCompletion". Like each other fault, this >> >> > forces the scope >> >> > >>> "scopeFlow" to terminate still running activities. >> >> > Assume, there >> >> > >>> was a fault handler defined in this scope which >> >> > catches the fault >> >> > >>> "forcedCompletion" (omitted in here), the process >> >> > continues after >> >> > >>> scope "scopeFlow". A problem arises, if scope >> >> > "scopeFlow" should >> >> > >>> be compensated. Because it was exited from a fault >> >> handler, no >> >> > >>> compensation handler was installed. >> >> > >>> >> >> > >>> Now, I explain my solution: In the example, I have >> >> > chosen a new >> >> > >>> "standard" fault name: "forcedCompletion". The only >> necessary >> >> > >>> change is to allow a fault handler that catches this >> fault to >> >> > >>> install a compensation handler for the same scope, >> >> > i.e. to mark >> >> > >>> the scope "scopeFlow" as "completed" instead of "exited". >> >> > >>> >> >> > >>> The standard compensation mechanism will only undo those >> >> > >>> ("scoped") activities within the scope, which >> >> > actually have been >> >> > >>> successfully completed, i.e. scopeA or scopeB or may >> be both. >> >> > >>> >> >> > >>> Axel. >> >> > >>> ---------------------------------------- >> >> > >>> Axel Martens >> >> > >>> >> >> > >>> Post Doc Researcher >> >> > >>> Component Systems Group >> >> > >>> IBM TJ Watson Research Center >> >> > >>> Hawthorne, NY (USA) >> >> > >>> Phone: (914) 784-7480 >> >> > >>> E-mail: amarten@us.ibm.com <mailto:amarten@us.ibm.com> >> >> > >>> >> >> > >>> >> >> > >>> *Alex Yiu <alex.yiu@oracle.com> >> <mailto:alex.yiu@oracle.com>* >> >> > >>> >> >> > >>> 09/10/2004 12:10 AM >> >> > >>> >> >> > >>> > >>> To >> >> > >>> Alex Yiu <alex.yiu@oracle.com> >> >> > <mailto:alex.yiu@oracle.com> >> >> > >>> cc >> >> > >>> "Trickovic, Ivana" <ivana.trickovic@sap.com> >> >> > >>> <mailto:ivana.trickovic@sap.com>, Axel >> >> > Martens/Watson/IBM@IBMUS, >> >> > >>> "'edwink@collaxa.com'" <mailto:%27edwink@collaxa.com%27> >> >> > >>> <edwink@collaxa.com> <mailto:edwink@collaxa.com>, >> >> > >>> "'satisht@microsoft.com'" >> >> <mailto:%27satisht@microsoft.com%27> >> >> > >>> <satisht@microsoft.com> <mailto:satisht@microsoft.com>, >> >> > >>> "'wsbpel@lists.oasis-open.org'" >> >> > >>> <mailto:%27wsbpel@lists.oasis-open.org%27> >> >> > >>> <wsbpel@lists.oasis-open.org> >> >> > >>> <mailto:wsbpel@lists.oasis-open.org>, Alex Yiu >> >> > >>> <alex.yiu@oracle.com> <mailto:alex.yiu@oracle.com> >> >> > >>> Subject >> >> > >>> Re: [wsbpel] Issue 6 - Rough draft of proposal >> for vote >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> Hi, >> >> > >>> >> >> > >>> Here are some examples how to use completeCondition to >> >> express >> >> > >>> similar business logic in Axel's previous email: >> >> > >>> >> >> > >>> (A) "Select one out of three" example: >> >> > >>> <flow> >> >> > >>> <completeCondition *branch="1"* /> >> >> > >>> <invoke name="CheckAirlineA" ... /> >> >> > >>> <invoke name="CheckAirlineB" ... /> >> >> > >>> <invoke name="CheckAirlineC" ... /> >> >> > >>> </flow> >> >> > >>> >> >> > >>> >> >> > >>> (B) "Select two out of three" example: >> >> > >>> <flow> >> >> > >>> <completeCondition *branch="2"* /> >> >> > >>> <invoke name="AskRefereeA" ... /> >> >> > >>> <invoke name="AskRefereeB" ... /> >> >> > >>> <invoke name="AskRefereeC" ... /> >> >> > >>> </flow> >> >> > >>> >> >> > >>> As you guys can see, the completeCondition declaration is >> >> very >> >> > >>> straight forward and simple. No complicated links and >> >> > >>> joinCondition usage. >> >> > >>> >> >> > >>> (C) "(Plane or Train) and Hotel" example: It would >> become two >> >> > >>> flow constructed (nested). >> >> > >>> >> >> > >>> >> >> > >>> <assign> ... <to variable="planeResult"></assign> >> >> > >>> <!-- initialize "planeResult" with NOT-OK value --> >> >> > >>> <assign> ... <to variable="trainResult"></assign> >> >> > >>> <!-- initialize "trainResult" with NOT-OK value --> * >> >> > >>> <flow name="checkIterinary">* >> >> > >>> *<flow name="PlaneOrPlane">* >> >> > >>> <completeCondition> >> >> > >>> fn:planeOK(planeResult) *or* >> >> > fn:trainOK(trainResult) >> >> > >>> </completeCondition> >> >> > >>> <invoke name="CheckPlane" >> >> > outputVariable="planeResult" ... /> >> >> > >>> <invoke name="CheckTrain" >> >> > outputVariable="trainResult" ... /> >> >> > >>> *</flow> * >> >> > >>> <invoke name="checkHotel" /> * >> >> > >>> </flow> >> >> > >>> <switch name="bookingSwitch">* >> >> > >>> <case> >> >> > >>> <condition> >> >> > >>> (fn:planeOK(planeResult) *or* >> fn:trainOK(trainResult)) >> >> > >>> *and* fn:hotelOK(hotelResult) >> >> > >>> </condition> >> >> > >>> <invoke name="invokeBooking" ... /> >> >> > >>> </case> >> >> > >>> <otherwise> >> >> > >>> <invoke name="writeInformation" ... /> >> >> > >>> </otherwise> * >> >> > >>> </switch>* >> >> > >>> >> >> > >>> >> >> > >>> Please note that regardless whether we pick a >> link-oriented >> >> > >>> approach or completeCondition approach: >> >> > >>> >> >> > >>> * The initialization of result variables are >> >> > needed because >> >> > >>> of potential cancellation of one of the invoke >> between >> >> > >>> train and plane >> >> > >>> * The "fn:*()" represents the logic to determine >> >> whether a >> >> > >>> traveling resource is available. They are used in >> >> either >> >> > >>> the transitionCondition of links or the >> condition of >> >> > >>> switch/case. >> >> > >>> >> >> > >>> As you guys see, we don't need declare to six links. The >> >> > >>> completeCondition and case-condition are much simpler >> >> > and easier >> >> > >>> to understand. >> >> > >>> >> >> > >>> I attach a diagram to illustrate the above flows. >> >> > >>> >> >> > >>> I guess we can still more time in terms of refiniment of >> >> > >>> joinCondition evaluation. However, I don't think that >> >> > should be >> >> > >>> the only approach to achieve complete condition related >> >> logic. >> >> > >>> >> >> > >>> >> >> > >>> Thanks!!! >> >> > >>> >> >> > >>> Regards, >> >> > >>> Alex Yiu >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> Alex Yiu wrote: >> >> > >>> >> >> > >>> Hi, >> >> > >>> >> >> > >>> +1 to what Ivana said in general. >> >> > >>> >> >> > >>> Few points to add: >> >> > >>> >> >> > >>> * Axel's proposed enhancement to control links >> evaluation >> >> > >>> works to an extent for static parallelism > (e.g. >> >> <flow>). >> >> > >>> However, control links do not work well in dynamic >> >> > >>> parallelism (e.g. "parallel forEach" or >> >> > "bundle"). I think >> >> > >>> the notion of completeCondition (borrowed from >> Ivana >> >> and >> >> > >>> DK) is general enough and it should be applied >> to both >> >> > >>> static and dynamic parallelism. A general >> >> > completeCondition >> >> > >>> mechanism will be easier for BPEL users to learn. >> >> > >>> * Even in a pure static parallelism case, >> >> > completeCondition >> >> > >>> has much better code clarity. It is more >> declarative >> >> and >> >> > >>> easier for BPEL users to understand. It will >> eliminate >> >> > >>> significant amount of joinCondition >> >> > programming, which may >> >> > >>> be error prone. (I will send another email later to >> >> show >> >> > >>> how completeCondition can be used to express the >> same >> >> > >>> semantics of Axel's example). >> >> > >>> * In one of my previous emails, I also tried to >> >> > use a "macro" >> >> > >>> way to illustrate how outstanding running flows >> can be >> >> > >>> cancelled by throwing a fault within a scope. The >> >> > >>> illustration has the same compensation handler >> >> > installation >> >> > >>> problem that Ivana has pointed out. The >> "illustraction >> >> > >>> macro" does NOT carry a desirable and intended >> >> > semantics. >> >> > >>> We need to create / describe a new mechanism to >> cancel >> >> > >>> parallel flow without throwing a fault. (That >> >> > was discussed >> >> > >>> briefly between Edwin and me at Oracle). >> >> > >>> >> >> > >>> >> >> > >>> Thanks! >> >> > >>> >> >> > >>> >> >> > >>> Regards, >> >> > >>> Alex Yiu >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> Trickovic, Ivana wrote: >> >> > >>> Axel, >> >> > >>> > >>> I find the idea interesting. In fact, I was >> >> discussing the >> >> > >>> completion condition issue with Dieter Koenig during >> >> > the last f2f >> >> > >>> meeting and his suggestion was also to try to resolve >> >> > this issue >> >> > >>> using links. And we identified that several changes need >> >> to be >> >> > >>> done, including removing restriction for >> >> > jonCondition, that "the >> >> > >>> join condition is evaluated as soon as all incoming >> >> > links of the >> >> > >>> activity are determined" - so definitely "immediate" >> >> semantics >> >> > >>> needs to be introduced. >> >> > >>> > >>> I have the following comments on your >> proposal. >> >> > >>> 1. In your proposal you are using a fault >> >> > >>> (bpws:forcedTermination) to terminate all active parallel >> >> > >>> branches. But this changes the outcome of the flow >> >> > activity. It >> >> > >>> will always end abnormally and compensation handler >> (if it is >> >> > >>> defined) will never be installed. Although completion >> >> > condition >> >> > >>> has evaluated to true and needed activities have >> completed >> >> the >> >> > >>> enclosing flow activity will end abnormally. Is this >> really >> >> > >>> intended semantics? >> >> > >>> > >>> 2. Your proposal does not address some pain >> >> points. >> >> > For example, >> >> > >>> in case of "N out of M", N<M there many possible >> >> "variations": >> >> > >>> (A) One enclosed activity may experience problems but >> >> > the <flow> >> >> > >>> activity may succeed >> >> > >>> (B) One of enclosed activities may experience a severe >> error, >> >> > >>> which may have impact on the <flow> activity >> >> > >>> The question is what to do with running activities? >> >> > In the latter >> >> > >>> case, reasonable behavior would be: if one enclosed >> >> > activity does >> >> > >>> not succeed other running activities should be >> >> > cancelled and the >> >> > >>> flow activity should try to recover. In the former >> case, we >> >> > >>> should allow active parallel activities to complete >> >> > their work. >> >> > >>> This is not supported in your proposal. >> >> > >>> > >>> Regards, >> >> > >>> > >>> >> >> > >>> Ivana >> >> > >>> >> >> > >> [stuff deleted] >> >> > >> >> >> > > >> >> > >> >> > To unsubscribe from this mailing list (and be removed from >> >> > the roster of the OASIS TC), go to >> >> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le >> >> > ave_workgroup.php. >> >> > >> >> >> >> To unsubscribe from this mailing list (and be removed from the >> roster >> >> of the OASIS TC), go to >> >> >> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. >> >> >> >> >> >> > >> > To unsubscribe from this mailing list (and be removed from the roster >> > of the OASIS TC), go to >> > >> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. >> >> > >> > >> > >> >> To unsubscribe from this mailing list (and be removed from the roster >> of the OASIS TC), go to >> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]