[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
thanks for finding that sentence. it was sufficiently buried that i couldn't pull it out. however, i never would have inferred serializable from that, nor would i recommend it. but i'll direct my comments to your issue when i see it. Yaron Y. Goland wrote: > Section 14.3 of the spec states: "An important characteristic of > assignment in BPEL4WS is that assignment activities are atomic. If > there is any fault during the execution of an assignment activity, the > destination variables are left unchanged as they were at the start of > the activity. This applies regardless of the number of assignment > elements within the overall assignment activity." > > I had been interpreting the previous such that atomic implied > serializable but that need not necessarily be the case. > > My own belief is that if assign's aren't inherently serializable then > programmers will kill themselves using BPEL. It is simply asking way > too much of programmers to make them understand that if they are > manipulating the same variable in two parallel flows that they can run > into problems like the one Danny's describes. > > In any case, I think this deserves its own issue so I just filed one. > > Yaron > > Danny van der Rijn wrote: > >> >> >> I certainly don't see anything in that section that says that assign is >> atomic. And even if it were, in my mind at least, that doesn't speak at >> all to concurrency. My example still holds if the assigns are atomic on >> separate control paths. >> >> Assaf Arkin wrote: >> >> > section 14.3. >> > >> > this is one of those things that has huge implications regardless of >> > completion condition. so if it's not clarified properly, got removed >> > in one of the edits, etc, it should be added back, regardless of how >> > we intend to solve completion conditions. >> > >> > Assaf >> > >> > Danny van der Rijn wrote: >> > >> >> can you point me to a section in the spec? >> >> >> >> thanks >> >> danny >> >> >> >> Assaf Arkin wrote: >> >> >> >>> Danny van der Rijn wrote: >> >>> >> >>>> i apologize for not being more explicit to begin with but imagine >> >>>> the following scenario, based on your example. to borrow a >> phrase, >> >>>> this is based on my lay understanding of the spec, and i apologize >> >>>> again in advance if this reasoning is incorrect. >> >>>> >> >>>> - outer scope initializes and sets counter to 0. >> >>>> - flow initializes. >> >>>> - each of 3 scopes initializes in parallel >> >>>> - the ... section of the first 2 scopes completes at the same >> time; >> >>>> the 3rd one hangs "forever," or for close enough to forever to >> >>>> satisfy the forever test. >> >>>> - the assigns of the first 2 scopes evaluate the "from" portion >> >>>> simultaneously, yielding a value of 1. >> >>>> - the "to" portions of the assign happen in some order. doeesn't >> >>>> matter. >> >>> >> >>> >> >>> >> >>> >> >>> Wouldn't happen, since the assign is atomic. >> >>> >> >>> Assaf >> >>> >> >>> >> >>>> >> >>>> now counter has miscounted, since 2 branches have completed, yet >> >>>> only 1 completion is "recorded." >> >>>> >> >>>> the flow will "never" complete. >> >>>> >> >>>> this would be solved if the leaf scopes were serializable. have >> >>>> some implicit concurrency control would be the huge advantage IMO, >> >>>> of having built-in N of M syntax. not that i'm necessarily >> >>>> advocating that complexity, but i think that if it is a common >> >>>> enough use case (which i think is really the crux of the issue) >> >>>> then asking people to get this right on their own is giving them >> >>>> enough rope to hang themselves, as well as giving them a boy scout >> >>>> knot-tying manual. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> Yaron Y. Goland wrote: >> >>>> >> >>>>> What the code implements is a 'at least N out of M'. >> >>>>> >> >>>>> Generally when we have N out of M scenarios (which are pretty >> >>>>> rare, most of our flow + break scenarios tend to be 'first to >> >>>>> finish') the goal is to make sure that at least N happens. If >> more >> >>>>> than N happens that's o.k. too. >> >>>>> >> >>>>> Put another way, try to imagine a scenario where you want exactly >> >>>>> N out of M. Why is 'exactly' important? Heck, what does 'exactly' >> >>>>> even mean? My suspicion is that any scenario where 'at least N >> out >> >>>>> of M' doesn't work requires either full serialization of all the >> >>>>> code or 2PC. >> >>>>> >> >>>>> Just a guess, >> >>>>> >> >>>>> Yaron >> >>>>> >> >>>>> Danny van der Rijn wrote: >> >>>>> >> >>>>>> >> >>>>>> >> >>>>>> 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. >> >> >>>>>> >> >>>>>> >> >> >>>>>> >> >> >>>>>> > >> >>>>>> >> >>>>>> 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. >> >> > > 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]