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
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
|