[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 204 - Proposal to vote
An alternative for the implicit scope is to make the implicit scope invisible for compensation purposes. But trying to explain that model to users will probably make both our and their heads explode. I think the simplest, most consistent and least surprising approach is to make the scope explicit. Yaron Alex Yiu wrote: > > Hi Danny, > > Do you mean that: if the explicit scope is not introduced, a ghost > (implicit) scope is introduced and the work performed (e.g. by > <onMessage>) CANNOT be compensated in that case? > > That may work for <eventHandler>, because that can be considered the > "side-job" of a scope. But, it may not work for <forEach>, which would > be extensively as parts of the "main-job" of a scope. > > Would people prefer treating "eventHandler" and "forEach" differently in > this context? > > [ Just a list of questions with an open mind on my side ... ] > > Thanks! > > > Regards, > Alex Yiu > > > Danny van der Rijn wrote: > >> IMO this adds unneeded complexity for those (many) cases where these >> handlers are not going to be compensated. What you are, in effect, >> proposing is this: >> >> <onEvent messageType="foo:bar" variable="vbl"> >> <scope/> >> </onEvent> >> >> should be read as: >> >> <onEvent messageType="foo:bar" variable="vbl"> >> <scope> >> <variables> >> <variable name="vbl"> >> $vbl >> </variable> >> </variables> >> </scope> >> </onEvent> >> >> in other words, declaring a variable of the same name on the scope >> which is initialized to the value of the ghost scope's variable. >> >> While I think that this makes sense, I disagree that this should >> require that "ghost scopes" be made corporeal. Why don't we just say >> that WHEN ghost scopes' immediately enclosed activities are scopes, >> that the above "macro" occurs. >> >> Danny >> >> Alex Yiu wrote: >> >>> >>> Hi all, >>> >>> The attached HTML is the proposal to vote for Issue 204. >>> >>> Thanks! >>> >>> >>> Regards, >>> Alex Yiu >>> >>> >>> >>> >>> Proposal Draft for Issue 204 >>> >>> Last modified: July 18, 2005 - 1pm PDT >>> >>> Summary: >>> To restrict that the child activity of: >>> (a) an <onEvent> and <onAlarm> under <eventHandler> >>> (b) a <forEach> activity (introduced by Issue 147) >>> MUST be a <scope> activity. >>> >>> Rationale: >>> Currently, <eventHandlers> and <forEach> are two constructs in BPEL >>> which: >>> >>> * introduces new variables without any explicit declaration >>> (<onEvent> implicitly declares message-related variables, while >>> <forEach> implicitly declares counter variable), and, >>> * introduces dynamic parallelism (i.e. having parallel branches >>> of which number is not known ahead of time) >>> >>> >>> Due to these two special natures, there is no well-defined way to >>> compensate the work performed by these 2 constructs from perspectives of: >>> >>> * lack of a well-defined scope-snapshot >>> * lack of a way to refer to dynamic parallel work being done >>> (e.g. <compensate scope="aScopeName" /> ) >>> >>> Some clarification is needed to fill in the gap between BPEL's >>> compensation model and semantics introduced by these constructs. >>> >>> (Note: <catch> also introduces variable to hold fault related data >>> without any explicit declaration. However it is used in "backward" >>> work, while <onEvent>, <onAlarm> and <forEach> can be used in >>> "forward" work. Hence, this kind of clarification is not needed for >>> <catch>.) >>> >>> Choices: >>> >>> To fill in the gap between the compensation model and these two >>> constructs, two choices were presented: >>> >>> * Implicit-Scope: treating <onEvent>/<onAlarm> (under >>> <eventHandler>) and <forEach> constructs as a way to add an >>> implicit scope, similar to the <invoke> macro (i.e. <invoke> >>> plus <compensationHandler>/<faultHandler> shorthand) >>> * Explicit-Scope: asking developers to use a <scope> explicitly >>> as the child activity under these constructs instead of adding >>> any implicit scopes >>> >>> The implicit-scope approach is relatively acceptable in the case of >>> <invoke> because there is no nested activity within <invoke> which >>> performs "forward" work. If an implicit scope is added as a result of >>> <forEach> or <onEvent>, any lexically direct child scopes under those >>> constructs will NOT be accessible by the fault handler / compensation >>> handler of the related parent scope. >>> >>> For example: >>> >>> <scope name="A"> >>> <faultHandler> >>> <catchAll> >>> <compensate scope="C" /> >>> </catchAll> >>> </faultHandler> >>> <eventHandlers> >>> <onEvent ... > >>> <sequence> >>> ... >>> <scope name="C"> ... </scope> >>> ... >>> </sequence> >>> </onEvent> >>> <eventHandlers> >>> ... >>> </scope> >>> >>> If the implicit-scope approach is adopted, <compensate scope="C" /> >>> will become illegal. This kind of semantics is perceived as too >>> implicit and surprising to users. Therefore, the implicit-scope >>> approach is not preferred. Also, <onEvent> and <onAlarm> will be >>> "upgraded" to become an activity, because it will need an activity >>> name if the implicit-scope-marco is applied. >>> >>> After the explicit-scope approach is adopted, the example would look >>> like the following: >>> >>> <scope name="A"> >>> <faultHandler> >>> <catchAll> >>> <compensate scope="B" /> >>> </catchAll> >>> </faultHandler> >>> <eventHandlers> >>> <onEvent ... > >>> <scope name="B"> >>> <sequence> >>> ... >>> <scope name="C"> ... </scope> >>> ... >>> </sequence> >>> </scope> >>> </onEvent> >>> <eventHandlers> >>> ... >>> </scope> >>> >>> With the explicit scope introduced, the semantics of scope-snapshot >>> and scope-specific <compensate> activity becomes well-defined now. >>> >>> (Note: The above choices discussion was briefly conducted during Palo >>> Alto F2F June-2005.) >>> >>> >>> Recap and More Details: >>> To restrict that the child activity of: >>> (a) an <onEvent> and <onAlarm> under <eventHandler> >>> (b) a <forEach> activity >>> MUST be a <scope> activity. >>> >>> This restriction MUST be enforced during static analysis. (XSD will >>> be updated to reflect this restriction). >>> >>> Variables introduced by these constructs (i.e. message related >>> variables at <onEvent> and counter variable at <forEach>) will be >>> declared implicitly as local variables of <scope> under <onEvent> and >>> <forEach>. (Hence, scope snapshot semantic is clarified.) >>> >>> >>> >>> END >>> >>> >>> >>>--------------------------------------------------------------------- >>>To unsubscribe from this mail list, you must leave the OASIS TC that >>>generates this mail. You may a link to this group and all your TCs in OASIS >>>at: >>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. You may a link to this group and all your TCs in >> OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]