Hi Danny,
I guess it loops back to two main issues:
(1) Whether it is OK for a scope instance to do some work which
cannot be compensated (i.e. no well-defined way to compensate)? (e.g.
the case of <eventHandler> without a child scope)
(2) Consider the following code fragment sample:
Is <compensate scope="inner" /> legal?
If illegal, will it be too surprising to users?
If legal, what exactly is it semantics and given the existence of
implicit counter variable?
At the compensationHandler inside scope "inner", is it legal to use
"counter" variable?
Using the same code sample, we can illustrate another aspect of (1):
How do we compensate the work of <invoke operation="xyz" ...> in
this case?
---------------------------------
<scope>
<faultHandler>
<catchAll>
<compensate scope="inner" />
</catchAll>
<sequence>
...
<forEach parallel="yes" counter ... >
<sequence>
<invoke operation="xyz" ...>
<toPart part="branch"
fromVariable="counter" />
</invoke>
<scope name="inner" >
...
<variable name="fooVar" ... />
...
<compensationHandler> ...
</compensationHandler>
<sequence>
<assign> <copy>
<from>$xyz/foo[$counter]</from>
<to variable="fooVar" />
</copy> </assign>
<invoke variable="foo" ... />
</sequence>
</scope>
</sequence>
</while>
</sequence>
</scope>
---------------------------------
Other points of consideration:
For parallel-ForEach, people need to declare an inner scope anyway for
99%.
I think at this stage of the spec, we should try to avoid any
"smart-macro" in <forEach> similar to the
"invoke+compensationHandler" combo, which already gives us a number of
edge cases to think about.
Thanks!
Regards,
Alex Yiu
Danny van der Rijn wrote:
Alex Yiu wrote:
Hi, Danny,
(1)
<while> and <repeatUntil> do not introduce implicit
variables.
Right. So if you need to use those variables in compensation, use a
scope-child, and get the implicit behavior that I described. (Or have
to make it explicit yourself?)
(2)
And, <while> and <repeatUntil> are executed serially ... It
would be much easier to track how many iteration of works has been
finished at given point of time (say when a fault happens) (e.g.by
checking the counter and other flag-like variables used in the while
loop).
For the dynamic parallelism case of <forEach>, if there is no
local scope within the <forEach>, users need to need to handle a
collection / array of flags to keep track of the progress of the bunch
of parallel works ... (And, we have not defined related facilties /
construct in BPEL standard for this kind collection of flags yet.)
If you want to keep track, then you put that scope in, and install
compensation handlers there. Same as I would do for while. I wouldn't
find the counter or other flags to be preferable to having my own
compensation handler, if I cared, since finishing a scope and changing
the counter aren't going to happen in ACID fashion.
Maybe this gets to your meaning of "can not be compensated" but again,
I don't think there's anything fundamental here that isn't *really*
there with a while.
Thanks!
Regards,
Alex Yiu
Danny van der Rijn wrote:
Alex -
I'm not sure that I understand what you're getting at. You wouldn't be
able to compensate the forEach *by name* but it could still be
compensated. Why is this any different from compensating <while>
or <repeatUntil>?
Danny
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
Clarify on how to compensate an EventHandler
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
|